Skip to content

Going live

Before you can mint a pb_sk_live_ key, your integration runs through a go-live checklist. You can see it any time in the portal under Account → Developers → checklist, where each check shows its current state and what’s left to satisfy it.

The checklist is a fixed set of six checks. Some are mandatory and gate the live key; some are advisory and never block you.

  1. Sandbox key used (mandatory) — you’ve made at least one API call with a test-mode key. This confirms your credentials work end to end.
  2. Sandbox session completed (mandatory) — you’ve driven at least one sandbox verification session all the way to completed, so you’ve exercised the full lifecycle at least once.
  3. Webhook consumption (advisory) — your endpoint successfully received a sandbox verification_session.completed delivery. Informational: it doesn’t block go-live, but it’s the clearest signal your handler is wired up.
  4. Live callback reachable (conditional) — every live webhook endpoint you’ve registered has received a successful reachability ping. This check is not applicable until you register a live endpoint; once you have one, it must pass.
  5. Return origin registered (advisory) — you have at least one registered return-URL origin (from a webhook endpoint, a store key, or plugin config). Advisory only.
  6. Account ready (mandatory) — your KYB is approved and your billing is active. These are business-critical gates, so this is the one check that can never be waived by anyone.

Live-key minting is blocked until every gating check is satisfied. If you try before then, the request fails with go_live_checklist_incomplete and lists exactly which checks are still outstanding — fix those, or ask an admin to waive an eligible one, and try again.

Once the checklist passes, you mint the pb_sk_live_ key from the same Developers tab you used for your sandbox key. Like the test key, it’s shown once — store it immediately. Your API and SDK integration is otherwise identical; only the key prefix changes.

Live mode runs the real pipeline, so two behaviors that don’t exist in the sandbox come into effect:

  • Writes are billing-gated. Live-mode write operations require an active billing account. If your account is frozen for non-payment, those writes are refused with 402 account_past_due until payment is resolved. Live-mode reads are always available, even past due.
  • Return URLs must be registered. A live session’s return_url origin must be on your allowlisted origins (the same registered origins that satisfy check 5). An unregistered origin is rejected — this is what keeps a live session from redirecting a customer to a domain you don’t control.

Neither restriction applies in the sandbox, which is why an integration that worked perfectly against a test key can still surface these on its first live call. Register your production origins and confirm billing is active before you flip the switch.