Use sandbox keys. A sandbox is an isolated test environment with its own keys and data, so a bug, a loop or a leaked key in testing cannot touch real customers or money. Switch to live keys only at launch, from a secrets manager, with restricted permissions.
What a sandbox gives you
Stripe's documentation describes a sandbox as an isolated test environment that lets you try functionality without affecting your live integration. Each mode has its own set of keys, and objects in one mode are not accessible to the other. A test product cannot be part of a live payment. Test keys carry a visible prefix, so you can tell them apart at a glance.
That separation is a security control as well as a convenience.
| Risk in testing | With live keys | With sandbox keys |
|---|---|---|
| A loop sends 10,000 requests | Real charges, emails or deletions | Simulated objects |
| A key is pasted into a ticket | Real credential exposed | Low-value credential |
| A new teammate experiments | Can change real records | Safe to try |
| A bug writes wrong data | Customers see it | Nobody sees it |
Steps for a clean separation
- Create a separate sandbox for each new integration, so settings and data stay isolated.
- Keep sandbox and live keys in different vault paths, with different access. Fewer people should reach live keys.
- Add a startup check that refuses to run a test build with a live key, and the reverse.
- Use test data, never a copy of production data. If you must use real shapes, mask the values.
- Test the failure paths: expired key, missing permission, rate limit, revoked grant.
- Use a restricted key in the sandbox too, so the permission list is proven before launch.
- At go-live, follow the provider's checklist. Stripe notes that switching keys is only one step.
Low-code and automation tools
The same rule applies to tools where flows are built by non-developers. Keep a development environment with sandbox connections, and a production environment where only reviewed flows run with live connections. Moving from one to the other should be a deliberate step, with an owner who checks the permissions.
Where sandboxes fall short
- Some features behave differently in test mode. Stripe's docs note that its identity checks do not perform verification in a sandbox and some account fields are not returned. Read the provider's list of differences, and run a small, supervised live test at the end.
- A sandbox does not test your network rules or your monitoring. Check those separately.
- Sandbox credentials are still credentials. Do not publish them.
Quick check
Is a test key safe to commit to a repository?
Avoid it. It is lower risk than a live key, but habits carry over, and a repository that holds test keys will eventually hold live ones. Use a secrets manager for both.
Who should be able to see live keys?
As few people as possible, with a named reason. Stripe, for example, notes that in live mode you generally cannot reveal a key you created after first seeing it, so store it in a vault straight away.
Safeguard's policies and gates can block risky changes from reaching production, and its dependency scanning checks the libraries your integration uses. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
