n-Stripe Billing Runs the Charge. Here's What Still Needs a Decision After That.
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.
How Stripe actually handles recurring billing
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.
Where a subscription event needs to go further than Stripe does on its own
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.
What we build on top of Stripe Billing
Access that follows the subscription status, not a spreadsheet
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.
Usage numbers reported on schedule, not typed in from memory
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.
What still waits on a person after a subscription changes in your business?
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.
Still chasing subscription changes by hand after Stripe already knows about them?
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