James Beswick

Learn effective data reconciliation strategies to keep product information synchronized between your internal systems and Stripe. Explore real-time vs batch processing tools, validation techniques, and best practices for maintaining consistent data across multiple platforms as your business scales.

Real-time vs batch reconciliation: Practical patterns for keeping data in sync

Learn advanced database reconciliation patterns for Stripe integration. Explore queue-based architectures, event-driven sync, and robust error handling to maintain product data consistency at scale.

From naive webhooks to durable sync: Queue-based and event-driven data reconciliation patterns

Learn how product data synchronization between internal databases and payment providers like Stripe evolves from simple scripts to complex architectural challenges as your business scales from hundreds to millions of products.

Keeping product data aligned with Stripe as your systems scale

Discover the latest from Stripe Sessions! Explore new products, APIs, and enhancements, including Stripe Workflows for no-code automation, MCP server for AI integration, and Accounts v2 for streamlined management.

Sessions 2025 Developer Track resources

Discover advanced caching strategies to optimize Stripe API performance in AWS Lambda using Amazon ElastiCache and DynamoDB. Learn how to manage API rate limits, reduce latency, and minimize costs while ensuring data consistency and scalability in high-volume applications.

Optimizing Stripe API performance in Lambda with caching strategies

Explore the complexities of enterprise subscription management and discover how an AWS microservice architecture can streamline subscription lifecycles. This guide uses AWS services to create a scalable, reliable, and auditable subscription management system, addressing challenges like mid-cycle plan changes and usage-based billing adjustments.

Using an AWS microservice architecture for subscription management

Discover how to build a scalable real-time payment analytics pipeline from Stripe to AWS. This guide explores the challenges, architectural components, and implementation details to help businesses monitor transactions, enhance security, and gain insights into customer behavior.

Real-time payment analytics: Building a data pipeline from Stripe to AWS

Implementing a resilient multi-region payment processing system using AWS and Stripe ensures reliable webhook handling, minimizes outages, and complies with regulations. This guide covers architecture design, challenges, and AWS service integration for optimal global performance and rate limit management.

Load balancing Stripe API calls from multiple AWS regions

Learn how to securely manage and automatically rotate your Stripe API keys in AWS for a production-grade approach. This guide covers best practices, tools, and strategies to enhance the security of your financial transactions.

Securing Stripe API Keys in AWS with automatic rotation

Learn about Stripe integrations with essential tips for robust, secure payment systems and seamless user experiences. This guide prepares developers for real-world scenarios, from subscription management to dispute resolution, ensuring secure and seamless payments.

Building rock-solid Stripe integrations: A developer's guide to success

Discover how to build reliable webhook handlers for Stripe events using AWS in this comprehensive guide. Learn about the challenges of processing webhook events at scale and how to address them with an enterprise-grade architecture.

Building resilient webhook handlers in AWS: Implementing DLQs for Stripe events

Discover the key concepts and terms for integrating Stripe in your applications. This guide covers Payment Intents Customer management, Subscription billing, Webhooks, Disputes, Refunds, and the benefits of expanded responses, providing developers with the tools they need to streamline payment processing efficiently.

New to Stripe? Learn the key concepts for software developers.

This post discusses integrating the Stripe agent toolkit with large language models (LLMs) to enhance automation workflows, enabling financial services access, metered billing, and streamlined operations across agent frameworks.

Using demo data for testing Stripe integrations in AWS-hosted applications

This blog shows how to find when something is wrong in production, avoid jumping between tabs/docs to find information, and resolving issues quickly in the troubleshooting process, using an AWS integration as a starting point.

Resolving production issues in your AWS/Stripe integration using Workbench

For developers building on AWS, you have various choices for processing payments within your application. Most developers choose a payment processing service to handle this part of their application flow, which involves integrating with a third-party vendor outside of the AWS environment.

Debugging your AWS/Stripe integration just got easier

Subscribe to Stripe Developers on YouTube.

Follow us at @Stripedev on twitter for updates and answers to your developer questions.

