Fraud Workflow and Statuses

Keep fraud fields separate from payment status. Read each value from its actual field.

This guide explains fraud screening and its relationship to payment handling. Fraud fields are not the payment field, even when their literal values coincide. A fraud acceptance does not confirm authorization, capture, or settlement.

The API exposes two distinct fraud fields:

Field	Purpose	Native values
`fraud.status`	Overall fraud-process outcome. In an order-wrapped payload: `order.fraud.status`.	`pending`, `in_review`, `accepted`, `rejected`.
`fraud.analysis.status`	Provider-analysis detail. In an order-wrapped payload: `order.fraud.analysis.status`.	`automatic_decision`, `pending_analysis`, `accepted`, `denied`.

Overall fraud process

The following diagram applies only to fraud.status. Rounded accepted/rejected nodes indicate completion of that fraud decision, not terminal payment states.

flowchart TB
    f_pending["pending"]
    f_accepted(["accepted<br/>DECISION COMPLETE"])
    f_accepted_review(["accepted<br/>DECISION COMPLETE"])
    f_rejected(["rejected<br/>DECISION COMPLETE"])
    f_rejected_review(["rejected<br/>DECISION COMPLETE"])
    f_in_review["in_review"]
    f_pending -->|"Immediate acceptance"| f_accepted
    f_pending -->|"Immediate rejection"| f_rejected
    f_pending -->|"Review required"| f_in_review
    f_in_review -->|"Accepted"| f_accepted_review
    f_in_review -->|"Rejected"| f_rejected_review
    classDef waiting fill:#FFF4CC,stroke:#967000,color:#172B4D,stroke-width:2px;
    class f_pending,f_in_review waiting;
    classDef accepted fill:#DFF3E8,stroke:#137447,color:#172B4D,stroke-width:2px;
    class f_accepted,f_accepted_review accepted;
    classDef rejected fill:#FDE8E7,stroke:#B42318,color:#172B4D,stroke-width:2px;
    class f_rejected,f_rejected_review rejected;

Fraud status	Meaning	Payment handling
`pending`	Fraud screening is awaiting a result.	Apply the configured review policy. Do not assume payment approval.
`in_review`	The fraud process requires further review or asynchronous analysis.	Await the fraud outcome and retain the payment's actual state independently.
`accepted`	The overall fraud process accepted the transaction.	Continue or release the applicable payment step according to policy. Check the payment result separately.
`rejected`	The overall fraud process rejected the transaction.	Apply the configured decline or reversal policy. A rejection alone does not prove that previously authorized or collected funds were reversed.

Provider-analysis detail

The following table describes fraud.analysis.status only. Matching literals in other fields have their own semantics:

Analysis status	Meaning
`automatic_decision`	The provider reports an automated analysis decision. Consult its accompanying decision details; this label alone is not approval.
`pending_analysis`	Provider analysis is pending.
`accepted`	Provider analysis reports acceptance.
`denied`	Provider analysis reports denial. This is distinct from the terminal payment outcome in `payment.data.status`.

Do not combine fraud.status, fraud.analysis.status, and payment.data.status into one enum. Their relationship is controlled by the configured pre-authorization or post-authorization fraud policy. The published schema lists the analysis values but does not specify a universal transition matrix for every fraud provider, so this guide does not invent one.

Handle fraud and payment updates

Keep fraud decisions and financial results in separate fields. A completed fraud decision does not confirm a payment or a reversal. Apply the configured fraud policy, then read the actual payment result.

See Payment Workflow & Statuses for payment handling and DEUNA Webhooks for notification setup.