Checkout Analysis Flow
The hosted Checkout Form runs an identity analysis for you at the start of a payment. It bootstraps a live identity session, binds the resulting snapshot and a signed assertion to the payment intent, and — unlike the rest of the Identity–Payment plumbing — this one call is customer-visible: the checkout form makes it in the browser. This page walks the flow end to end.
This is the one place on the payment path where an identity bootstrap is a visible browser request. Everything downstream of it (resolving the snapshot into fraud, feeding profiles back) is platform-internal gRPC you never call.
The bootstrap call
At the start of checkout the form issues:
POST api/v1/payments/form/live-analyzeThis is a payment-service call — it is the payment stack, not Identity, that owns the endpoint. Internally it drives an identity live analysis, but you (and your buyer's browser) only see this single payment-form request.
How it works
The form bootstraps a live session
The checkout form calls POST api/v1/payments/form/live-analyze. The payment stack runs a live identity analysis for the session behind it.
Identity produces a snapshot and a signed assertion
Identity returns the IdentityDecisionSnapshot plus a signed identity assertion — an asymmetrically signed statement of the snapshot that a downstream service can verify rather than trust blindly. See Assertions & JWKS.
Both are bound to the payment intent
The snapshot and assertion are written into the payment intent (intent.metadata), and browserFingerprint is filled on the intent. A sessionProof cookie is issued to the browser, tying that browser to this payment session.
The payment proceeds with identity attached
From here the payment continues with the identity evidence bound to it — ready to be weighed if you have enabled the external risk mode (see Identity in the Payment Decision).
What gets bound
| Artifact | Where it lands |
|---|---|
| Identity snapshot | intent.metadata on the payment intent |
| Signed identity assertion | intent.metadata (verifiable via JWKS) |
browserFingerprint | Filled on the intent |
sessionProof | A cookie issued to the buyer's browser |
The mandatory pre-condition
The bootstrap is a required gate, not an optional enrichment. The payment cannot proceed on an empty or incomplete identity analysis.
If the analysis did not finish — analysisStatus is anything other than completed, or the snapshot / assertion came back empty — the payment is stopped with RISK_CHECK_FAILED. A completed identity bootstrap is a hard pre-condition for the intent to move forward; there is no silent skip.
| Condition | Outcome |
|---|---|
analysisStatus === 'completed' with snapshot + assertion | Bound to the intent; payment proceeds |
analysisStatus !== 'completed' | RISK_CHECK_FAILED |
| Empty snapshot or assertion | RISK_CHECK_FAILED |
Next steps
- Identity in the Payment Decision — what the bound snapshot does once it is attached.
- Checkout Form — the hosted payment form that runs this bootstrap.
- Assertions & JWKS — verifying the signed identity assertion.
- The Risk Snapshot — every field bound to the intent.