A sandbox proves that your code handles the vendor's test cases. It cannot prove real card network behavior, real bank delays, real customer mistakes or the settings of your live account. Plan a small, watched live test after launch, and keep a list of what the sandbox could not confirm.
What a sandbox is for
One payment provider describes a sandbox as an isolated test environment. Payments created there are not processed by card networks or payment providers. You can simulate events without moving money, give each team its own sandbox, and invite an external partner to a sandbox without exposing live data. It advises separate sandboxes for local development and continuous integration so automated tests do not affect other settings or data.
That is valuable. It is also the reason for the gaps below.
Gaps to plan for
| Gap | Why the sandbox cannot cover it | What to do |
|---|---|---|
| Real network responses | Payments are not processed by networks or providers | Run a low value live test and watch it end to end |
| Objects and IDs | Sandbox objects are not usable in live mode | Recreate them in live with the same IDs |
| Webhook endpoints | Test and live endpoints are separate | Register and verify live endpoints |
| Keys and secrets | Each mode has its own keys | Rotate and store live ones properly |
| Account settings | Live configuration can differ | Compare settings side by side |
| Feature limits | Some features cannot be tested in a sandbox | Read the vendor's limitations page |
| Timing | Real bank steps can be slow | Test late and out of order events |
| Human behavior | Customers abandon, double click and use odd cards | Test duplicates and cancellations |
The documentation itself lists limits: for example, one pricing model cannot be tested in a sandbox, and connections between a platform sandbox and connected account sandboxes are not possible.
Make the live test safe
- Use a restricted live key with a short expiry, if offered.
- Run one low value transaction with a card you control.
- Watch the webhook delivery, the order status and your logs together.
- Refund it and check the refund event as well.
- Confirm receipts and notifications reach the right place.
- Revoke the test key, or keep it only if the live service needs it.
What else to verify
- Duplicate delivery and out of order events, as in out of order webhook events.
- Failure paths, such as declines and timeouts, covered in what to do when a payment times out.
- Test card hygiene, so test data never mixes into production: test payment cards and sandbox data in staging.
Write down the untested list
Keep a short note: what was tested, in which environment, and what was only assumed. That note is useful to reviewers, auditors and your future self.
Where Safeguard fits
Safeguard's compliance and evidence automation can help keep records of test and review results for audits. A free scan can check your dependencies before launch.
Quick check
Is passing every sandbox test enough to launch?
No. It proves your code against test data. Add a small live test and review account settings, webhooks and keys for live mode.
Can I reuse sandbox object IDs in live mode?
Objects themselves do not carry over. Recreate them in live mode, using the same ID values so your code keeps working.
Sources
- Sandboxes, Stripe documentation
- Go-live checklist, Stripe documentation
- API keys, Stripe documentation
Last reviewed: 19 October 2026.
