Subscription Billing for SaaS: How Stripe and Subscriptions Work

When you build a SaaS, billing is rarely the exciting part - yet it decides whether money actually ends up in your account. The good news: you don't have to build your own payment system. Stripe handles the trickiest parts (card data, recurring charges, security), and all you build is the bridge between your product and Stripe. In this article we explain how that really works, both technically and organizationally - without the marketing fluff.

The Core Building Blocks: Product, Price, Subscription

Stripe thinks in three layers that are worth understanding once - after that, the rest falls into place:

• Product - your abstract offering, such as the Pro plan or the Team plan.
• Price - a concrete price for a Product, for example 29 EUR per month or 290 EUR per year. A Product can have multiple Prices (monthly, yearly, different currencies).
• Subscription - the ongoing link between a customer and a Price. It ensures that the charge is collected automatically every month or every year.

On top of that comes the Customer: the Stripe object that represents one of your users and to which the payment method and subscriptions are attached. The most important rule from day one: store the Stripe customer ID in your own database on the user record. That way you can always map cleanly between Stripe and your own system.

How a Subscription Purchase Plays Out

The standard and safest approach today is Stripe Checkout - a payment page hosted by Stripe. Here's the flow:

• Your user clicks Subscribe on a plan. Your server creates a Checkout session with the matching Price ID.
• The user is redirected to Stripe, enters their card details there and completes the purchase. Sensitive data never touches your server - which spares you the strictest parts of PCI compliance.
• Stripe redirects back to your success page and creates the Customer and Subscription behind the scenes.

Important to grasp: the redirect to your success page is not reliable proof that payment was actually made. The user could close the tab. The real source of truth comes through webhooks.

Webhooks: The Core Piece Many Underestimate

A webhook is a message that Stripe actively sends to your server whenever something happens - payment succeeded, payment failed, subscription canceled. Your server listens at a fixed endpoint and reacts. It's the only reliable way to keep your database in sync with reality on Stripe's side.

The events that practically always matter for a SaaS:

• checkout.session.completed - the user has successfully subscribed; grant access.
• invoice.paid - next month's recurring payment went through.
• invoice.payment_failed - the card was declined; you should notify the user and, if needed, restrict access.
• customer.subscription.deleted - the subscription has ended; revoke access.

Two things you have to get right here: first, verify the signature of every webhook so no one can slip you forged events. Second, build your handler to be idempotent - Stripe can send the same event more than once, and you must not provision or charge a user twice because of it.

Trials, Cancellations and Plan Changes

Subscriptions can have a trial period - say seven days free, after which the charge is collected automatically. Stripe manages the date for you. A cancellation is usually set to cancel_at_period_end: the user keeps access until the end of the paid period, then the subscription expires. An upgrade or downgrade within the period is billed by Stripe on a prorated basis, so no one pays too much or too little.

Taxes, Invoices and the EU Context

For the German-speaking market, two points are central. First, VAT: if you sell to consumers in the EU, the tax rates of the customer's country apply. Stripe Tax can calculate and add this automatically. Second, Strong Customer Authentication (SCA): in the EU, many card payments have to be confirmed via 3-D Secure. Stripe Checkout handles this automatically - a good reason not to build your own payment form. Stripe also generates invoices; whether they meet your formal requirements is something you should quickly check with your tax advisor.

What We've Learned in Practice

We run seven of our own brands in production, several of them with subscription or paid models via Stripe. The recurring pitfalls are rarely the integration itself, but the edge cases: failed renewal payments, double-processed webhooks, users who cancel in the Stripe dashboard but still show as active in your database. An honest piece of advice: just get started. A single plan, monthly billing, Checkout and three cleanly handled webhook events are perfectly enough to begin with. Complex volume tiers, coupons and usage-based billing you can add later, when real customers ask for them - not before.