Alongside our work to build the fastest and most efficient analytical database, our team is constantly striving to ensure that using FeatureBase is as easy as possible. Recently, our team has been working on developing a pay-as-you-go business model. This means that our customers can provision and deprovision all the databases that they need, anytime they want, and get charged based on the hourly consumption.
Two other software providers were necessary to achieve this business model: Amberflo and Stripe. Amberflo allows us to meter the infrastructure we deploy, can scale with our growth, and enables us to build and operate modern, usage-based pricing plans. Stripe allows us to securely store our customers' payment information and process charges according to their FeatureBase usage.
One recent security measure our team has been working through is tracking event updates for payments through Stripe and flagging any issues in real-time.
We documented our experience integrating Stripe Webhooks with Amberflo and are sharing our process with other teams who may be curious or interested in implementing a similar capability on their own product.
Stripe is our payment processing platform in which we securely store all customer payment information. Webhooks are an HTTP event driven communication mechanism between two applications, and when configured in Stripe, they notify us of payment events. Amberflo is a usage-based pricing and billing platform with real-time meter event ingestion and aggregation.
Amberflo monitors customers’ database consumption and produces the invoice. Stripe charges customers when it receives the Amberflo invoice and payment intent object, allowing us to automatically charge customers based on payment information we stored in Stripe.
To-date, our product has required manual invoicing on a monthly basis or payment through the AWS marketplace, but many of our customers would prefer to set up automatic payments directly in our product instead of dealing with the hassle of monthly invoices. Because of this, we sought to offer a user-friendly experience in which our trial users are able to seamlessly continue using FeatureBase with an easy pay-as-you-go option, and our existing customers are able to set up automatic, recurring payments. To ensure that payments would not fail for reasons such as expired payment information or insufficient funds on the given stored payment method, we began building an integration to notify us of payment anomalies.
Stripe provides an API that sends objects called events. These events contain information about what is going on in Stripe’s system. Our objective was to make sure that:
In order to achieve those goals, we needed to collect and track real-time updates of the following Stripe events:
payment_intent.payment_failed : this event occurs when a paymentintent sent out by Amberflo has failed to have been paid.
customer.source.deleted : occurs whenever a payment source is removed from a customer.
customer.source.expiring : occurs whenever a source input by a customer will expire by the end of the month.
Since Stripe sends events through Webhooks, we needed to expose an endpoint to collect events that would indicate for us to perform some action on the events received. Here’s how we approached this integration:
We needed to make our webhook endpoint publicly accessible, so we created a public facing service. This service listens to Stripe webhooks and verifies that the incoming request signature events are sent by Stripe and not another 3rd party.
The service will handle the received Stripe Event and return one of two possible responses to Stripe:
To make sure this process runs successfully we had to implement some failure handling mechanisms. A couple issues we wanted to proactively troubleshoot were:
Potential Issue #1: Our backend could fail to handle the Stripe events sent out because of some error.
Solution: To track this process, we configured Stripe to notify us of a misconfigured endpoint that has not responded with the 200 HTTP status code (indicating successful payment).
Potential Issue #2: Webhook endpoints might occasionally receive the same event more than once.
Solution: Make event processing idempotent. One way of doing this could be logging and storing the events we’ve processed with a time stamp to avoid processing duplicate events.
Potential Issue #3: Listening for unnecessary, extra events (or all events). This would put undue strain on the server.
Solution: We configured our webhook endpoint to receive only the types of events required by our integration.
Using this process, we are able to prevent the incorrect allocation of resources when our platform runs into issues with payments. If you’re interested in trying FeatureBase for yourself, start your free trial now!