Payment Context in the SDK

When you score a browser session that belongs to a payment, add the payment's identifiers to the identity client. They are attached to every request the SDK makes, so the analysis — and every event after it — is queryable against the payment it belongs to. This is the same headless Web SDK; this page covers only the payment-specific config.

Nothing here changes what the SDK does. analyze() still returns the risk snapshot and you still own the decision. The payment fields are correlation context — they tag the analysis so it can be tied back to the payment later.

The payment config fields

Field	Purpose
`paymentId`	The payment this analysis belongs to. Attached to every identity request.
`checkoutSessionId`	The checkout session, when a payment id does not exist yet.
`subjectId`	Who you are scoring (your customer id). Falls back to the payment ids if omitted — see below.
`includeFraudDecision`	Optional flag asking the analysis to also carry a fraud decision. See the caveat below.

const client = await Lunixi.identity.init({
  sessionBootstrapUrl: '/lunixi/identity/session',
  subjectId: 'cus_8f2a9c',
  paymentId: 'pay_01HV3K...',
  checkoutSessionId: 'cks_7bd2...',
  productContext: 'checkout',
  includeFraudDecision: false,
});
const snapshot = await client.analyze();

Subject fallback

subjectId is the identity the analysis is filed under. If you do not set it, the SDK falls back so the analysis is never anonymous:

`subjectId`

Used as-is when present.

`paymentId`

If subjectId is absent, the payment id becomes the subject.

`checkoutSessionId`

If neither is present, the checkout session id becomes the subject.

⚠️

Set an explicit subjectId (your stable customer id) whenever you have one. Falling back to a paymentId files each payment under a different subject, which fragments the per-subject continuity history the snapshot is built on.

traceId correlation

analyze() returns a traceId in the response envelope (meta.traceId). The SDK carries that same traceId onto the track() / trackBatch() events that follow, so one analysis and all of its downstream events share a single correlation id.

const snapshot = await client.analyze();
// meta.traceId ties this analysis to the events below
await client.track('checkout_step', { step: 'review' });

Because the analysis is also tagged with paymentId / checkoutSessionId, you can later line up the identity trace, its events and the payment from either side.

The includeFraudDecision flag

includeFraudDecision is a strict boolean, default off. It is a request-shaping flag: it asks the analysis to also carry a fraud decision alongside the snapshot.

⚠️

Treat includeFraudDecision as an optional request flag, not a guarantee. Setting it does not promise a fraud decision comes back in the SDK response — whether one is populated depends on backend configuration for your account. Do not build client logic that requires a fraud verdict from this flag. When you want fraud to actually weigh on the payment, that happens on the server via the payment risk mode, not here — see Identity in the Payment Decision.

Next steps

Checkout Analysis Flow — how the hosted form binds identity to a payment without the SDK.
Identity in the Payment Decision — when identity evidence actually weighs on the outcome.
Web SDK — the full SDK reference: methods, config, token rotation, error handling.
The Risk Snapshot — every field analyze() returns.

Overview Checkout Analysis Flow