The settings, retries, and dunning sequences that turn payment failures into recovered MRR.
Most SaaS founders accept involuntary churn as a cost of doing business. They shouldn't. Of every 100 failed renewals, 50–70 are recoverable with the right Stripe configuration and a thoughtful dunning workflow. This guide is the playbook.
Before optimising, measure. Pull the last 90 days of failed invoices from Stripe and check what percentage eventually succeeded (within 14 days). If you're below 50%, the rest of this guide will roughly double your recovery. If you're above 70%, you're already doing well — focus on the long tail.
In your Stripe dashboard, go to Settings → Subscriptions and emails → Recovery and enable Smart Retries. This replaces Stripe's default fixed-interval retry schedule with an ML-driven schedule that times retries when the customer is most likely to have funds. Typical lift: 10–20% of total recovery.
Smart Retries are free and work better than any custom retry logic you'll build. Don't overthink this.
Half of card declines are 'card_declined' due to expiry or replacement. Stripe's Card Account Updater automatically gets the new card from Visa/Mastercard networks (the customer's bank issued it) for $0.25 per update. Enable it under Billing → Subscriptions. Typically pays for itself 50× over.
Card Account Updater only covers Visa and Mastercard. Amex and Discover require manual customer outreach.
Stripe sends one dunning email by default — disable it and send three from your own email infrastructure: (1) immediately on failure, soft and informational; (2) at 4 days, with the 'your service may be interrupted' framing; (3) at 10 days, last call before suspension. Personalise sender to a real human name and reply-to. Recovery rates roughly double versus a single notification.
Each dunning email should link directly to a Stripe customer portal session where the customer can update their card in two clicks. Don't make them log in, navigate to billing, find the right card. The shorter the path, the higher the recovery.
Generate a portal link server-side per email so the link is pre-authenticated. Stripe's Billing API supports this.
Decide when a failed subscription becomes a cancelled one. Stripe's default is 4 retries over 21 days. Most SaaS should use 21–30 days — long enough for genuine recovery, short enough that you're not carrying inactive customers. Configure under Subscriptions → Recovery → 'How long should we retry?'
Recovery rate (recovered MRR / failed MRR) should be reviewed monthly. If it drops, something changed: a payment processor outage, a checkout regression, an email deliverability issue. Treat it like any growth metric.
Done well, payment recovery is the highest-ROI work you'll do this quarter. Most founders ignore it. That's the opportunity.
FlowMRR detects failed payments, runs your dunning sequence, and reports recovery rate per cohort — out of the box.
Set up Recovery in FlowMRRA SaaS with 3% involuntary churn going from 30% to 65% recovery effectively saves 1 percentage point of monthly churn. On $50K MRR that's $500/mo recovered, $6K/year — usually 50× the engineering cost in the first year.
Your own. You'll get better deliverability (Stripe's IPs are shared with millions of merchants), better branding, and more granular A/B testing. Use Stripe's webhooks to trigger your sequence.
