The structured process of recovering revenue from failed subscription card charges — the quiet 5–10% of MRR that walks out the door when solo founders ignore involuntary churn.
Research-based overview. This article synthesizes Stripe Billing documentation, public industry benchmarks from ProfitWell and Recurly, and vendor pricing pages. How we research.
The word “dunning” sounds like it belongs in an 1880s ledger book, and in some sense it does — the term originally referred to a creditor demanding payment. In modern SaaS it describes something subtler: when a customer’s card declines on a $29 monthly renewal, your billing system has to decide what to do next. The retry timing, the email copy, the day the subscription gets paused, and the URL that lets the customer update their card — that whole choreography is dunning.
Most solo founders treat dunning as a settings page they never visit. The result is a slow leak in MRR: the customer is simply gone, with no clear villain. Stripe and ProfitWell have published industry data suggesting that 5–10% of recurring revenue is lost to failed payments rather than to active cancellation, depending on price point, customer geography, and card mix. For a $5K MRR product that is roughly $300–$500 in monthly leakage, $3.6K–$6K a year — usually fixable with a few hours of configuration.
Before going deeper, the vocabulary matters. Churn comes in two flavors:
The reason this distinction matters is that involuntary churn is, in a real sense, free money on the floor. The customer already wants the product; the only thing standing between you and the renewal is a failed network call to Visa. Our broader writeup on what churn rate is and how to measure it covers the metric side; this page is about the recovery mechanics specifically.
Failed renewals come in two distinct shapes that require different responses:
The card is still on file, but the issuing bank refused to authorize the charge. Common reasons include insufficient funds, daily-spend caps, fraud-prevention algorithms flagging a recurring merchant as suspicious, or transient network issues at the processor. These are often recoverable — retrying the same card a few days later succeeds about half the time, especially for soft declines like “insufficient funds” or “issuer unavailable.”
The card on file is no longer valid. The customer’s wallet was stolen, the card expired, the bank reissued the card with new digits, or the customer canceled that card entirely. No amount of retrying the dead card will succeed; the customer has to log in and update their payment method. Recovery here depends entirely on whether you can get the customer’s attention, send them to an update form, and have them complete it before they decide they don’t care anymore. Stripe’s Card Account Updater service partially solves the “reissued” case automatically by syncing new card numbers from the major networks, but expirations and cancellations still need a human in the loop.
A complete dunning sequence has four moving parts: retry scheduling, customer email cadence, account-state transitions, and a payment-update path. Each one matters, and the difference between a good flow and a default one is often hundreds of dollars per month per thousand subscribers.
The first instinct is to retry on a fixed schedule — say, day 1, day 3, day 7. This works, but not well. Stripe’s public documentation on Smart Retries describes a machine-learning approach that adjusts retry timing based on the historical success rate of similar charges — the card brand, the decline code, the time of day, the customer’s prior payment behavior, and the merchant’s industry. Stripe reports that Smart Retries recover meaningfully more revenue than a fixed schedule, which is the lift that justifies their continued investment in the feature. Specific recovery percentages will vary by merchant, but the directional benefit (smarter timing recovers more cards) is documented in their research and in Stripe’s authorization-rate guides.
On Stripe Billing this is a checkbox in Settings → Subscriptions and emails → Smart Retries. The alternative is a flat retry schedule that ignores everything Stripe has learned from billions of historical attempts.
The retry alone is not enough. Roughly half of dunning recovery comes from the customer noticing the failure and updating their card — which only happens if you tell them. The standard pattern is a three-email cadence:
Stripe Billing ships templated versions of all three emails, enabled in Settings → Subscriptions and emails. The defaults are workmanlike but bland; replacing them with branded copy often lifts open rates. Avoid sending more than three emails per cycle — the marginal recovery from email four onward is small, and unsubscribe risk grows.
What happens if the customer doesn’t respond? The two common patterns are:
After the pause cliff, the subscription transitions to canceled. Some founders skip the pause entirely and cancel directly; this is a mistake because canceled subscriptions are psychologically harder to revive than paused ones. The pause-then-cancel pattern gives you a second recovery window in the form of post-pause re-engagement emails (“your account is paused; one click to reactivate”).
Every dunning email needs a single, frictionless link to update payment. Stripe’s hosted Customer Portal handles this for free — one configuration, a single URL per customer, and the customer can update card details without you writing any UI. The combination of Smart Retries plus Customer Portal plus the default email templates is what most solo founders should be running before considering a third-party tool.
If you are on Stripe (and most solo SaaS are; see our best payment processor for SaaS roundup), the built-in dunning toolkit is more capable than founders realize. The features included for free with Stripe Billing:
invoice.payment_failed, customer.subscription.updated) so you can trigger custom downstream behavior.None of this costs extra; it is part of the standard 0.5% Billing fee on top of the base 2.9% + 30¢ processing rate. Configuration lives in Settings → Subscriptions and emails. If you are wiring Stripe Billing into a Next.js + Supabase stack, our walkthrough on how to set up Stripe subscriptions with Supabase covers the webhook side, and Stripe pricing explained covers the cost math.
Tools like Churnkey, Recover (by Baremetrics), and Stunning sit on top of Stripe and add features Stripe does not ship: in-app dunning modals (rather than only email), failed-payment-specific cancel flows, branded payment-update pages with offers, A/B testing of retry copy, and analytics dashboards focused on involuntary-churn recovery.
These tools typically price between $99 and $499 per month, scaling with MRR or recovered revenue. The decision rule is simple: if Stripe’s built-in dunning is already running and you want incremental lift, a third-party tool is justified once your involuntary-churn dollar volume exceeds the tool’s monthly fee by a comfortable margin. A $5K MRR SaaS losing 7% to involuntary churn ($350/month gross loss) doesn’t justify a $299/month tool. A $50K MRR SaaS losing the same 7% ($3,500/month gross loss) has plenty of room.
How much should you expect to recover? Public industry numbers suggest a well-tuned dunning flow on Stripe Billing recovers roughly 50–70% of involuntary-churn dollars, varying with customer geography (US recovery is higher than emerging markets), price point (cheap subscriptions recover better because the friction-to-update ratio is lower), and customer-segment age (B2B with corporate cards recovers worse than B2C with personal cards because expense-report owners are slower to react).
The math for a typical solo SaaS:
If you are building on Stripe and want the fastest path from zero to working dunning, this is the five-step checklist:
customer.subscription.updated webhook handler that fires a transactional email when the status flips to paused. A few dozen lines of code.That setup is enough to capture most of the value most solo SaaS will ever capture from dunning. Layered improvements — in-app modals, segmented retry copy, third-party tools — are real, but they belong on a later sprint. Plug the leak first; optimize the patch later. Pair this with the broader SaaS churn reduction playbook and a clear understanding of what MRR actually measures, and the involuntary-churn part of your business stops being invisible.
Dunning is the unglamorous infrastructure that decides whether the 5–10% of MRR represented by failed cards turns into recovered revenue or quiet attrition. The math overwhelmingly favors getting it right: a few hours of configuration, a webhook handler, and one custom email can capture 50–70% of involuntary-churn dollars that would otherwise be gone. Stripe Billing ships most of what you need for free; third-party tools are worth their fee only after you’ve squeezed the basics. Build the minimum-viable flow first, measure the recovery rate every month, and treat involuntary churn as a fixable operational problem rather than a fact of life.
The stack, prompts, pricing, and mistakes to avoid — for solo founders building with AI.