Stripe Payment Strategies

This post is the second part of a complete, free course on Stripe, which is available both on this very website and on YouTube.

Both the course and its code are openly and freely available. If you enjoy the content, you can support the website by becoming a premium member, or buying my book.

In the YouTube video, the content of this post starts at minute 33:12.

1 - Introduction to Payment Strategies

Once you start researching how to handle payments, you begin to discover different ways or practices you might not have known about before. 

This is the list of all the strategies I know. There might be more, but these will cover the vast majority of cases, and we'll see some of them throughout this course.

• One-time Payment: Quite straightforward, a customer makes a payment and receives a product in return, this is the strategy I use to process book purchases on the site.
• Recurring Payment: This strategy allows for recurring payments, often used for applications or companies that provide ongoing services. The most famous examples are streaming websites like Netflix or Amazon, but an alarm company follows the same logic.
• Free Trial: This usually goes together with the previous strategy, letting you have full access for the first month or days for free before you have to pay for the full subscription.
• Freemium: This model gives you a free portion, and after exceeding that, you start paying. For example, in an email system where the first 1,000 sends are free and then you pay a fee of X euros per additional 5,000 emails sent.
• Tiered Subscriptions: I'm not sure what the correct term for these is, but basically, they offer multiple price points, each unlocking different possibilities. This is very common for Software as a Service, where one tier is for regular users, and another for admin users. Another example is in an email service, where a tier 1 version lets you send lots more emails, but a (more expensive) tier 2 lets you view statistics about those emails.
• Seats: Seats are similar to recurring payments, except access is given to a certain number of users within a group. For example, Company A has 5 pro seats on my book website, at any time, 5 assigned users from that company can be on the site. Even if the company has 500 employees, they pay for 5 seats, which rotate among users.
• Tokens/Usage Billing: Instead of paying by month or user, you pay based on usage. It's a payment strategy that benefits those who know what they’re doing. For example, the OpenAI API (Chat GPT) or providers like AWS or Azure work this way.

When you create your own application, you should investigate which strategy is most beneficial for you. 

In this course, as I said, we'll look at several. The first will be the one-time payment, we'll allow users to buy a book individually and receive the book by email. 

These users can be registered or not; for our specific use case, it doesn’t matter.

The payment architecture we'll look at is as follows: 

A user lands on the website and generates a payment, which is then redirected to Stripe’s website, where all the payment management happens, and once completed, returns to the website.

At the same time, Stripe sends a webhook to notify the payment, and from there, we send the book by email to the user, give them access on the site, or start the subscription period. 

We'll see later how to work with Stripe webhooks, but for now let's just say it's an endpoint on our API.

The good thing about this diagram is that it works for the vast majority of the previous cases since the process is the same.

And it will be the first use case we go through.