Implementing Stripe Subscription payments in 5 seconds

Since there was some interest around my last article about implementing payments on a Monday, I wanted to spend some time to analyse the code, show how it works, and also illustrate a use case for both Hyperlambda and KISS - In addition to teaching you how to implement Stripe subscription payments in 5 seconds ^_^

First things first, if you want to reproduce what I am doing in the video, you should probably start out with the first article in this series, and sequentially read your way through each article, following the hands on exercises as you proceed. If you're too lazy to do that, you can also simply register a cloudlet in the link below and be up running in 30 seconds with your own Hyperlambda and Magic backend, for then to install the "Stripe Payments" plugin in your own Magic cloudlet.

• Create a Magic and Hyperlambda backend

Then, watch the following video where I walk you through all the ins and outs of the module.

Notice, you will obviously need a Stripe merchant payment account to use this module. After you have installed the Stripe Payment module you will have some roughly 10 HTTP endpoints, two of which are the most important ones being as follows.

• POST towards magic/modules/stripe/payment-methods
• POST towards magic/modules/stripe/subscriptions

The first endpoint takes a payload such as follows.

{
  "card_number": "1234567890",
  "card_exp_month": "6",
  "card_exp_year": "2023",
  "card_cvs": "123"
}

This creates a payment method internally within the module, which is a reference to a credit or debit card that your customer owns. The endpoint then returns the payment method ID, which you can later transmit to the second endpoint to create a subscription. The second endpoint's payload is as follows.

{
  "price": "price_xyzqwertyuiop",
  "payment_method": "pm_xyzqwertyuiop"
}

The "price" above is a price for a product, and these are created and administered from within Stripe's dashboard. They typically look something like the following screenshot.

Notice, this module doesn't allow you to create or administer products, instead it assumes you're able to use the Stripe dashboard to administrate your products and prices. This is kind of a big deal, and a large part of the point, since great software developers always asks themselves the following question when faced with a problem.

How can I avoid having to create code myself?

Every time you're facing a problem, regardless of how great of a developer you are, you should always ask yourself the above question first.

What is a subscription payment?

A subscription payment is basically exactly what it says. Stripe supports weekly, monthly, and yearly subscriptions, and when a payment is due, Stripe will automatically deduct the subscription fee from the credit or debit card that belongs to them. This is highly useful for for instance news media sites, requiring a subscription fee to access "paid content", or some online service, such as our cloud hosting solution that we charge for after a 3 months initial trial period.

Subscriptions are therefor a great way to implement stable and recurring revenue, for some service you are providing for your customers, that requires them to pay repeatedly over and over again in return for you providing some service to them. Just have your customers provide you with their credit or debit card, and you'll automagically have the subscription fee in your account every time a payment is due, without the customer having to do anything to pay you manually.

If you have a great product, that users wants to use, subscription payments are a win-win for both you and your customers.

Additional helper endpoints

In addition to the two primary endpoints documented further up, the module also contains some helper endpoints. First of all (obviously) the ability to cancel a subscription.

• DELETE magic/modules/stripe/subscriptions requiring a single query parameter named "subscription"

Unless your customers can somehow stop a subscription once they no longer need it, they'll probably be a bit angry over time - Hence, to allow for users to cancel a subscription is probably an important feature.

In addition to the above, the module also contains the ability to query prices and products, returning the information associated with the price and product from Stripe's internal systems. These two endpoints are aggressively cached, both on the server, and using Cache-Control HTTP headers, so they can be invoked very frequently, and will typically most of the time only require 1 millisecond to invoke, assuming your client respects the Cache-Control HTTP header of course. Below is a screenshot showing all endpoints that exists (currently) in the module.

Why not use Stripe's HTTP API directly?

Thank you for asking. First of all realise that to simply create a customer and associate a card with the customer is 4 HTTP invocations. In our Stripe payment module we've reduced these down to 1 HTTP invocation. This single endpoint has fault recovery automatically built in, implying if anything goes wrong, you can invoke it again and it will "continue" from where it left of previously as it failed.

Second of all, simply having "subscription payments" is literally useless, because you want to associate payments and subscriptions with specific users in your app. The module automatically takes care of this, as long as you pass in the Magic JWT token returned as you authenticate your users.

Hence, if you were to implement this yourself, you'd need authentication, authorisation, the ability to associate users with payments, credit and debit cards, Stripe's customer objects, and payment methods - In addition to subscriptions. With a traditional programming language such as C# or Java, you'd easily be looking at at least one week of software development, probably more, depending upon your experience level. KISS' first rule is as follows ...

What's the minimum amount of code required to solve the problem?

And the answer is 0 lines of code if you use our Stripe Payment module. Really, it's that simple, hence ...

All great software developers are lazy, because the first look for ways to AVOID coding ...