Check out the docs for the in-depth developer guidance.

Join the Stripe Discord server to chat live with other developers.

Join a local Stripe Developer Meetup to learn about the latest features and network with your community.


The new [Stripe sandboxes](https://docs.stripe.com/sandboxes) feature makes it easier to manage multiple test environments from a single Stripe account. Sandboxes provide richer functionality than the existing test mode feature and enable you to map test environments more easily to multiple developers in your AWS accounts.

This blog post summarizes the key differences between test mode and sandboxes, shows how to use sandboxes from an AWS-hosted application, and explains how to manage sandbox access if you have more than one developer working on a project.

## **The differences between test mode and sandboxes**

Stripe’s existing [test mode](https://docs.stripe.com/test-mode) feature is useful for developers testing integrations, offering different API keys from production. It’s designed to allow you to simulate successful payments, card errors, disputes, refunds, and authentication scenarios. Its purpose is to allow you to ensure your application responds correctly to the variety of outcomes that can happen in payment flows, and isn’t intended for load-testing or representing all Stripe objects available.

Stripe sandboxes provide a significant evolution of functionality that improves the testing experience for developers. A sandbox is a completely isolated account containing its own set of data, separate from production accounts or other sandboxes. Unlike test mode, which is available to all users who have access to your production account, you can define who has access to sandboxes.  

With Sandboxes, you can simulate external events to test payments, accumulating a fake balance instead of real money movement, and use the Test Payouts functionality using API v2 keys, calling API v2. You can use the CLI or SDK to interact with sandboxes by simply changing the API keys used. 

While sandboxes are intended to replace test mode, you can continue to use the legacy test mode if preferred. Sandboxes are intended as an additive product experience, and do not require you to migrate or make any changes to your development workflow.

|  | Legacy test mode | Sandboxes |
| :---- | :---- | :---- |
| *Number per account* | 1 | 5 |
| *API key access* | Unique API key per account | Unique API key per sandbox |
| *Isolation* | Some settings changed in test mode also affect your live account | Complete isolation per sandbox, separate from your production account |
| *Access control* | Users who can access the account can also access both production and test modes | You can define which users can access sandboxes, separate from production access |

## **Using sandboxes from an AWS-hosted application**

From the Stripe dashboard, you can access sandboxes from the account picker menu in the upper left. One sign-in may have access to multiple accounts, and each account may have up to 5 sandboxes.

![](/images/managing-multiple-stripe-test-environments-from-aws/image4.png)

Sandboxes must be created in the Dashboard UI by clicking **Create sandbox** from this page. Each sandbox must have a name that can be changed after creation. You can also choose to copy settings from your live account, such as the country where the account is based \- see the [sandbox settings page](https://docs.stripe.com/sandboxes/dashboard/sandbox-settings) in the documentation to see exactly which attributes are copied.

Once you have created all the sandboxes needed, you can access the list from the account dropdown or by visiting [https://dashboard.stripe.com/sandboxes](https://dashboard.stripe.com/sandboxes). As with sandbox creation, the deletion process is also managed in this page \- click the trashcan icon to delete a sandbox when finished.

![](/images/managing-multiple-stripe-test-environments-from-aws/image2.png)

You can access a sandbox from your AWS-hosted application by using its API keys. To see these, click **Open** next to the sandbox you want to use. The **Home** tab shows the publishable and secret keys. Generally, for server-based apps, you use the secret key from your workload hosted in AWS. Unlike production secret keys, which are only presented once, you can reveal secret keys in sandbox mode anytime from this screen.

![](/images/managing-multiple-stripe-test-environments-from-aws/image1.png)

Depending on your configuration and security preferences, you may prefer to use a restricted API key even in the sandbox. These keys can be scoped to specific read and write permissions per resource. This can be good practice for more complex payment configurations with many developers or teams, or where you want to mirror restricted keys in production.

You can control access to the sandbox from the **Team and security** option in the **Settings** menu, or from [https://dashboard.stripe.com/settings/team](https://dashboard.stripe.com/settings/team). Once a developer has an API key, they have the ability to take any action that the API key has access to. As a result, if you are running your application in AWS, you should only provide login access to the Stripe dashboard to administrators or other roles as needed, and separately guard your API keys.

While a sandbox will never have access to production and cannot be used to move real money, [it’s recommended that you treat API keys](https://www.google.com/url?q=https://docs.stripe.com/keys-best-practices&sa=D&source=docs&ust=1724797609980886&usg=AOvVaw1U2IklVnlHh6uR5ndZ8knp) for these the same way as you do for production. Specifically:

* Don’t embed API keys in code, or pass keys around in chat, email, or other unsecure means. Use services like [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/) to retrieve the key dynamically at runtime and don’t log the key in your code.  
* Don’t store keys in source repositories like [GitHub](https://github.com/), even if the repo is private since this can result in key leakage later.  
* Rotate your keys periodically in the Stripe dashboard, and then update AWS Secrets Manager. Restrict who has access to create, modify or delete keys in both Stripe and AWS.

With the keys set up, you can then save production and sandbox keys in AWS Secrets Manager. By using the secret name as an alias when you [retrieve the secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html), you can confidently use the same code in test and production environments. This is because you haven’t embedded the key directly or used any logic pathing based on the environment, which helps to limit bugs caused by human error.

## **Managing sandbox access with more than one developer**

Many Stripe customers use AWS to host their applications, and for enterprise workloads they often [use multiple AWS accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) to separate their development environments. [AWS Identity & Access Management](https://docs.aws.amazon.com/iam/) allows you to configure granular permissions for your developers to control precise access to resources in those accounts. In larger development teams, you can integrate with directory services (like Active Directory) and use groups so that as employees join and leave your organization or its team, access control is synchronized accordingly. 

Once you have configured sandboxes in the dashboard and secured the secrets in AWS Secrets Manager, you should then use IAM resource policies to control access by IAM principals. You can grant access to a single secret to multiple users and roles, or grant access to users and roles in other AWS accounts. 

To add a secret in Secrets Manager, you can use the AWS Management Console, [AWS SDKs](https://aws.amazon.com/developer/tools/), or [AWS CLI](https://aws.amazon.com/cli/). For the CLI, enter the following command in the terminal:

```bash
aws secretsmanager create-secret \
    --name mySandboxSecret \
    --secret-string file://mysecret.json
```

While the JSON payload for mysecret.json can store any arbitrary text, in this case it could contain the following:

```bash
{
    "name": "mySandbox",
    "apiKey": "<< YOUR API KEY >>"
}
```

*Learn more about [creating secrets in AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_database_secret.html) using the AWS SDKs.*

For AWS accounts running beta accounts of your software, you can restrict access to the production Stripe keys to ensure they never accidentally call production APIs. Similarly, you can prevent the production AWS account from accessing sandbox secrets. By embedding this logic into policies instead of logic in code, you can systematically enforce key access and implementation and reduce human error.

*Learn more about [configuring permission policies](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples.html) or read the [AWS Secrets Manager User Guide](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples.html) for details.* 

## **Conclusion**

With Stripe sandboxes, you can work in test environments that provide greater functionality than the legacy test mode, with strict isolation between each other and production accounts. 

For AWS developers using multiple AWS accounts to manage application environments with teams of developers, you can then secure the API keys in AWS Secrets Managers and use IAM resource policies to limit access to those keys. This helps to avoid sharing keys openly, and allows you to apply rigorous access control best practices. You can take advantage of integration with directory services and other automations in your AWS account to lock-down API key access to your developers.

To learn more about developing applications with Stripe, visit our [YouTube Channel](https://www.youtube.com/stripedevelopers).

![](/images/managing-multiple-stripe-test-environments-from-aws/image3.png)

Stripe sandboxes enhance test environment management, offering improved functionality over test mode, allowing isolated accounts, multiple developers, and better access control while integrating seamlessly with AWS applications.

Managing multiple Stripe test environments from your AWS-hosted application

James Beswick