Skip to main content

Sandbox and go-live

Use this checklist after you complete the Quickstart. Work entirely in sandbox until every item passes, then switch environments for production.

Sandbox testing​

Account and access​

  • Organization exists and you can sign in to the dashboard
  • Dashboard is in sandbox mode
  • At least one Admin or Developer can manage flows and API keys, roles
  • Reviewers (Operator / AML Officer) can open flow results without over-privileged access, PII access

Flow and happy path​

  • A KYC flow exists with the steps you need (for example Document Verification + Liveness)
  • You can complete a full verification yourself in sandbox
  • Flow result status reaches a terminal state you understand, statuses
  • Public link works if you use hosted UI, sharing
  • SDK path works if you embed, SDKs

Webhooks​

  • Webhook URL is HTTPS and reachable from the internet (or a tunnel in local dev)
  • Signature verification uses the raw body and organization secret, signature
  • Handler returns 200 OK quickly; heavy work is async
  • Handler is idempotent (retries are expected)
  • You tested COMPLETED, FAILED, and REVIEW (if manual review is enabled), failure and review
  • You reconciled events with your own user id via custom fields
  • Optional: use flow developer tools to trigger and monitor deliveries before real traffic

Review and scoring​

  • Operators can approve / reject results, manual review
  • Scores appear as expected if configured, scoring
  • Your product does not reject on REVIEW; it waits for the final event

Optional products (if in scope)​

  • KYB sandbox application completes and is reviewable, KYB
  • AML screening results and risk score are understood, AML
  • Transaction monitoring rules evaluate sandbox events with Allow / Review / Block, TM
  • KYC Passport invitation path tested with a partner org, KYC Passport
  • MCP / bot token can list or create flows only where you intend automation, MCP

Go-live checklist​

Credentials and environments​

  • Create production API keys; never reuse sandbox keys in production clients
  • Store secrets in a server-side secret manager (API keys, webhook secret, bot tokens)
  • Confirm environment selection in the Node SDK / server config (staging vs production as applicable)
  • Rotate any key that was ever committed or shared in chat

Webhooks and networking​

  • Production webhook URL points at production infrastructure
  • Signature verification enabled and failing closed (reject invalid signatures)
  • Timeouts and retries in your queue are sensible; endpoint stays under delivery limits
  • Alerting exists for webhook processing failures

Product configuration​

  • Production flows mirror sandbox (steps, thresholds, success URL, branding), theming
  • Country / document filters match your compliance policy
  • Minimum age and score thresholds reviewed with compliance
  • Manual review routing and reviewer roles assigned
  • Billing products enabled for what you will charge, billing

Privacy and access​

  • Role assignments follow least privilege, Manage users
  • Extended webhook / PII fields only enabled where contracts and access control allow
  • Data retention and deletion process understood, data deletion

Observability​

  • You log resultId, verification request id, and your own external user id for support
  • You can map webhook statuses using Statuses and codes
  • Runbook exists for REVIEW backlog and elevated failure rates

Cutover​

  • Smoke-test one real production verification with a controlled account
  • Confirm production webhook delivery and dashboard result
  • Switch client traffic from sandbox links / keys to production
  • Keep sandbox for ongoing QA and rule backtests
  1. Quickstart, first reviewed result in sandbox
  2. This page, full sandbox matrix for your product scope
  3. Choosing an integration method, lock public link vs SDK vs MCP
  4. Production credentials + webhook + smoke test
  5. Enable additional products (AML, TM, Passport) with the same sandbox-first habit