Anti-fraud customization
Design, test, and operate fraud signals, provider decisions, routing, and outcome feedback without coupling fulfillment to a browser result.
On this page
Customize fraud controls as an end-to-end decision system: collect permitted signals, ask the configured provider for a decision, translate that decision into a payment action, and return confirmed outcomes so the model can improve.
Fraud decision lifecycle#
01 · observe
Collect approved signals
Send accurate order, customer, seller, address, and device context that the selected provider supports.
02 · assess
Evaluate risk
DEUNA invokes the active anti-fraud connection at the configured point in the payment strategy.
03 · act
Apply the policy
Continue, require authentication, hold for review, route differently, or decline according to the standardized result.
04 · confirm
Reconcile payment state
Use the authoritative payment state or a verified webhook before fulfillment.
05 · learn
Return outcomes
Send agreed fraud and chargeback outcomes so the provider can evaluate model performance.
Flow diagram
Risk level alone is not a payment result. A low-risk transaction can still be declined by a processor, and a completed authentication can still be followed by an unsuccessful authorization. Keep fraud, authentication, and payment state as separate fields.
Choose the customization task#
Device fingerprintGenerate and forward the device identifier expected by the configured fraud or payment provider.Web and supported SDK flowsShadow modeCompare provider decisions on production-shaped traffic before a new model affects the customer journey.Observe without blockingOutcome feedbackSend agreed historical chargeback outcomes without confusing feedback ingestion with dispute management.Email or provisioned SFTPPayment strategiesPlace fraud evaluation before or after authorization and define the action for each supported result.Decision to actionFraud statusesModel fraud evaluation separately from the financial lifecycle and manual-review state.State and decisionsProvider capabilitiesConfirm where each anti-fraud provider is published and open its connection guide.Country and capability filters
Decide where fraud runs#
| Placement | What it protects | Main trade-off | Required handling |
|---|---|---|---|
| Before authorization | Avoids sending policy-blocked attempts to the processor | A fraud timeout can delay or stop the payment before an authorization exists | Define timeout and fallback behavior; do not invent a payment result |
| After authorization | Lets the provider evaluate processor and authorization context | An approved authorization may need to be voided when risk rejects the order | Keep fulfillment blocked and verify the void or capture outcome |
| Shadow mode | Measures a provider without changing payment decisions | Results are observational and must not silently become enforcement | Separate comparison metrics from live routing inputs |
| Manual review | Adds a human or provider review before the final action | The customer and fulfillment flow remain pending longer | Treat manual_review as unresolved and consume the later authoritative state |
Use Dynamic authentication when the fraud result selects a verification control such as 3DS. Use Manual review for held transactions and 3DS for issuer authentication behavior.
Signal contract#
Send only data that is accurate, permitted, and supported by the selected provider. More fields do not automatically produce a better decision.
| Signal group | Examples | Integration rule |
|---|---|---|
| Order | Amount, currency, items, shipping, discounts | Keep totals consistent with the order processed by the backend |
| Customer | Stable customer reference, account history, contact context | Do not place secret credentials or unrelated personal data in free-form fields |
| Device | Provider-compatible fingerprint or device session identifier | Generate it in the supported client flow and bind it to the same order attempt |
| Marketplace | Seller identifiers and approved seller attributes | Confirm which marketplace_sellers fields the provider actually consumes |
| Outcome | Payment result, confirmed fraud, or agreed chargeback state | Send idempotently with the DEUNA transaction identifier |
Roll out safely#
- Confirm support. Choose the provider, markets, channels, and evaluation placement from the published capability and commercial contract.
- Define the policy. Write the action for every supported provider result, timeout, unavailable response, and manual-review outcome.
- Map signals. Document the authoritative source, format, consent basis, and fallback for every field you send.
- Validate in sandbox. Exercise low, medium, high, unavailable, timeout, duplicate, and malformed-signal cases.
- Compare in shadow mode. Measure coverage and disagreement before switching a new provider or model into enforcement.
- Release gradually. Monitor approval, challenge, review, false-positive, fraud, and payment outcomes together.
- Close the loop. Return approved outcomes through the chargeback feedback workflow.
Operating checklist#
- Keep private provider credentials in DEUNA Admin or a protected backend, never in browser or mobile code.
- Correlate the fraud evaluation, payment attempt, order, and later outcome with stable identifiers.
- Make retries idempotent; a client timeout is not proof that an evaluation or payment failed.
- Preserve the raw provider reference required for support while exposing only the normalized decision to business logic.
- Alert on missing device data, evaluation latency, unavailable responses, decision drift, and feedback-processing failures.
- Revalidate the strategy whenever a provider, SDK, market, or required signal changes.