RevGuard Stripe Smart Retries: what they do, when they never run, and what they leave behind
Smart Retries recover about half of failed payments. This guide covers what happens to the rest and what to add.
What Smart Retries actually do
When an invoice payment fails, Stripe schedules up to four more attempts over roughly two weeks, timed by a model that looks at when similar cards succeeded. After the last attempt it applies the setting you chose in Billing: leave the subscription past due, cancel it, or mark the invoice uncollectible. Stripe's own published figure is that this recovers around half of failed recurring payments. Baremetrics' benchmarks across their customers put failed payments at 4% to 9% of MRR every month, so half back still leaves 2% to 4.5% of MRR on the floor, monthly.
When they never run
Look at next_payment_attempt on the failed invoice. When it is null on the first failure, no retry is scheduled. This happens for hard declines such as an expired or cancelled card, where a retry is pointless, and also for certain issuing banks and countries where Stripe's model expects retries to fail. Those invoices sit in past due until your own settings cancel the subscription. From the customer's side, nothing happened. From yours, a customer who wanted to stay is gone.
What they do not do
- They do not ask for a new card. Stripe sends a generic failed-payment email if you enable it. It is one email, not a sequence, and it is not in your voice.
- They do not time retries by decline reason. An insufficient-funds decline wants a payday. A technical error wants an hour. Smart Retries use one model for both.
- They do not tell you why customers slip. The Stripe dashboard shows a list of past-due invoices. It does not show that 60% of your losses are one decline code from one country.
- They do not touch PayPal. If you also bill through PayPal, PayPal retries on its own schedule and then suspends the subscription, and nothing on the Stripe side knows.
What to add on top
Three things, in order of return:
- An email sequence with a fresh card-update link in every message. Billing-portal links expire, so mint one per email. Churnkey's involuntary-churn data puts retries plus a three-to-four email sequence at about 70% recovery, against about 51% for retries alone.
- Retries branched by decline code. The decline code guide has the exact groups. The free classifier on GitHub does the branching.
- An expiring-card warning. Cards expiring in the next 45 days are visible in Stripe today. Email those customers before the charge fails and the failure never happens. This matters most on annual plans, where one failed renewal is a whole year and recovery rates run far lower.
Monthly tool, or one-time setup
The tools that do this as a service, Churnkey, Baremetrics Recover and ProfitWell Retain among them, charge either a monthly fee or a share of what they recover. For a business under $50k MRR that is often $100 to $300 a month for the life of the business. RevGuard is the same loop as a one-time purchase, from $49, that runs on your own machine, with your billing data never leaving it. The comparison lists what each alternative does that we do not, so you can pick honestly.