In this article, I want to walk through the process of integrating a Stripe asynchronous subscription event with AWS EventBridge.
In a nutshell, EventBridge is a serverless event bus which hugely simplifies the process of building event-driven applications. This simplification is made possible with AWS taking care of event ingestion, delivery, security, authorization, and error handling.
What about Stripe? It is a fully integrated payments platform offering a rich set of APIs, a client library available in a range of languages, webhooks and a CLI which greatly simplifies life for a developer.
There are still several moving parts to consider with this serverless example With AWS CDK much of the complexity can be offloaded (GitHub link for sample project included later). The AWS stack includes:
- An API Gateway endpoint acting as a target for the Stripe webhook event with integration request type of LAMBDA_PROXY.
- A Lambda function which verifies the Stripe webhook request signature before programmatically sending the EventBridge event. The handler function accepts events of type APIGatewayProxyRequest.
- The EventBridge event bus with supporting rule. When EventBridge receives an event matching the pattern defined by the rule it will send to the source supplied in the event pattern.
- A second Lambda function which acts as the target for your EventBridge rule. The handler function accepts events of type CloudWatchEvent.
- And finally, a DynamoDB table updated as a consequence of the target functions being invoked.
Step 1 Creating the Event Bus
You have options when it comes to creating an event bus. Use the default event bus which handles all events emitted by AWS services, create a partner event bus described as being suitable for integrating with SaaS partners, or finally the option I have chosen which is to create a custom event bus which will receive events from the services and applications we create. AWS CDK reduces setup to a few lines of code(using Python CDK).
L1 Create event bus. L3 Create rule and associate with event bus, the default event bus will be used if one is not specified. L9 Define rule event pattern. L14 Add the target EventBridge will send the event to when a rule is emitted matching the pattern you have defined.
In this situation, we are not attempting to capture events emitted by the native AWS services in our account. If that was the case the default event bus must be used. When creating our rule we also have the option of choosing a target from one of the almost 20 AWS resources EventBridge can emit events to ranging from SQS to RedShift. We can also specify a Dead-Letter queue which EventBridge can use to send unsuccessfully delivered events.
Step 2 Creating a Stripe Webhook
I will be using the Stripe developer dashboard to create a test webhook, you can also do all this through the API. Through the web dashboard, use the API Gateway endpoint along with the customer.subscription.created event type to complete setup.
Step 3 Creating Lambda Handlers
The first Lambda function we create will handle the webhook request via our API Gateway endpoint. Some code is excluded from the snippet below however the main thrust of this function is to verify the incoming Stripe request signature. The signature is included in the incoming requests Stripe-Signature header and allows you to verify the request without requiring a third party. Signature verification is done by first downloading the endpoint's secret which we subsequently place in AWS Secrets Manager. Once verification is successful, the function creates an event and emits it to EventBridge.
The second Lambda function will act as the target for the event bus rule we have defined earlier and which will subsequently write to DynamoDB. It accepts events of type CloudWatchEvent. Details of the new customer subscription are extracted from the CloudWatchEvent object and written to the database table.
Step 4 Invoke the Test Webhook
Through the Stripe developer dashboard invoke the new webhook endpoint selecting the customer.subscription.created event type.
Step 5 Verify Rule Metrics and Database Update
CloudWatch metrics for your event bus rule allow you to quickly sanity check whether the rule was invoked successfully or not.
Finally, verify the database has been updated accordingly with the new customer ID.
Conclusion
It has been suggested that AWS EventBridge is the biggest thing to happen for serverless since Lambda. This is only my first foray with EventBridge so I won't wax lyrical just yet however I can certainly see where much of the excitement stems from. With an ever-growing number of integration options both AWS native services and SaaS providers, advanced monitoring and analytics, and a simple API for generating and emitting custom events it really does offer a management and coordination layer to tie all of your serverless modules together. I'm looking forward to watching this technology grow and hopefully have the opportunity to share more insights.
A full code example can be found over on GitHub: https://github.com/cdugga/eventbridge-stripe-go
Top comments (0)