Skip to main content
All systems operationalChangelogv1
Log in

Fraud Workflow and Statuses

Understand DEUNA fraud-process, provider-analysis, and risk-decision fields without confusing them with payment outcomes.

On this page

Fraud decisions and payment outcomes are independent. An accepted fraud decision does not prove that a payment was authorized, captured, or settled; a rejected fraud decision does not prove that previously reserved or collected funds were reversed.

Read every value from its actual field:

FieldPurposePublic values
fraud.statusOverall fraud-process state. In an order-wrapped payload: order.fraud.status.pending, in_review, accepted, rejected
fraud.analysis.statusStatus reported for the selected provider analysis.automatic_decision, manual_review, pending_analysis, denied, accepted
fraud.analysis.fraud_decisionNormalized risk decision used by policy and routing.high_risk, medium_risk, low_risk, pending_risk, manual_review, manual_denied, manual_approved
payment.data.statusFinancial payment lifecycle.See Payment workflow and statuses.

Do not combine these fields into one enum, even when two fields contain similar words.

Overall fraud process#

This diagram applies only to fraud.status. The rounded nodes complete the fraud decision, not the payment lifecycle.

Flow diagram
Immediate acceptanceImmediate rejectionManual or asynchronousreviewApprovedRejected1pendingEvaluation started2in_reviewMore analysis required3acceptedDECISION COMPLETE4rejectedDECISION COMPLETE5acceptedDECISION COMPLETE6rejectedDECISION COMPLETE
Review or pendingResult or outcomeException or stop
fraud.statusMeaningMerchant handling
pendingFraud screening has not produced an overall result.Keep the configured review policy active and evaluate payment state separately.
in_reviewFurther review or asynchronous analysis is required.Wait for a completed fraud decision. Do not fulfill solely because the payment advanced.
acceptedThe overall fraud process accepted the transaction.Continue according to policy, then check the actual payment status.
rejectedThe overall fraud process rejected the transaction.Apply the configured decline or reversal policy, then verify any required refund or void from the payment status.

Provider analysis#

fraud.analysis.status describes how the selected anti-fraud provider produced or is producing its analysis. The API does not define one universal transition sequence across all providers, so treat these as provider-analysis results—not as a second payment state machine.

Flow diagram
Still runningAutomated policyReview requiredAcceptance resultDenial result1Provider analysis2pending_analysisWaiting3automatic_decisionAutomated result4manual_reviewHuman review5acceptedProvider accepted6deniedProvider denied
Provider or processorReview or pendingResult or outcomeException or stop

automatic_decision says how the analysis was produced; it is not by itself an approval. Read fraud.analysis.fraud_decision, risk level, score, and details together. Provider-specific response fields can contain additional diagnostic values and must not replace the normalized public fields.

Pre-authorization and post-authorization flows#

Fraud screening can run before or after the processor operation according to the configured route.

Sequence diagram
1Merchant backend2DEUNA3Anti-fraud provider4Payment providerCreate paymentPre-authorization evaluation whenconfiguredFraud decisionPurchase or authorization when policyallowsPayment resultPost-authorization evaluation whenconfiguredFraud decisionFraud fields + payment status
Merchant or customerDEUNAProvider or processor

In a post-authorization rejection, an authorization or collected payment can already exist. Follow the configured policy and confirm the actual payment.data.status; do not assume that the fraud response completed a void or refund.

Fraud provider selection, pre/post-authorization timing, manual review, and the resulting reversal behavior depend on merchant and processor configuration. Ask your DEUNA TAM to confirm and enable the required behavior.

Handle updates safely#

  1. Store fraud.status, fraud.analysis.status, fraud.analysis.fraud_decision, and payment.data.status separately.
  2. Keep fulfillment blocked while the applicable fraud policy is pending or in review.
  3. Treat fraud acceptance as permission to continue the configured flow, not as financial confirmation.
  4. After fraud rejection, inspect the payment history and wait for any required voided or refunded result.
  5. Process repeated webhooks idempotently and preserve provider references for reconciliation.
  6. Preserve unknown values and reconcile them; never map an unknown fraud value to payment success.

See Payment workflow and statuses for financial transitions and DEUNA Webhooks for notification setup.