SaaS Billing with Stripe: Implementation Patterns

Stripe Billing is the standard infrastructure layer for SaaS subscription revenue — it handles recurring charges, proration, trials, invoice generation, and payment failure recovery. Implementing it correctly requires understanding not just the API surface but the event-driven architecture that Stripe uses: your application reacts to webhook events, not to API call responses, to keep subscription state consistent.

Getting Stripe Billing wrong creates silent revenue leakage, broken subscription states, and customer-facing billing errors that are expensive to diagnose and fix. This guide covers the patterns that avoid those problems from the start.

---

How Stripe Billing Works

Stripe Billing is built on four core objects: Products, Prices, Customers, and Subscriptions.

Products represent what you sell — your SaaS plan tiers (Starter, Pro, Enterprise). A Product is a container; pricing lives in Prices attached to it.

Prices define how a Product is charged — the amount, currency, billing interval (monthly or annual), and billing model (flat rate, per-seat, usage-based). One Product can have multiple Prices (monthly and annual variants of the same plan tier).

Customers represent your users in Stripe. Every subscriber needs a Stripe Customer object. The Customer stores the payment method, billing address, and tax information.

Subscriptions link a Customer to one or more Prices, define the billing interval, and manage the subscription lifecycle (trialing, active, past_due, canceled).

The lifecycle is: create a Customer when a user signs up → collect payment method via Stripe Elements or Stripe Checkout → create a Subscription attaching the Customer to a Price → handle lifecycle events via webhooks.

---

Pricing Models and When to Use Each

For most B2B SaaS products at MVP stage, flat rate or per-seat pricing is the right starting point. Usage-based billing adds significant implementation complexity and should only be introduced when the business model explicitly requires it.

---

Implementation: The Subscription Lifecycle

Step 1: Create a Stripe Customer on user signup

Every user who might subscribe needs a Stripe Customer. Create it at signup, not at checkout — this allows you to attach trial periods, tax IDs, and metadata before they ever pay. Store the Stripe Customer ID on your user record.

Step 2: Collect payment method via Stripe Checkout or Elements

Stripe Checkout is the fastest implementation path — a hosted page that handles card collection, 3D Secure authentication, and compliance. Use it unless you need deep UI customization.

Step 3: Create the Subscription

After the payment method is attached, create the Subscription via the API with the customer ID, price ID, trial period if applicable, and payment settings.

Step 4: Handle webhooks — this is where the real logic lives

Do not rely on the API response to update your database. Your application must listen for and handle:

• customer.subscription.created — subscription is active, provision access
• customer.subscription.updated — plan changed, seats changed, trial ended
• customer.subscription.deleted — subscription canceled, revoke access
• invoice.payment_succeeded — payment collected, extend billing period
• invoice.payment_failed — payment failed, begin dunning sequence
• customer.subscription.trial_will_end — 3 days before trial ends, prompt upgrade

---

Proration: How Plan Changes Work

When a user upgrades or downgrades mid-billing-cycle, Stripe calculates proration automatically. A user on a $50/month plan who upgrades to $100/month on day 15 of a 30-day cycle gets a $25 credit for unused time and is charged $50 for the remaining 15 days — net $25 additional charge at upgrade.

Proration behavior is controlled by the proration_behavior parameter on subscription update calls: create_prorations (default, immediate invoice), none (change takes effect at next billing cycle), or always_invoice (immediate invoice regardless of amount).

For most B2B SaaS products, create_prorations is the right default.

---

Dunning: Handling Failed Payments

Payment failures are inevitable at scale. Stripe's Smart Retries automatically retries failed payments. Your application needs to handle the dunning flow on top:

• On first failure: send in-app notification and email prompting payment method update
• On second failure: send more urgent email, potentially restrict non-core features
• On final failure before cancellation: send final warning with direct billing update link
• On customer.subscription.deleted after exhausted retries: fully revoke access

Build a Stripe Customer Portal link for payment method updates — a Stripe-hosted page that eliminates custom payment update UI work.

---

How to Get Started

Before writing any billing code, decide on: pricing model (flat rate vs per-seat vs usage-based), trial strategy, and upgrade/downgrade proration behavior. These decisions affect Stripe object structure and webhook handling. Changing them after launch requires database migrations and Stripe configuration changes.

For a full B2B SaaS implementation including multi-tenancy, RBAC, and Stripe billing wired together, see Magehire's B2B SaaS development service.

Ready to Implement Billing That Doesn't Leak Revenue?

Stripe billing bugs — missed webhook events, incorrect proration handling, broken dunning flows — are invisible until they cause customer complaints or revenue discrepancies. Magehire implements Stripe Billing with full webhook coverage and reconciliation checks from day one. Schedule a strategy session to get billing done right.