Choosing the right sandbox strategy for your organization

Ben SmithSep 26, 2024

Source: Stripe
Published: Sep 26, 2024
Added to Yomu: Aug 28, 2026

Summary

Stripe sandboxes provide isolated environments for testing Stripe features without affecting a live integration, with access controls for the people who use them. Each live account can have up to five sandboxes, which admins can create, name, configure by copying selected live-account settings, and delete when no longer needed. The guide describes a staged setup for startups and small teams, using separate environments for development, integration testing, user acceptance testing, and spare capacity, while larger organizations may assign sandboxes to departments and rotate them between projects. It also presents an iterative model in which teams prototype, collect stakeholder feedback, retest changes, and document results. The recommended strategy depends on team size, organizational structure, workflow, and development methodology.

Context

Organizations need to choose a sandbox arrangement that fits their development approach, team size, organizational structure, testing workflow, and specific needs. Small teams may need to coordinate staged testing with limited resources, while larger organizations face overlapping work across departments such as development, QA, marketing, and product management.

Approach / What changed

Use Stripe sandboxes as isolated, access-controlled testing environments and allocate them according to organizational context. Suggested models include five staged sandboxes for development, integration testing, UAT, and spare capacity; department-specific sandboxes that can be deleted and reassigned; or dedicated environments for iterative prototyping, stakeholder feedback, retesting, and documented learning.

Takeaways

A Stripe live account can have up to five sandboxes, and admins can control access, create and name environments, copy available live-account settings, and delete sandboxes when they are no longer needed.
A small-team setup can assign sandboxes to development, integration testing, and user acceptance testing, while reserving two for unexpected or overflow testing needs.
Larger organizations can separate department workflows into dedicated sandboxes and rotate environments between departments after a testing phase ends.

Architecture Developer Experience Testing

Read original post

Choosing the right sandbox strategy for your organization

Ben SmithSep 26, 2024

Source: Stripe
Published: Sep 26, 2024
Added to Yomu: Aug 28, 2026

Summary

Context

Approach / What changed

Takeaways

A Stripe live account can have up to five sandboxes, and admins can control access, create and name environments, copy available live-account settings, and delete sandboxes when they are no longer needed.
A small-team setup can assign sandboxes to development, integration testing, and user acceptance testing, while reserving two for unexpected or overflow testing needs.
Larger organizations can separate department workflows into dedicated sandboxes and rotate environments between departments after a testing phase ends.

Architecture Developer Experience Testing

Read original post

Related reading

Stripe · Sep 16, 2024
Avoiding test mode tangles with Stripe Sandboxes
Stripe integrations can become difficult to test when an account has only one test mode, because unrelated work can interfere and sensitive configuration must remain protected. The post presents Stripe Sandboxes as separate testing areas and shows a Node.js Express application authenticating with a sandbox secret key stored in a .env environment variable. It creates payment intents through /create-payment-intent and retrieves account details through /account, then uses Jest and supertest to verify the sandbox identity, including the expected display name dev-sandbox. A GitHub Actions workflow injects STRIPE_API_KEY from repository secrets, installs dependencies, and runs tests on pushes to the main branch, while .gitignore excludes environment files. The conclusion is that isolated sandboxes and automated checks reduce test tangles and help prevent calls to the wrong environment.
Ben Smith
Stripe · Nov 26, 2024
Managing multiple Stripe test environments from your AWS-hosted application
Stripe sandboxes provide isolated test accounts that let teams manage multiple environments from one account. Unlike legacy test mode, each sandbox has separate data, its own API keys, and configurable user access, while up to five sandboxes can exist per account. They support simulated external events, fake balances, Test Payouts with API v2 keys, and CLI or SDK access by changing keys. For AWS-hosted applications, the recommended pattern stores sandbox and production keys in AWS Secrets Manager, using secret names as environment-neutral aliases rather than embedding environment logic in code. Teams can combine Stripe sandbox permissions with AWS IAM resource policies and directory groups to restrict which users or accounts can retrieve keys and prevent accidental production access.
James Beswick
Stripe · Dec 19, 2024
Crush errors with Sandbox testing
Payment integrations can encounter errors caused by external events, such as network issues or outages, or by bugs in application code, and unhandled failures can stall checkout. The post presents Stripe Sandboxes as isolated environments for reproducing live-integration failures without changing live payment settings or traffic, optionally copying settings when a sandbox is created. Developers can use Workbench’s Errors and Logs views to diagnose a card_declined response, then route test requests through sandbox keys and a test card. On the Python backend, a try/except implementation catches Stripe errors and generic exceptions and returns an error response instead of leaving the payment page stalled. Sandboxes remain separate after creation, but each Stripe account can have at most five, so unused environments may be deleted or have their test data cleared while settings are preserved.
David Edoh-Bedi
Stripe · Dec 13, 2024
Japan community highlights: Effective testing and security
This article reports practical lessons from two September 2024 JP_Stripes events in Aizuwakamatsu and Sapporo for developing and operating Stripe-integrated services more efficiently and at lower cost. Sandboxes let teams create up to five separate test environments, reproduce payment failures and state transitions through Stripe's API, and use CI-specific workspaces without production access. Stripe Connect examples show how a three-person codoc team launched in nine months by staggering account creation and embedding payout and payment-management interfaces. For fraud prevention, the article recommends Radar or Radar for Teams with webhook automation, including early-fraud-warning events and preemptive cancellation or refunds when dispute fees exceed transaction value. Together, these cases emphasize using managed Stripe capabilities and community-shared implementation experience to reduce testing effort, UI work, and fraud-related costs.
Hidetaka Okamoto