Coordinate retries and customer reminders, then measure the outcomes.
Content reviewed:
Failed renewals have different causes: temporary funding problems, expired cards or hard declines. Recovery depends on your customers, payment methods and follow-up. Start with a measured baseline, then coordinate Stripe retries and customer communication.
Recovery operations and measurement, not guaranteed recovery rates. Configure and test changes in a sandbox before applying them to live billing.
Choose a cohort of failed invoices and a fixed recovery window, for example 14 days. Use cohorts old enough to have completed that window. Measure both invoice count and recovered amount, separating currencies or converting consistently. Compare the same definitions before and after a change; no recovery percentage is a universal benchmark.
Review Smart Retries in Stripe's revenue recovery settings. Stripe recommends 8 tries within 2 weeks by default; the schedule is configurable. Hard declines require a new payment method before collection can resume. attempt_count may increase even when a scheduled retry does not execute a charge, so inspect payment outcomes too.
Coordinate automated and manual retries to avoid overlapping collection attempts. Check current Stripe terms and your contract rather than assuming retries are free.
Automatic card updates are enabled by default for saved cards when the issuer supplies updated details. Coverage depends on the card and issuer; supported cards cannot be predicted in advance. An update can help with an expired or replaced card, but it does not resolve every decline.
Do not look for a separate Billing toggle or assume a fixed per-update fee. Check your contract and current Stripe terms, and offer a secure way for customers to update their payment method.
Review Stripe's email settings before adding your own reminders, to avoid duplicate messages. An illustrative sequence is a notice on failure, a reminder on day 4 and a final notice on day 10, only if those dates match your retry and access policy. Stop reminders when payment succeeds. Use a monitored reply address and state any service interruption accurately; test delivery rather than assuming more emails improve recovery.
Link emails to an authenticated billing route in your app. After authentication and a server-side ownership check, create a fresh Stripe customer portal session. Never trust a browser-supplied customer ID or bypass authentication to shorten the flow.
Customer portal setup and ownership checksA generated portal session expires after 5 minutes if unused, or within 1 hour of the latest activity once used: it is not a persistent email link. Alternatively, use Stripe's reusable portal login link, which requires Stripe email authentication.
Choose what happens after retries are exhausted: keep the subscription recoverable, mark it unpaid or cancel, according to your terms and Stripe configuration. Align the retry window, access policy and customer notices. The recommended Smart Retries default is 8 tries within 2 weeks, not a universal cancellation deadline.
Review recovered invoice amount divided by failed invoice amount within your chosen window, alongside recurring revenue at risk. Invoice amounts and MRR are different measures: do not label one as the other. Investigate changes in decline reasons, delivery, payment methods and cohort maturity before attributing a change to your reminders.
A reliable recovery process combines measured outcomes, clear customer messages and controlled payment attempts. Improve it against your own baseline, without assuming a guaranteed return.
Once Stripe is connected, explore FlowMRR's Stripe MRR analytics and failed payment recovery.
Use FlowMRR to prioritise failed payments, send recovery emails and make authorised manual retries. Stripe controls automatic retries.
Estimate from your own mature failure cohorts, recoverable balances and costs. Recovered invoice cash is not necessarily recovered MRR: taxes, billing intervals and one-off items can differ. No recovery rate or return on engineering effort is guaranteed.
Either can fit. Compare branding, delivery monitoring, implementation cost and the controls you need. Coordinate both systems to avoid duplicate reminders and stop your own sequence on successful payment; do not assume one sender has universally better deliverability.
