Skip to main content
Work through this once your integration is complete and before the first real user sees the flow. Most items take minutes; skipping them costs hours later.
1

Account and credentials

  • You have received your API host, OAuth token URL and client credentials from your account manager.
  • They are stored in your secret manager and read only by your backend.
2

Customers

  • The customer id is persisted against your user record and reused on every transaction.
  • The first verification for every customer is document and biometric, so the reference face gets enrolled before any biometric-only step-up relies on it.
3

Transaction configuration

  • The accepted-documents list names exactly the countries and types you accept. Nothing you tested with that you do not actually want.
  • Thresholds are at the defaults unless you have measured a reason to move them.
  • New or unproven rules are set to warn, so you can watch them before they reject anyone.
  • Emulator and compromised-device detection are set to reject.
  • The time limit matches how the flow is delivered — short for in-app, long only for links sent out of band.
  • The webhook URL points at your live endpoint.
4

Webhooks

  • The endpoint is public, HTTPS, and answers quickly.
  • It verifies the signature and the timestamp window.
  • It is idempotent.
  • It fetches the transaction rather than trusting the body.
  • A reconciliation job covers transactions that never reach a terminal status.
5

Mobile app

  • Release builds are tested, not just debug builds — the minified build on Android, the archived build on iOS.
  • The iOS permission descriptions and the ProMotion setting are in place; the location description too if you request location.
  • Permission strings are localised for every language you ship.
  • The SDK’s location setting matches your GPS rules: if a GPS rule is active, the SDK asks for location.
  • Detailed error output is turned off.
  • The app shows “we’re reviewing” on completed, not “approved”.
  • The app handles cancelled gracefully and failed codes specifically, with a fallback branch for codes from newer SDKs.
  • Retries are capped and there is a path to human support.
  • The SDK version you ship is the one you tested.
6

Backend handling

  • Approved, rejected and undetermined each take a different path.
  • Finding codes are mapped to user-facing copy; messages are logged, not shown.
  • Fraud-signal findings route to manual review.
  • The full result is not written to logs, and only the fields you act on are stored.
  • API errors are retried only when safe to retry.
7

Monitoring

  • Dashboards for decision rates (approved / rejected / undetermined) and the top finding codes.
  • An alert on the rate of undetermined decisions.
  • An alert on webhook delivery failures and API server errors.
  • The completion funnel: transactions created → initiated → completed → finished. A drop between created and initiated means users are not reaching the SDK; a drop between initiated and completed means they are abandoning inside it.
8

The last test

  • One complete verification, on a real device, with a real document belonging to someone on your team — through the release build, all the way to a decision arriving on your webhook.
After launch, test configuration changes and SDK upgrades against your own team’s devices before they reach real users. A rule promoted from warn to reject is the kind of change that deserves a rehearsal.