Building payments with Stripe, 101.

Hello, I’m Justin, software engineer at Maki.

In the following article, I will tell you more on how we went about developing billing at Maki. In particular, you will learn:

• How we initially thought about developing our pricing
• Compromises we had to make in order to meet our deadlines
• How Stripe checkout saved us a crazy amount of time

Before we begin, let me walk you through key parameters we had to consider for pricing:

• Maki offers 5 product plans in total: 4 standard product plans + 1 custom plan for specific clients (Enterprise accounts)
• For each plan, we must consider 2 pricing models :
  - A flat rate model, that translates into a yearly or a monthly subscription fee
  - An usage-based model, corresponding to the number of candidates that took an assessment on top of the initial plan limit
• We also need to handle multiple currencies

💳 Why did we chose Stripe?

When considering providers, we decided to go with Stripe for 2 main reasons.

First, Stripe offers a friendlier developer API. It’s well documented, super easy to understand and setup. They have a lot of examples and use cases to envision how to best build your products. They can hide all the complexity to manage payment with their Checkout API (more on that down below).

Second reason was that Stripe allowed us to operate in currencies / geographies we might target in the medium & long run.

🆘 How it started?

At first, we wanted to build a self-hosted billing experience within our application. We started to implement the payment for a subscription in our app but quickly found out this implied a lot of complexity. Potential issues we could think of included:

• Handling all the reasons why a payment could fail
  - Invalid card
  - Card declined (Not enough money, Blocked, Can’t be use to pay in stripe…)
  - etc.
• Handling two versions of 3D Secure depending of the card
  - More information here
• Handling payment method management (card / sepa)
• Handling subscriptions
• Generating invoices

Here’s a glimpse at our initial payment flow

🤔 A step back

With our short deadline, we figured it would not be easy to release billing in time for our launch if we built everything ourselves. We ended up digging in the Stripe documentation to see how we could make some compromise on our side and speed up the development. We discovered a really useful product in Stripe name Stripe checkout to speed up the payment process

🔥 What is stripe checkout?

How Stripe defines it: The quickest way to build conversion-optimized payment forms, hosted on Stripe.

I can only agree with them, it’s super fast to set up a payment form experience with it. It took less than a day to have something working. It solved all our payment issues. But how exactly does it work?

We start by showing the various plans to users directly from our app.

However, when a user clicks to select a plan, we make a call to Stripe API to get a checkout session with the product for that specific user. In response, they return us a Stripe URL, so the user can complete the payment. You just have to do a redirection on the front-end.

Users will get a form that look like this:

The form is pretty straightforward to fill, and is really all you need in my opinion to start a business. Users can access every details about the product they are subscribing. Rest assured, you can customize the page to match your branding.

Once this is done, you will get in the back-end side some events through a webhook in order to know if the transaction failed or succeeded. It should be simple to handle them, we didn’t have any issues.

For more about details on how to offer a similar experience and implement a subscriptions integration, check this Stripe article.

What did we learn? 💡

We followed our core intuition that ‘relying on existing bricks’ is better than reinventing the wheel, especially on things that are not part of our core business. In that case, relying on Stripe to provide us with some ready-made experiences saved us precious time, and helped us focus more on our product and on what we really want to bring to our customer in the end.