Creating reusable developer environments with Stripe Sandboxes

Summary

Setting up development machines with the correct tools, permissions, and dependencies can take weeks for new engineers, so the setup combines Stripe Sandboxes with development containers. Stripe Sandboxes provide isolated accounts with full Stripe API access for testing without real transactions, while sandbox settings remain independent and production customer, product, and transaction data is not copied. A C# example uses Bogus to generate ten fake products and Stripe.net’s ProductService to create them with metadata in the sandbox, and the text notes that SDKs can populate additional account data. The containerized workspace uses Docker development containers, a .NET 8 image, Redis via Docker Compose, environment variables, VS Code customizations, and a post-create script that installs Stripe CLI. Configuration files can then be checked into source control, giving team members an isolated and consistent workspace for exploring payment workflows without affecting live data.

Takeaways

1. 1

   A Stripe account can have up to five sandboxes; sandbox settings are not synchronized with the associated live account, and copied settings exclude customer, product, and transaction data.

2. 2

   The C# example uses Bogus and Stripe.net to generate ten fake products, then creates Stripe products with images, shippable status, and a unique-code metadata field.

3. 3

   The development container mounts the project at /workspace, runs Redis with a password and ports 6379 and 8001, and uses network_mode: service:redis so Redis is available through localhost inside the API container.