Stripe Billing is Stripe's subscription engine: you set up Products and Prices, attach a Subscription to a Customer, and Stripe generates the recurring invoice, charges the card, retries a failed payment on its own schedule, and tracks the subscription's status automatically. We don't set up your Stripe Billing configuration. We build what happens elsewhere in your business the moment a subscription changes, renews, or fails.
Every Stripe subscription moves through a defined set of statuses. `trialing` means the customer's inside a free trial period and hasn't been charged yet. `active` means it's current and paid. `past_due` means a renewal charge failed and Stripe is retrying it on its own schedule. `canceled` means it's over. `unpaid` means the retries ran out without success. That status, not a guess based on when someone last opened the dashboard, is what should be deciding whether a customer keeps access.
Cancelling a subscription in Stripe can happen two ways: immediately, which stops billing and ends access right away, or at the end of the current billing period, which lets the customer keep what they already paid for and stops the next renewal from happening. Which one's right depends on whether you want to deal with a prorated refund or just let the current period run out cleanly.
Pausing is a separate option from cancelling, set through Stripe's `pause_collection` field. It stops new invoices from being generated while the subscription stays on the books, so a customer can come back later without re-subscribing from scratch. You choose separately whether invoices that were already open while paused get kept, voided, or marked uncollectible.
Stripe's Smart Retries decide when to try a failed card again, but they don't decide what happens to that customer in the meantime. Whether a feature gets revoked after the third failed attempt, whether someone on your team gets flagged to make a personal call, or whether a win-back email goes out in your own voice instead of Stripe's default template, all of that lives outside Stripe and usually isn't built unless someone's watching for it manually.
The same gap shows up with usage-based pricing. If part of what a customer owes depends on something you track somewhere else, seats used, API calls made, data processed, that number has to reach Stripe before it can bill correctly. Plenty of businesses handle this by someone pulling a report and typing a figure into the Stripe dashboard every billing cycle, which works right up until someone forgets or the volume gets too big to do by hand.
A `customer.subscription.updated` webhook can revoke a feature, downgrade a seat count, or restore access the instant Stripe's own status changes, rather than someone checking the dashboard once a week to see who's actually still paying.
When billing depends on a usage figure that lives in your own app or database, we pull it on schedule and report it to Stripe automatically, so metered billing doesn't depend on someone remembering to log in and enter a number before the cutoff.
A cancellation, a downgrade, a failed renewal: tell us which one still depends on someone noticing it, and we'll look at what it would take to close that gap.
Stripe Billing handles the charge and the retry timing on its own. What happens to that customer's access, their record in your CRM, or your own books afterward is still a decision your business makes, and most of that decision doesn't need a person sitting in the middle of it. Subscriptions are just this page's example; n-frames builds the same kind of follow-up automation anywhere a tool fires off an event and someone's been catching it manually instead.
Let's talk →Cancel it immediately to end access and stop billing right away, or set it to cancel at the end of the current period so the customer keeps access through what they already paid for. The second option avoids a prorated-refund conversation; the first is faster when a customer wants out now.
Yes, using Stripe's `pause_collection` setting. It stops new invoices from generating while the subscription stays active in the background, so the customer can resume later without signing up again from zero. You decide separately how any already-open invoices from before the pause get handled.
`trialing` is a free trial that hasn't been charged yet. `active` is current and paid. `past_due` means a renewal failed and Stripe is retrying it. `canceled` means it's ended. `unpaid` means the retries ran out without a successful charge. Those statuses are what should drive access decisions, not a manual check of the dashboard.
There isn't a flat monthly fee for Billing on most accounts; you pay Stripe's normal processing rate on each recurring charge, with an additional small percentage for the Billing feature itself on some account tiers. Check Stripe's current pricing page for your specific account type before assuming a number that may have already changed.
Billing is built for automatic, recurring charges on a schedule, subscriptions that bill themselves. Invoicing is built for one-off invoices a customer pays manually, often used for larger B2B payments where net-30 terms make more sense than an automatic card charge. We cover Stripe Invoicing on its own here.