Identity with Payment
When you take payments on Lunixi, Identity rides along as the evidence layer underneath checkout. It never charges, never blocks and never approves — it produces a signed risk snapshot that the payment stack can carry and, when you turn it on, weigh. This page maps the two places Identity and Payment touch, what flows across each, and how that evidence reaches the payment decision.
Identity is a standalone evidence provider. On the payment path it contributes device, network, behavioral and bot signals plus its own identityRiskLevel verdict. The action — allow, add a 3DS step-up, or fail — is always the payment stack's, not Identity's.
Two surfaces
Identity meets Payment in exactly two places. One you script yourself; the other the hosted checkout form does for you.
| Surface | Who drives it | What it is |
|---|---|---|
| The Web SDK | You, in the browser | You add payment context (paymentId, checkoutSessionId) to the identity client so an analysis is tied to the payment it belongs to. See Payment Context in the SDK. |
| Checkout live-analyze | The hosted checkout form | The form bootstraps an identity session at POST api/v1/payments/form/live-analyze; the snapshot and a signed assertion are bound to the payment intent. See Checkout Analysis Flow. |
Everything else between Payment and Identity is platform-internal gRPC — service-to-service calls guarded by an internal auth token. You never call those directly. When this section says "the payment stack resolves the snapshot" or "carries it to fraud", that is platform plumbing, not an endpoint you invoke.
What flows
Across those two surfaces, the same evidence moves in one direction — from Identity into the payment intent:
- Identity snapshot — the
IdentityDecisionSnapshot: scores, per-family signals,identityRiskLevel,reasonCodes,findings. - Signed identity assertion — an asymmetrically signed statement of the snapshot, so a downstream service can verify provenance rather than trust an inline blob. See Assertions & JWKS.
- Correlation ids —
paymentId,checkoutSessionIdand thetraceIdreturned byanalyze, so an analysis, its events and the payment all line up. - Browser fingerprint & session proof — the checkout bootstrap fills
browserFingerprinton the intent and issues asessionProofcookie that ties the browser to the payment.
Evidence to decision, end to end
Collect
The SDK collects telemetry in the browser, or the checkout form bootstraps a live session. Either way Identity produces a snapshot and, on the checkout path, a signed assertion.
Bind
The snapshot and assertion are attached to the payment intent (intent.metadata). On the checkout path this is a hard pre-condition: if the analysis did not complete, the intent is rejected before authorization. See Checkout Analysis Flow.
Decide
The payment stack's risk gateway reads the bound evidence only when you have enabled the external risk mode. In the default mode, identity evidence is carried but does not drive the payment decision. See Identity in the Payment Decision.
Feed back
Whatever the outcome, the payment path can hand the decision back to Identity so its per-subject risk profile keeps learning. This is best-effort and not guaranteed to complete.
Where to go next
New to the payment product itself? Start with the Payments overview and Checkout Form, then come back here for the Identity layer.
- Payment Context in the SDK — tie an analysis to a payment with
paymentId/checkoutSessionId. - Checkout Analysis Flow — the hosted-form
form/live-analyzebootstrap, step by step. - Identity in the Payment Decision — how (and when) identity evidence weighs on the outcome.
- The Risk Snapshot — every field the evidence layer carries.