Identity in the Payment Decision
Once a snapshot is bound to a payment intent, whether it actually weighs on the outcome depends on one platform setting — the payment risk mode. This page is honest about the default: in a standard install, identity evidence is carried but does not drive the payment decision. It only reaches the decision when the external risk mode is enabled.
You do not call an endpoint to "run the identity check" on a payment. The risk stage is built into the payment stack. What you control is whether it consults external evidence — by enabling PAYMENT_RISK_MODE=EXTERNAL. Everything below is platform behavior, not an API you invoke.
PAYMENT_RISK_MODE
The payment stack's risk stage runs in one of three modes:
| Mode | What it does | Uses identity? |
|---|---|---|
DISABLED | Always allows — the risk stage is a pass-through. | No |
BASIC | Default. Heuristic checks on amount, currency, IP and fingerprint. Does not read the identity snapshot. | No |
EXTERNAL | Carries the bound snapshot + signed assertion to the fraud service and takes its decision. | Yes |
The default is BASIC — so out of the box, identity does not influence the payment decision. The snapshot is still collected, bound to the intent and available for querying and analytics, but it is not consulted at the point of allow/decline until you enable EXTERNAL. Frame any "identity blocks a payment" expectation against this: it only happens once the external mode is turned on.
What EXTERNAL does
In EXTERNAL mode the payment stack hands the bound identity snapshot and its signed assertion to the fraud service (over platform-internal gRPC — not a call you make), and maps the fraud service's decision back onto the payment:
| Fraud decision | Payment outcome |
|---|---|
force_3d | 3DS step-up — the payment is escalated to 3D Secure |
block | The payment fails |
review | Escalated to force_3d; if the payment is already forced-3D, it becomes block |
The mapping is a payment-side translation of a fraud verdict. Identity supplies the evidence the fraud service reasons over; it does not itself emit force_3d or block. For how the snapshot is resolved and weighed inside fraud, see Identity with Fraud.
Where identityRiskLevel sits
You might expect the snapshot's identityRiskLevel to branch the payment directly. It does not.
identityRiskLevel is carried inside the snapshot but is not read as a direct branch in the payment decision today. There is no rule that says "if identityRiskLevel is high, force 3DS." What drives the outcome in EXTERNAL mode is the fraud service's decision — which reasons over the snapshot's device and network signals (and its own logic) — not a direct switch on the identity level. So identity's influence is indirect, through fraud.
RISK_CHECK events
The payment risk stage emits events you can observe on the payment:
| Event | Meaning |
|---|---|
RISK_CHECK_PASSED | The risk stage completed and allowed the payment to proceed |
RISK_CHECK_FAILED | The risk stage stopped the payment — including the checkout bootstrap pre-condition failing (missing/incomplete snapshot) |
Turning it on
Enabling EXTERNAL is a platform configuration change for your account, not a code path you toggle per request. Because the default is BASIC, plan the switch deliberately: once EXTERNAL is on, fraud verdicts can escalate payments to 3DS or fail them, which is a real change in buyer experience and approval rates.
Next steps
- Checkout Analysis Flow — how the snapshot gets bound before the decision.
- Identity with Fraud — how the fraud service resolves and weighs the snapshot.
- 3D Secure — what a
force_3dstep-up does to the payment. - The Risk Snapshot — the evidence the decision reasons over.