Before you switch from sandbox to live, rotate the keys used during development, register live webhook endpoints, set the API version on purpose, test duplicate and invalid input, and check that your logs hold no card data or personal details. Swapping keys is the easy part. The rest is where mistakes hide.
Why a checklist helps
Payment providers design live and sandbox to behave alike, so switching is mostly a matter of swapping API keys. That similarity is the trap. It feels like a small change, and nothing forces you to look at what else differs. One provider's go-live checklist lists the items below, and they apply to messaging and identity vendors too.
The checklist
| Item | What to do |
|---|---|
| API version | Set it on purpose rather than inheriting the account default |
| Edge cases | Test incomplete, invalid and duplicate data, and have someone else try it |
| Error handling | Handle every error type, including ones that "never" happen |
| Logging | Keep your own logs, and make sure they hold only what you need |
| Test objects | Do not rely on sandbox objects, since they are not usable in live mode |
| Webhooks | Register live endpoints and confirm they behave like the test ones |
| Keys | Rotate before launch and confirm none are in code |
Walk through each one
API version. Requests use your account settings unless you override the version, and webhook payloads follow the account version unless you set one when creating the endpoint. In strongly typed languages, the server library pins a version based on the library release. Know which one you have.
Edge cases. Send the same request twice. Send a malformed one. See what the customer sees. The documentation separates a card decline from a backend error and asks you to look closely at what you show users.
Logging. Provider logs record requests made with your keys, but your own logs are the backup if your server cannot reach the provider or your keys are wrong. Review them regularly and keep card details and personally identifiable information out.
Test objects. Products, plans and coupons made in a sandbox do not exist in live mode. When you recreate them, use the same IDs so code that references them keeps working.
Webhooks. Test and live webhook endpoints are separate. Confirm the live one handles delayed notifications, duplicates and out of order events. See out of order webhook events.
Keys. Rotate keys that were used in development in case they were saved somewhere outside the codebase, and check that nothing in code contains one. See build and test with sandbox keys, not live keys.
Add security items the vendor will not do for you
- Keep live keys in a vault with a named owner.
- Use restricted keys per service where offered.
- Turn on usage and spend alerts in the vendor console.
- Write down how to revoke each key and who can do it.
- Confirm the webhook endpoint verifies signatures and rejects stale timestamps.
- List the integration in your asset inventory and third party register.
Try it yourself
Click through it at your own pace, or open it full screen. Look for the vendor SDK in the inventory and its version.
Where Safeguard fits
Safeguard's SBOM and dependency scanning list the SDKs you ship, and compliance evidence automation can attach proof that the checks were done. Start with a free scan.
Quick check
Is swapping keys enough to go live?
No. You also need live webhooks, objects recreated in live mode, a deliberate API version and tested error paths.
Should I keep logging after launch?
Yes, on your side as well as the vendor's, but review it so it stores no card details or unnecessary personal data.
Sources
- Go-live checklist, Stripe documentation
- Sandboxes, Stripe documentation
Last reviewed: 19 October 2026.
