> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chmodlab.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Go-live checklist

> Everything to confirm before the first real user sees the flow.

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.

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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](/api-reference/errors).
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Info>
  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.
</Info>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.