How to Implement Payments with Stripe

Let’s start by refining our first pricing offer, and design the corresponding pricing page. For now, this should be only a frontend implementation, we will not connect the product to Stripe.

Now let’s dive into Stripe and get familiar with its main objects. Understanding how to navigate Stripe is important for two key reasons: It will help you with the technical implementation of payments in your product. It’s essential for handling customer support, whether you're troubleshooting a bug or investigating a specific customer issue.

Now let’s walk through how we’ll interact with Stripe’s API to implement the logic behind the subscription system. We’ll break this down into two main flows: 1. Subscription flow: when a user subscribes to a product for the first time. 2. Update and cancellation flow: when a user upgrades, downgrades, or cancels their subscription.

We’re getting closer to our first Stripe integration, but before that, we need to set up our database with the proper tables. In this lesson, we’ll walk through the tables you need to create and how they relate to one another to support your subscription logic.

Before diving into Stripe objects, we first need to create a new Account object. This will act as an extended version of the user, storing additional attributes, such as the stripe_customer_id if the user becomes a customer.

Let’s now work on the products table. This table will be filled-in with the various products (or plans) that we will create inside Stripe. Each product will also hold the rules regarding the access to each available feature (what we call feature entitlement)

As we saw earlier in the description of the Stripe workflows, Stripe relies heavily on webhooks. Webhooks are a common concept in modern applications, so we’ll start with a quick refresher on what they are. Then, we’ll set up Stripe webhooks and update our app to ensure it can properly receive and handle those webhook events.

We are now going to improve the user flow inside the pricing page so that a checkout session is created after the user clicks on the “Subscribe” This will be required as the event “subscription.created” will only be generated once the user has performed a successful payment inside the checkout session.

Let’s wrap up our Stripe setup for the subscription flow by using the data received from Stripe webhooks after a successful payment. We’ll use this data to create the subscription in our database and update the corresponding account. This ensures that each account has access to the correct features based on their subscription.

Now that the subscription creation workflow is in place, we can move on to handling subscription updates and cancellations. These flows start from the Customer Portal, which customers can access from the Settings page. This is from this page that customers will be able to either update (upgrade or downgrade) their subscription. We’ll begin by generating a new Customer Portal session whenever a user clicks the “Manage subscription” button, similar to how a Checkout Session is created when subscribing to a plan.

Now that the Customer Portal is set up and users can update or cancel their subscriptions, let’s focus on implementing the logic to reflect those changes in our system. Specifically, we’ll update the subscription record and adjust the associated account based on the new plan the customer has selected.

Let’s now implement the final use case: when a user wants to cancel their subscription. The cancellation workflow happens in two stages: - Stage 1: The user initiates the cancellation. This schedules the subscription to end at the end of the current billing cycle. At this point, the subscription is marked as canceled but remains active until the cycle ends. - Stage 2: Once the billing cycle ends, the subscription status changes to inactive, and the user no longer has access to paid features.

Now that our backend handles subscription management, let's implement the final piece: enforcing feature entitlements in the frontend. This means blocking users from accessing features that their subscription doesn't include.

To complete the final step of handling entitlements, we need to accurately track the number of credits consumed by each customer. This ensures that the credit counter decreases as templates are generated, so customers only use the credits included in their plan. That’s exactly what we’ll implement in this tutorial.

In this follow-up tutorial, we'll secure the workflow setup we built around accounts. As you may recall, we had to disable authentication for API calls because users weren't authenticated during account creation. We'll now implement a more secure approach by listening to events sent by Supabase.