Stripe Can Now Auto-Pause a Subscription Instead of Canceling It for a Failed Payment. Flexible Billing Mode Is the Catch.
Stripe shipped automatic pause-on-payment-failure for subscriptions on Sept 30. Here's exactly when it fires, what it requires, and what it replaces.
For as long as Stripe Billing has existed, a subscription that exhausted its payment retries had exactly one native outcome: cancellation. You could soften that with pause_collection hacks or your own past_due grace-period logic, but the subscription object itself either stayed active or died. As of the September 30 Endive release, there's a third, native option — Stripe can pause the subscription automatically the moment a renewal payment fails, instead of canceling it once retries run out.
That 9% doesn't come from unhappy customers. It comes from subscriptions that quietly died because a card expired or a bank declined a charge, and the old default — cancel once retries run out — treated every one of those subscriptions the same way it treats a customer who deliberately hit cancel. The new option gives you a way to stop doing that by default, without writing the webhook logic yourself.
What actually ships: two triggers, one status
You can configure Stripe Billing to automatically pause an eligible subscription in two distinct situations, and you can turn each on independently:
- After the first payment attempt fails on a renewal invoice — pause immediately, don't even run the retry schedule.
- After retries are exhausted on an invoice that isn't part of a pending update — the point where, previously, cancellation was the only native outcome.
While paused this way, the subscription stops generating new invoices entirely, and — this is the detail that matters for your books — the invoice that triggered the pause stays open and collectible. Stripe isn't writing off the failed charge; it's freezing the subscription around it so the debt doesn't compound into invoice after invoice while the customer figures out their card situation.
You can configure automatic resumption for when that invoice is eventually paid, or when someone manually marks it uncollectible, and you choose separately whether resuming resets the billing cycle anchor to the resume date or preserves the original schedule. That anchor choice isn't cosmetic — reset it and a customer who recovers nine days into what should've been their next cycle gets a fresh full period from the resume date; leave it alone and they rejoin mid-cycle like nothing happened. We walked through the same tradeoff in the context of trial conversions moving the billing cycle anchor, and the stakes here are the same: pick the option that matches what you actually told the customer would happen.
To tell which trigger fired without reconstructing it from invoice history, check status_details.paused.subscription.type on the subscription object. It returns first_payment_failure or final_payment_failure — a distinction worth routing differently in your dunning emails, since a subscriber paused on the first attempt probably just has a timing issue, while one paused after four exhausted retries has a harder problem.
The catch: flexible billing mode only
None of this works unless the subscription is on flexible billing mode, the newer billing engine Stripe has made the default for subscriptions created under API version 2025-09-30.clover or later. If your integration predates that and you haven't explicitly migrated, your subscriptions are almost certainly still running on classic billing mode — and on classic, a failed payment still only ever leads to the behavior you already had configured, whether that's past_due with a grace period or outright cancellation.
Migrating is a one-way door. Stripe's own docs are explicit that you can move a subscription from classic to flexible billing mode, but never back. The migration itself is simple — one API call, or a dashboard toggle — but it changes proration math, usage-based billing calculations, and cancellation behavior for all activity on that subscription going forward, and none of your pre-migration invoice items get recalculated under the new rules. If you're running a mature product with years of subscriptions on classic billing mode, that's a real audit before you flip the switch, not a config change you make during a dunning cleanup sprint.
Why pause-by-default beats cancel-by-default
The economic case isn't subtle once you compare what happens to a subscription after each outcome. A canceled subscription is gone — the object still exists in Stripe's records, but getting the customer back means a new checkout, a new payment method capture, and in most self-serve products, the customer actively choosing to sign up again. A paused subscription is still there, still attached to the same customer, still one successful charge away from resuming exactly where it left off.
Sources: Recurly, 2026 State of Subscriptions Report (pause reactivation); RevenueCat, State of Subscription Apps 2026 (post-cancellation reactivation)
Those two numbers aren't measuring identical populations — the Recurly figure covers subscribers who paused deliberately, the RevenueCat figure covers mobile app subscribers who fully canceled — but the gap between them is the entire argument for this feature. Preserving the subscription record changes what "winning the customer back" requires, from a new sale to a single successful charge.
Cancellation-by-default for nonpayment never made that distinction. It treated a customer whose card expired mid-renewal exactly like a customer who read your product, decided it wasn't worth it, and clicked cancel. Both ended up with a dead subscription and a "resubscribe" flow standing between them and coming back. Auto-pause-on-failure gives you a dunning endpoint that matches the actual situation: this person didn't leave, their card did.
How the three failed-payment outcomes compare
| Outcome | Who triggers it | Subscription status while waiting | How it resumes |
|---|---|---|---|
| Cancel on exhausted retries (old default) | Stripe, automatically, once retries run out | canceled — subscription object terminated | New checkout, new subscription |
| pause_collection | You, via application code | Unchanged — still reports as active | Unset pause_collection, or wait for resumes_at |
| On-demand pause endpoint | You, usually from a retention offer a customer accepts | paused — distinct status | Dedicated resume endpoint, manual call |
| Automatic pause-on-failure (new) | Stripe, automatically, on first failure or exhausted retries | paused — same status as on-demand pause | Automatic, when the triggering invoice is paid |
The new option shares its underlying status with the on-demand pause endpoint Stripe shipped earlier this year — both land on the same paused value, with the same no-invoices, no-cycle-advancement behavior. The difference is purely who pulls the trigger and why. One is a retention offer a customer opts into; the other is dunning logic acting on a subscription nobody asked to pause. If your reporting already knows how to treat paused as its own bucket separate from active and canceled — which it should, if you built anything against the on-demand pause endpoint — you don't need new analytics code to handle this. You need webhook logic to decide when to turn it on.
What to actually configure
Three decisions, each with a real downstream consequence:
1. Pause on first failure, or wait for retries to exhaust?
Pausing on first failure is aggressive — it skips Stripe's Smart Retries entirely for that invoice, which means you give up the 10–15% recovery lift Smart Retries typically adds over a fixed retry schedule. It makes sense for low-ACV or high-fraud-risk segments where a failed first attempt is rarely a timing fluke. For most SaaS products, pausing only after retries are exhausted keeps the recovery benefit of retries while replacing the old cancel-for-nonpayment endpoint with a reversible one. Our Stripe dunning guide covers the retry-schedule math in more detail if you haven't tuned yours past the defaults yet.
2. Reset the billing cycle anchor on resume, or preserve it?
Resetting gives the customer a full fresh period from their resume date, which is more generous and simpler to reason about but means your renewal dates drift every time a customer recovers from a pause. Preserving the original anchor keeps your renewal calendar predictable but can resume a customer mid-cycle with less time left than they'd expect. There's no universally correct answer — it depends on whether your billing model treats the period as a fixed calendar slot or a rolling entitlement.
3. What your webhook does with first_payment_failure vs. final_payment_failure
This is the one most teams will get wrong by default, because it's tempting to treat both the same way — "subscription paused, send a payment-update email." But a subscriber paused on the first attempt hasn't seen a dunning sequence yet; a subscriber paused after exhausted retries has already ignored however many emails your retry schedule sent. Routing both into the same generic "update your card" email wastes the urgency signal Stripe is handing you for free in the status_details.paused.subscription.type field.
Where this leaves manual pause offers in your cancellation flow
This doesn't replace the pause offer in your cancellation flow — it solves a different problem. Your cancel flow's pause offer exists for customers who choose to leave voluntarily and might come back; automatic pause-on-failure exists for customers who never chose anything, because their payment method failed. Both end on the same paused status, both are more recoverable than cancellation, and both should probably feed the same win-back sequence once you can tell them apart by status_details.paused.subscription.type versus a customer-initiated pause reason you set yourself.
If you're trying to size what moving even a fraction of your involuntary cancellations into a recoverable pause state is worth against your current numbers, our churn calculator is a quick way to model it before you commit to a flexible billing mode migration. And if your product doesn't have a cancellation flow with its own pause and discount offers built in yet, that's the gap CancelFlow closes on the voluntary side — so between the two, a card failure and a customer having second thoughts end up handled by the same playbook instead of two different ones you have to maintain separately.
Frequently asked questions
What exactly triggers Stripe's automatic pause-on-payment-failure?+
Two moments, both configurable independently: the first failed payment attempt on a renewal invoice, or the point where Smart Retries exhausts its retry schedule on an invoice that isn't tied to a pending update. Stripe records which one fired in status_details.paused.subscription.type, as either first_payment_failure or final_payment_failure, so your webhook handler can tell the two apart without guessing from invoice history.
Does automatic pause-on-failure work on classic billing mode subscriptions?+
No. It's scoped to subscriptions on flexible billing mode, the billing engine Stripe has been pushing as the default for new subscriptions since the 2025-09-30 API version. A subscription still on classic billing mode keeps following whatever cancel_at or past_due behavior you already have configured — this feature doesn't touch it at all until you migrate.
How is this different from the pause_collection attribute or the on-demand pause endpoint?+
pause_collection and the dedicated pause/resume endpoint are both things you call deliberately, usually from a retention offer a customer accepts. Automatic pause-on-failure is Stripe's own dunning logic deciding to pause a subscription on your behalf, with no human or application code in the loop, as an alternative to its other default: canceling for nonpayment. They can coexist — nothing stops a customer-initiated pause and a failure-triggered pause from using the same underlying paused status.
What happens once the invoice that triggered the pause finally gets paid?+
If you've enabled automatic resumption, Stripe resumes the subscription as soon as that specific invoice is paid or manually marked uncollectible — you don't have to poll for it or wire up your own listener for the retry outcome. You also choose, per subscription or at the account level, whether resuming resets the billing cycle anchor to the payment date or keeps the subscription's original cycle intact.
Stop losing subscribers today
One script tag. One function call. A live cancellation flow in under 10 minutes.
Start free trial →