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 six checks
Section titled “The six checks”The checklist is a fixed set of six checks. Some are mandatory and gate the live key; some are advisory and never block you.
- 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.
- 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. - Webhook consumption (advisory) — your endpoint successfully received a sandbox
verification_session.completeddelivery. Informational: it doesn’t block go-live, but it’s the clearest signal your handler is wired up. - 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.
- 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.
- 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.
Minting the live key
Section titled “Minting the live key”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.
What’s different in live mode
Section titled “What’s different in live mode”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_dueuntil payment is resolved. Live-mode reads are always available, even past due. - Return URLs must be registered. A live session’s
return_urlorigin 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.