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.

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

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

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.



For AWS developers integrating with third-party APIs outside of your AWS account, there are several common problems that can cause your production application to behave unexpectedly. 

With Workbench, [Stripe](https://docs.stripe.com/development) provides next-generation debugging tools that make it easier and faster to pinpoint, understand, and resolve production problems. Stripe logs detailed information about every API request in your account without additional charges. Workbench provides powerful filtering and insights capabilities to help search logs quickly and find application requests. 

This blog post shows how to find and resolve common production issues by using Workbench and provides recommendations for addressing those issues.

### Getting started with Workbench

To use Workbench:

1. Navigate to [https://dashboard.stripe.com/](https://dashboard.stripe.com/) in your preferred browser and log into your Stripe account.   
2. If you have multiple accounts configured, use the drop-down in the top-left to select which account API activity you want to view. Workbench reports and content are scoped to the account level.  
3. In the bottom-right corner of the browser, hover over the terminal icon to expand the menu, then select the caret symbol to open Workbench.

![](/images/workbench-common/caret-dark3.png)

4. Workbench opens in the lower portion of the window:

![](/images/workbench-common/workbench-screen.png)

*Workbench is not a browser extension and does not rely on CLIs or other tools in your development machine, so you can use it immediately without the need for installing additional software.*

### Detecting duplicate API calls from an application

In this scenario, you expected code to call an API endpoint once but instead the endpoint was called twice or more. The code worked as expected in development and this issue only appears sporadically in production.

![](/images/aws-resolve/aws-resolve3.png)

AWS offers a range of options to host your application, from serverless compute like AWS Lambda to containerized services like Amazon ECS. Some of these services provide high availability by hosting your code or application in multiple underlying availability zones. The trade-off is that there may not be an exactly-once processing guarantee.

In the case of Lambda, if the function errors out unexpectedly or if there is a transient network error, the service will retry executing your code. This means that an API call can be retried again, and Stripe is unaware that you didn’t explicitly retry in code. This can also happen if the Lambda service experiences issues in an availability zone, so you should expect that it’s possible for the code to be executed more than once. While you often don’t see these issues in the development process, as systems receive more traffic, these transient failures become more common in the long tail of traffic. 

To mitigate this issue, when calling a Stripe POST API, it’s recommended that you use an [idempotency](https://en.wikipedia.org/wiki/Idempotence) header in your request to prevent duplicate requests from having unintended side effects. Most common client libraries can add idempotency requests to API calls automatically, but the feature usually must be enabled first. Since you have limited control over compute services that may invoke your code more than once, the idempotency header allows Stripe to ignore requests that it may have seen before. Stripe’s GET and DELETE APIs are already guaranteed idempotent without needing this key.

*Learn more about [designing with idempotency with AWS Lambda](https://aws.amazon.com/blogs/compute/handling-lambda-functions-idempotency-with-aws-lambda-powertools/) and [making retries safe in AWS compute services](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/).* 

### Using Workbench to find duplicate API calls

If your application unexpectedly calls an API more than once, you can use Workbench to detect this behavior. Go to the **Logs** tab and search by the resource ID to quickly filter the logs for a specific request. You can use additional filters to drill down by HTTP method and API endpoint if needed. 

In the example below, this AWS-hosted application calls the `/v1/prices` endpoint multiple times with the same payload. The *Idempotency* header is different for each request, indicating that it either hasn’t been set correctly, or hasn’t been used by the client. Choosing one of the requests shows the multiple pricing requests in the UI.

![](/images/aws-resolve/aws-resolve4.png)

### Identifying why an application’s API request has failed

If your AWS logs confirm that an API request has been sent, you can search in Workbench to ensure that Stripe received it. If the log is missing, it was not processed by Stripe, and you should check that the code has the necessary permission to reach the API. You should also verify the URL used in the API call, and any egress restrictions in your AWS account that may prevent the traffic from reaching the endpoint.

The HTTP status code in the response defines the broad type of error. You can see this in your AWS application logs, but it doesn’t always indicate there is an issue with your code or the Stripe service. Code 401 and 403 indicate issues with your API key, while 402 means there is a problem with the payment details provided. Response codes in the 5xx range are rare and are caused by a problem at Stripe. 

*Learn about [Stripe’s HTTP error codes](https://docs.stripe.com/error-low-level\#errors-in-http).*

### Learning more in Workbench

The **Logs** tab in Workbench allows you to filter by *Status* (e.g. “Failed”) to list all the failed API calls from your application. From here, you can drill down into any request and learn more about the request and response bodies. While credit card data is masked, the **Error insights** panel can indicate problems with the card information provided. 

![](/images/aws-resolve/aws-resolve5.png)

This is useful for tracking individual errors but if users of your production application are reporting multiple problems, the **Errors** tab can give you more information and help accelerate problem resolution. This section aggregates errors by type, allowing you to find the common cause of the bulk of the errors, and then drill down into specific data. 

![](/images/aws-resolve/aws-resolve6.png)

You can also use the **Overview** tab in conjunction with this view to detect rate limiting. This results in 429 HTTP errors to requests and can be seen in busy systems in production. You can [contact Stripe support](https://support.stripe.com/) to request limit increases but in some cases you can rearchitect your AWS-based application to avoid bursts of requests to the Stripe API and smooth out traffic. 

*Learn more about [Stripe’s rate limits](https://docs.stripe.com/rate-limits).*

### Locating and resending Stripe events that never appear in your AWS account

Many Stripe processes are asynchronous and take time to complete. To avoid polling APIs for changes and to help synchronize state closer to real-time, Stripe can push data changes directly to your AWS account as events. Once configured, events arrive in the partner event bus of the [Amazon EventBridge](https://aws.amazon.com/eventbridge/) service, where you can then route to other services to take appropriate action. However, the service does not log if events fail to arrive, so your application is unaware of the missing data.

![](/images/aws-resolve/aws-resolve7.png)

### Using Workbench to detect and replay failed events

In the **Event destinations** tab, set the *Status* filter to “Failed/Pending” to show a list of events that have not been delivered successfully. Click on an event to load the detailed view. From here, the **Delivery attempts** panel shows the history of failed delivery, together with the option to resend to the event bus. Clicking one of these delivery attempts shows additional information about why the delivery failed.

![](/images/aws-resolve/aws-resolve8.png)

*Learn more about [setting up Stripe events in your AWS account](https://docs.stripe.com/event-destinations/eventbridge).*

### Conclusion

Many AWS customers use Stripe for processing payments by calling Stripe’s APIs from their hosted applications. There are many runtime errors that can occur in production, from service failures to errors in user-provider credit card information. While you can use logs from your applications to locate failed calls, in many cases it's faster to use Stripe’s Workbench tool to isolate and resolve the cause of the problem.

Workbench logs verbose information about APIs at no extra charge to users and provides rich filtering capabilities and insights. This blog post shows how to use this to identify duplicate API calls, unexpected HTTP errors, and locate and resend events that are not reaching their AWS targets.

If there are more features you would like to see, let us know by clicking the **Send feedback** button at the top of the panel.




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

James Beswick