Implementation patterns
Start from the action you protect.
Each guide connects collection timing, a conservative probe profile, the mobile payload, and the backend contract for one real product flow.
- Backend creates an opaque action ID.
- App collects only purpose-approved probes.
- Host API sends the raw event with authentication.
- Backend validates freshness and action ownership.
- Policy combines observations with server evidence.
Choose the product flow
The SDK stays the same. What changes is when collection happens, which fields are justified, and which server-owned action receives the event.
Authentication
Attach current device context to a login attempt without treating client telemetry as proof of identity.
Implement login contextPayments and checkout
Bind pre-confirmation observations to a payment attempt and optionally use the two-stage transaction window.
Implement payment contextAccount recovery
Add investigation context while preserving a usable recovery path when telemetry is absent or unusual.
Implement recovery contextPromotion abuse
Correlate redemption context with account, campaign, and server history while minimizing location and telephony data.
Implement redemption contextProtected actions
Collect around payout changes, new beneficiaries, password changes, or security-setting updates.
Implement action contextCollection recipes
Use compact probe profiles when you already understand the full mobile and backend lifecycle.
Compare profilesWhat every implementation keeps constant
Use a short-lived login, payment, recovery, redemption, or protected-action ID. Do not invent a persistent device ID.
Use consentFor(...), disable unnecessary probes, and project fields before the event leaves the app.
Preserve success, skipped, timeout, error, omitted values, and observed false.
The SDK does not calculate a risk score, produce a verdict, upload data, or make a blocking decision.