Every subscription business bleeds revenue from failed payments. The number most teams underestimate is how much. Stripe's own published benchmark says involuntary churn, where a customer's card is declined for fixable reasons like an expired card or insufficient funds, accounts for roughly 20-40% of all churn on subscription businesses, depending on the study (Stripe Atlas churn playbook, Recurly research). That is not customer dissatisfaction. That is recoverable revenue sitting in your payments stack with no one reaching for it.
The fix is automation. Stripe already retries failed payments on its default Smart Retries schedule, but the default schedule is conservative and the surrounding workflow, including the email dunning, the alert routing, and the recovery escalation, is almost always manual. A real recovery workflow ties Stripe webhooks to a dunning sequence, routes exceptions to a human, and watches the right metrics so you can tell whether your automation is actually working or just sending more emails.
This guide walks through the recovery workflow that small and mid-sized subscription businesses should ship. The goal is simple: more failed charges recover without a human looking at them, fewer customers churn over a $9 card issue, and clear visibility into what is happening when the system does need attention.
What "payment failure recovery" actually means
Three terms get conflated in most product conversations. They are not the same thing.
- Involuntary churn. A customer wants to stay subscribed but their payment method stops working. Card expired, bank flagged the charge, insufficient funds, fraud filter caught a legit transaction. The product did not lose this customer. The payment stack did.
- Voluntary churn. A customer actively cancels. No amount of retry logic helps here. The right move is to surface the cancel reason, not to retry the card.
- Dunning. The structured sequence of messages and retries that runs after a payment fails. The word comes from old-world debt collection, but in SaaS it has been cleaned up to mean a respectful, time-bounded sequence of emails, in-app prompts, and smart retries aimed at getting the customer's payment method updated.
The recovery workflow this guide builds is for involuntary churn only. It assumes the customer wants to stay. If you also need voluntary-churn flows (win-back, save-the-cancel-page, downgrade offers), those are a separate playbook.
Recovery automation is not about being more aggressive. It is about being faster, more accurate, and less dependent on someone noticing a failed charge in the dashboard.
Why the Stripe default is not enough
Stripe Smart Retries uses a model trained on billions of payments to pick retry timing. Out of the box, it recovers roughly 40-50% of failed payments that are retried (Stripe documentation). That is a great baseline and you should keep it on.
Where the default falls short:
- It only retries. It does not send an email. It does not pause the subscription. It does not tell your CS team a VIP is about to lose access. You have to wire those up yourself.
- The default schedule is conservative for some industries. A B2C consumer subscription with a $9 monthly price can usually tolerate a more aggressive retry schedule than a $499/month B2B contract where the customer is on vacation for two weeks.
- Failure modes are not all the same. A card expired for two weeks needs a different email than a charge that was blocked by the issuer's fraud filter on a first attempt. Smart Retries treats them the same.
The fix is to layer your own dunning and routing on top of Smart Retries. Stripe gives you the retry engine. You bring the customer communication, the segmentation, and the escalation logic.
The four-part recovery workflow
Here is the structure most teams should ship in the first iteration. Each part is small enough to build in a weekend and stack into something more sophisticated over time.
1. The webhook listener
Stripe fires a webhook for every interesting state change on a charge, invoice, subscription, or payment intent. The events that matter for recovery are:
invoice.payment_failed: an invoice could not be charged. The clock starts here.invoice.payment_action_required: the bank requires 3DS or SCA authentication. Customer must act.customer.subscription.updated: the subscription status changed (often topast_dueorunpaid).charge.refunded: you refunded a charge. Useful for the metrics loop later.
Your webhook handler does three things and only three things: verifies the signature, normalizes the event into your internal shape, and enqueues a job. Do not call third-party APIs synchronously from inside the webhook handler. If your dunning service is down for ten seconds, Stripe will mark your webhook endpoint as failing and start exponential-backoff retries, which is the opposite of what you want during a payment failure.
The simplest production-ready shape:
<figure> <img src="/blog/img/stripe-payment-failure-recovery-automation-2.webp" alt="Vintage robot reviewing failed payments at an operator workstation" /> </figure>// Stripe webhook handler (pseudo-code)
app.post('/webhooks/stripe', express.raw({ type: 'application/json' }), async (req, res) => {
const sig = req.headers['stripe-signature'];
let event;
try {
event = stripe.webhooks.constructEvent(req.body, sig, process.env.STRIPE_WEBHOOK_SECRET);
} catch (err) {
return res.status(400).send(`Webhook signature error: ${err.message}`);
}
// Acknowledge immediately, then enqueue
res.status(200).send();
await dunningQueue.add('handle-event', { type: event.type, data: event.data });
});
The res.status(200).send() line matters. If you wait until after the dunning work is done, Stripe thinks your endpoint is slow and may disable it.
2. The dunning state machine
Once the event is in your queue, it needs to land in a state machine that drives the customer's next touchpoint. Most teams start with five states:
| State | Trigger | Next action |
|---|---|---|
failed_first | First invoice.payment_failed for this invoice | Send email "your card was declined", kick Stripe Smart Retries |
failed_retry_exhausted | All Stripe Smart Retries have failed | Send email "update your card", in-app banner |
action_required | invoice.payment_action_required (3DS / SCA) | Send email "confirm your payment", include deep link |
recovered | Any subsequent successful payment on the failed invoice | Send email "you're back", cancel all pending dunning |
abandoned | N days since first failure (default 14, configurable by plan tier) | Cancel subscription, send final email |
The state machine lives in a single table or document per subscription. Every state transition writes a row with a timestamp. That history becomes the most useful dataset for tuning the workflow later.
3. The dunning email sequence
The emails are where most of the recovery actually happens. The four-email sequence below is the minimum viable version. It assumes a monthly billing cadence.
- Email 1, day 0: "We had trouble charging your card." Soft tone. Link to update payment. No mention of cancellation yet. Most subscribers see this and just fix it.
- Email 2, day 3: "Still no luck." Add a one-line explanation of the most likely cause (expired card, bank flagged it). Include a one-click "update card" link pre-filled with their last-used card.
- Email 3, day 7: "We'll cancel your subscription on day X unless we hear from you." Specific date. Include the consequences (loss of access, loss of saved data). This is the email that pulls most stragglers back.
- Email 4, day 14: "Your subscription is canceled." Final notice. No recovery offer in this email. The recovery offer goes in the win-back flow after cancellation, where it has a much higher success rate.
The whole sequence can be run from any of the standard automation tools (Zapier, Make, n8n, Customer.io, SendGrid, Postmark), whatever your team already uses. The wiring matters more than the tool.
4. The escalation alerts
Some failed payments should never reach the dunning sequence. They should page a human immediately.
- Charges over a configurable threshold (often $500 or above) where the customer is on an annual or enterprise plan.
- Multiple consecutive failures across the same customer within a rolling 30-day window.
- First-time failure on a customer whose account was provisioned by your CS team (any touch of a manual onboarding signals higher LTV and lower tolerance for surprise cancellations).
- Failures tagged with specific Stripe
decline_codevalues likedo_not_honor,fraudulent, ortransaction_not_allowed, where the customer almost certainly needs a human to walk them through a fix.
The escalation routes to a Slack channel or a PagerDuty service, with a link to the customer's Stripe dashboard view and the last 30 days of payment events. The alert should not auto-retry. It should hand off to a human who decides.
Wiring it together in Zapier or Make
The full code path in the section above is overkill if your team runs on Zapier or Make. The equivalent workflow is roughly:
- Trigger: Stripe "New charge" or "Failed payment" event.
- Filter: Continue only if
charge.status = 'failed'andamount >= <your threshold>. - Lookup customer in your CRM (HubSpot, Pipedrive, Salesforce) by Stripe customer ID.
- Branch on
decline_code: different dunning copy forexpired_card,insufficient_funds,card_velocity_exceeded, etc. - Add to dunning sequence in your email tool with a 0/3/7/14-day cadence.
- Create task in your CRM for the CS team if amount > $500.
- Post Slack alert if amount > $500 OR customer is in a manual-onboarding segment.
A single Zap or Make scenario can run this whole flow. The CRM lookup and the Slack alert make it more useful than a pure email dunning, because now the right human sees the high-value case before the customer notices.
The metrics that tell you whether it is working
The whole workflow is invisible to your team if you do not measure it. Five numbers, all derivable from Stripe data plus your email tool's event log:
| Metric | What it tells you | Target (consumer subscription) |
|---|---|---|
| Involuntary churn rate | What % of MRR left the business last month due to failed payments | Under 3% of MRR for B2C, under 1% for B2B |
| Recovery rate | What % of failed charges recover within the dunning window | 50-70% for monthly, 60-80% for annual |
| Time to recovery | Median hours from first failure to successful retry | Under 72 hours |
| Email open rate | Whether the customer is reading your dunning copy | 50%+ on email 1, 35%+ on email 2 |
| Update-card rate per email | Which emails actually drive payment-method updates | 15%+ on email 3, 5%+ on email 1 |
If your recovery rate is under 40%, the workflow is broken somewhere. The most common cause is that the dunning email's "update card" link lands on a generic account-settings page instead of a focused, mobile-friendly payment-method update screen. The fix is one page redesign and usually a 10-point recovery lift.
If your email open rate is under 40% on email 1, the customer's email on file is probably stale (an old work address, a personal email they check rarely) or your sending domain's SPF/DKIM/DMARC records are misconfigured. Both are tractable. Stale emails take longer.
What to skip on the first build
It is tempting to build the whole state machine, the CRM integration, and the Slack alerts at once. Resist that. Ship these four things in this order:
- The webhook listener with signature verification and queueing.
- The four-email dunning sequence triggered by
invoice.payment_failed. - The single Slack alert for charges over your threshold.
- The five-metrics dashboard.
That is roughly two to three days of work for one engineer. Everything else (the decline-code branching, the CRM integration, the escalation logic) is iteration once you can see the first version working.
<figure> <img src="/blog/img/stripe-payment-failure-recovery-automation-3.webp" alt="Vintage robot celebrating a fully automated recovery workflow with flowchart and checkmark" /> </figure>When to revisit and tune
The default cadence (0/3/7/14) is a starting point, not the answer. The right schedule depends on your customer, your price point, and your churn tolerance. A weekly newsletter subscription at $5/month can run a tighter cadence (0/2/5/10) because the customer feels the loss of access fast. An annual B2B contract at $5,000/year should run a much more forgiving schedule (0/5/14/30) because the customer's accounting team is the one who needs to fix the card, and they only run AP on Tuesdays.
The right way to tune is to instrument every state transition with a timestamp, run the workflow for 60 days, then look at the recovery-rate curve by day-since-failure. The day your curve flattens out is the day your cadence should stop. Most consumer subscriptions flatten out around day 10. Most B2B contracts flatten out around day 25.
Recovery automation is a feedback loop, not a one-time setup. The first version gets you to baseline. The tuning gets you the next 10 points of recovery rate.
The bottom line
Stripe Smart Retries will recover roughly half of your failed payments by default. A four-email dunning sequence, a Slack alert for high-value cases, and a five-metric dashboard will push that recovery rate into the 60-75% range and give you visibility into the cases that still fall through. The whole workflow is small enough to ship in a weekend and valuable enough to pay for itself within the first billing cycle.
If your team is already drowning in failed-payment tickets, this is the highest-leverage automation you can ship. If your team is not yet drowning, this is the automation that keeps them from drowning six months from now when the subscription base doubles.