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.
There are several key benefits to developers taking this approach. First, if your application processes credit cards, you can avoid the security risk of handling or storing credit card information. Second, if you have a spiky workload, such as processing payments for Black Friday or large-scale events, you can offload to a service that can handle the variability of requests. Third, if you have global payments or multiple payment methods enabled, the payment provider can handle that complexity, and can make it much easier to add additional countries or payment methods in future, as your needs change.
The difficulty of finding logs for API calls in AWS
When you use a third-party service such as Stripe, you either embed payment processing logic into the frontend of your web application or use backend APIs to submit payment information to the service’s API. The exact flow depends on if your application is customer-facing or operating as middleware for another workload. You also use the APIs for non-payment activities like creating products, configuring prices, and creating customers.
AWS has a broad range of compute services where you can run your application, from AWS Lambda to Amazon ECS, and Amazon EKS. Regardless, your application can make calls to Stripe’s API directly from your code and it’s good practice to log the outcome and other attributes for these calls. However, depending on your compute choice and code configuration, your log files may contain sparse or verbose information about the API calls, and are stored in different places.
For example, Lambda stores logs in Amazon CloudWatch which by default create a new log file for each Lambda invocation. This means if you have 10,000 calls in your application to Stripe’s API, you need to search up to 10,000 log files to find specific information. You must then filter for type of call, HTTP response code, and other attributes to identify a specific log. Additionally, by default the logs will not provide an aggregated view of your API calls over time.
For cost optimization in logging, it’s also common practice to use verbose mode during the development phase and restrict logs to essential information in production. This can unintentionally result in limiting the information available to debug production issues. Furthermore, the logging usually only captures the payload and associated metadata of the call, and any response received from the endpoint, but lacks any additional information available from the provider.
Getting started with Workbench
Stripe’s Workbench provides a more convenient way for developers to access and search logs at scale. It doesn’t require you to set a logging level, storing all available information by default while still obfuscating credit card numbers and other sensitive data.
To see Workbench:
- Navigate to https://dashboard.stripe.com/ in your preferred browser and log into your Stripe account.
- If you have multiple accounts configured, use the drop-down in the top-left to select the store API activity you wish to view. Workbench reports and content are scoped to the store level.
- 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.
- Workbench opens in the lower portion of the window:
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.
Different tabs of Workbench are useful at different stages of development, or during production usage. On the Overview tab, you can immediately see the total number of successful and failed API requests by time. This can be useful for finding the time of failures, or for determining if your total number of API calls is likely to reach rate limits.
In the left pane, the API versions panel allows you to track which API versions your application uses. While Stripe supports API versions for up to six years, here you can identify calls using older versions:
By clicking the bar graph, this opens the Logs tab for the associated version, making it easier to find applications and microservices that can be updated.
The Logs tab allows you to drill into any individual API call to view the Response and Request body. This is equivalent to what you might store in a verbose log within AWS, but you are not charged by Stripe to store this data. Additionally, the UI contains quick links to copy the JSON, link to underlying records, and envelope metadata (such as API key and API version) that otherwise might not be captured by the caller.
Even when Workbench is collapsed, its toolbar contains notifications that can help highlight important information. Click the icons with the red dots to learn more about any specific issues:
If your application has a recurring issue in an API call, the Errors tab makes it easier to view the different types of errors. Instead of parsing log files, use the list view on the left to find the most recent errors generated by an application, and then drill down.
This links to your individual logs. When you expand a single log entry on the left, the verbose version contains links to helpful documentation. Depending on the error, it may also provide error insights that expand on the exact type of problem that’s occurring.
Debugging events delivery failures
Stripe’s Event Destinations feature makes it easier for you to handle asynchronous processes by delivering changes in state via a JSON event payload. In your AWS account, you receive these events via a partner event bus in your application’s region. However, when an event is either not delivered or has a failure, this may not be logged by the event bus, depending on if a CloudWatch Logs group has been configured as a target in the event rule.
Workbench provides the Events and Event Destinations tab to simplify the process of debugging event issues. In the events tab, you can see a list of recent events generated in your Stripe account. You can drill down into a single event to find successful and failed deliveries to webhook endpoints and connected platforms. This view aggregates all events including those sent to AWS and other platforms.
The Event destinations tab provides more information about retries on pending and failed events that Stripe sends to your AWS account. This view shows a graph of event delivery activity, and allows you to drill down into delivery attempts and responses from the endpoint. You can filter by event ID or by delivery status to help locate problematic events more quickly.
Conclusion
Using Stripe to process your payments can remove significant complexity from your code base, and help offload scalability and security concerns away from your AWS account. AWS has a broad range of compute options that can result in your application log files being distributed between server logs, CloudWatch Logs, and other places, making them challenging to locate and search.
Workbench is designed to help centralize the information developers need for understanding their Stripe integrations without the need for a third-party logging processor. You can quickly navigate large amounts of log data using advanced filters and find common types of errors occurring using aggregation. These logs are stored and made available at no extra cost to you and can provide more insights than are typically provided by verbose logging.
If there are more features you would like to see, let us know by clicking the Send feedback button at the top of the Workbench panel.