Subscription Dunning Automation Failed payments recovered with the right retry and the right message
Failed payments are retried at the right moment and chased with the right message, and a cancellation gets one save offer.
- Run for you$247/month
- Custom build · this process$3,500–6,000 one-time
- Starts whenBilling event (Stripe / Chargebee / Recurly)
Covers one billing platform and up to 2,000 billing events a month. Multi-currency tax logic, usage-based billing or a custom cancellation flow inside your app are a custom build. Custom builds start at $2,000 site-wide; this band is for this process and its integrations.
Subscription Dunning Automation is an automation Agentmelt installs in Gmail + Twilio + Intercom and Slack + Google Sheets. The free template is a file you import yourself; the kit ($49) adds the setup guide and prompts. Installed for you costs $249 one-time and is live within two working days of access, with a recorded walkthrough and 30 days of fixes. Run for you costs $247/month, with setup and maintenance included. A custom build of this process is $3,500–6,000 one-time; custom builds start at $2,000 site-wide. No call is needed for any option. Written by Max Zeshut; last revised 2026-09-21.
Reference stack: Claude + n8n. Node names are on each step; the file is under the template.
Founder at Agentmelt
Reviews every build before it goes live; the workflow escalates to a person, never past one.
What is subscription dunning?
Subscription dunning automation recovers the customers a business loses to a failed card rather than a decision — usually its largest churn line and the one nobody looks at. The workflow watches billing events from Stripe or Chargebee, chooses a retry schedule from the decline code (a soft decline retries; a hard decline asks for a new card immediately), writes the dunning message for the specific failure, runs the sequence across email and in-app, handles plan changes and pauses, intercepts cancellations with one approved offer, and reports recovered revenue weekly. Discounts and offers are rules you set; the model writes the words.
- Involuntary churn is our biggest churn line and nobody owns it.
- The card failed, the customer got a generic email, and we found out when the account lapsed.
- Every retry is on the same schedule whether the card expired or the bank declined.
- Cancellations go straight through; nobody offers a pause or a downgrade.
- We cannot say how much revenue dunning recovered last month.
If two of these are yours, this is the process to look at first. Free audit — or read on.
What it looks like once it runs.
Involuntary churn — customers lost to a failed card, not a decision — is usually the largest churn line a subscription business never looks at. The workflow watches billing events, runs a retry schedule tuned to card decline codes, sends dunning messages written for the specific failure, handles plan changes and cancellation requests with the right offer, and reports recovered revenue weekly.
- 03:10 A card is declined. The decline code decides the plan: retry near payday, or ask for a new card now.
- 08:00 A short message for this exact situation goes out — amount, card ending, one link to update.
- Day 3, day 7 The sequence continues by email; SMS on day 7 for accounts above a value threshold.
- On a cancellation request One save offer is proposed from your approved list; finance sees the daily recovered total.
Failed payments get the billing provider's default three emails and then silently cancel. Cancellation requests get processed with no conversation. Finance finds out about revenue loss at month end.
Failed payments are recovered at a measurably higher rate because the retry timing matches the decline reason and the messages tell the customer exactly what to do. Cancellation requests get a relevant save offer or a clean exit, never silence. Recovered revenue and the reasons behind losses are on a weekly report.
Trigger, then 8 steps.
All eight steps run without anyone; a person sees only what the guardrails escalate.
Billing event (Stripe / Chargebee / Recurly)
Receive the billing event
Event type, customer, amount, decline code, card details (last 4, expiry), plan and tenure.
Choose the retry strategy
Decline code decides: insufficient funds → retry on likely payday; expired card → no retry, update-card message; do-not-honour → one retry then message; fraud → stop and alert.
Draft the dunning message
A short message for this exact situation and customer — amount, card ending, what happens next, one link to update payment — in your brand voice, with tone rules enforced.
Send across the sequence
Email day 0, 3, 7; SMS on day 7 for accounts above a value threshold; in-app banner via Intercom if available. Each step checks whether payment already succeeded before sending.
Handle plan changes and pauses
Downgrade and pause requests are processed in the billing system with the right proration and a confirmation; upgrade requests route to the expansion workflow.
Cancellation intercept
On a cancellation request, the agent reads tenure, usage and stated reason and proposes one save offer from the approved set (pause, discount, downgrade, concierge call) — or none for customers who should simply be let go cleanly.
Alert finance and the owner
High-value failures and cancellations alert the account owner with context; finance sees the daily failed/recovered tally.
Weekly recovery report
Failed amount, recovered amount, recovery rate by decline code and by message step, cancellations saved, and losses by reason.
No step waits for a person.
What the workflow hands to someone, by rule:
- Save offers come only from the finance-approved set; the agent picks, it does not invent discounts.
Failed payments are recovered at a measurably higher rate because the retry timing matches the decline reason and the messages tell the customer exactly what to do
Failed payments are recovered at a measurably higher rate because the retry timing matches the decline reason and the messages tell the customer exactly what to do.
No decisions needed. Anything the guardrails flag is handed to a person; the rest ran alone.
Each pattern page explains it in plain words and lists every automation that uses it.
The template is built on n8n (how the n8n AI Agent node works); the same steps run on Make, Zapier or plain code. The tool is chosen to fit your accounts, you own the result, and the template comes in all three formats.
A typical first month — a B2B software company with 1,400 paying accounts, on Stripe, Gmail and Intercom.
Not a client report
Around ninety payments fail a month. Each gets the billing provider's three default emails and then a silent cancellation, and the finance lead learns about the churn in the month-end revenue report. Cancellation requests are processed the same day with no conversation, and nobody can say how much of the loss was an expired card and how much a customer who meant to leave.
The first month- Day 1Failed-payment, cancellation and card-expiring events reach the workflow. Every message is drafted and held for the finance lead to read; retries follow the card-network rules rather than the provider's default schedule.
- Week 1The finance lead reads about thirty drafts and approves the tone. The save-offer set is agreed — a two-month pause, a downgrade, a call — and the agent picks from it; it cannot invent a discount.
- Week 2Messages go out on their own. Each says which card, how much, what happens on which date, with one link straight to the update form. 'Insufficient funds' retries after the likely payday; 'expired card' skips retries and asks the customer to act.
- Week 3Day-7 messages for the higher-value accounts go by SMS. Cancellation intercepts start: one relevant offer or a clean exit, and anyone who declines the offer is cancelled that day.
- Week 4The first weekly recovery report: recovered revenue by decline reason, save rate by offer, and the losses with their reasons. Finance drops one offer nobody takes.
| Metric | Before | After a month |
|---|---|---|
| Recovery rate on failed payments | the provider's default | measured weekly by decline reason — the one number this table cannot give you |
| Customers chased for a paid invoice | it happens | none — payment status is checked before every message |
| Cancellations that got a conversation | none | all of them: one offer, or a graceful exit |
| When finance learns about a loss | at month end | on the weekly report, with the reason |
The blueprint gives no recovery-rate range on purpose: it depends on your mix of decline reasons and how your customers treat their cards. At ninety failures a month the weekly report shows a readable rate by week three; that is where the figure comes from.
This is a worked example, not a client's results: the company is a composite of a stated size, and the figures are the ranges this blueprint's own metrics make typical at that size. A real engagement replaces it, with permission, once an install has run a month.
Data it touches
- Billing platform events and customer data (Stripe, Chargebee, Recurly, Paddle)
- CRM account owner and tenure
- Product usage (for save-offer decisions)
- Approved save-offer set (finance-owned sheet)
Guardrails
- Retry schedules respect card-network rules and the provider's limits.
- Save offers come only from the finance-approved set; the agent picks, it does not invent discounts.
- Customers who ask to cancel and decline the offer are cancelled promptly — no dark patterns.
- Every message step checks payment status first so nobody is chased for a paid invoice.
Why decline codes matter
A failed payment is not one thing. 'Insufficient funds' usually succeeds if retried after the customer's likely payday; 'expired card' will never succeed and needs the customer to act; 'do not honour' is the bank being cautious and often clears on a second attempt days later; a fraud flag should stop everything. Billing providers' default retry logic treats them similarly. Matching the retry timing and the message to the code is where the recovery-rate improvement comes from — and it is pure workflow logic.
Messages that get cards updated
The default dunning email says a payment failed and links to a portal. The workflow's message says which card, how much, what will happen on which date, and gives one link that opens the update form directly. It is sent from a person, and the day-7 message for valuable accounts goes by SMS because email is where dunning gets ignored. The agent's role is making that specificity automatic without the tone slipping into threatening.
Cancellations: save or release
Not every cancellation should be fought. The agent looks at tenure, usage and the stated reason and either proposes one relevant offer from the approved set — pause for two months, a downgrade, a call — or recommends a clean exit with a short, graceful confirmation. Customers who decline the offer are cancelled immediately. The report shows save rate by offer and by reason, which is how finance decides what to keep offering.
What it connects to.
| Tool | Role in this workflow |
|---|---|
| n8n | Event handling, sequences, reporting |
| Stripe / Chargebee / Recurly | Billing (unchanged) |
| Claude | Dunning messages and save-offer selection |
| Gmail + Twilio + Intercom | Email, SMS, in-app |
| Slack + Google Sheets | Alerts, offer set, reports |
Want this running without building it?
$247/month
We set it up in your tools, run it on our servershost it on our n8n cloud (or deploy it to your own n8n, Make or Zapier), watch it, and fix it when something changes. Setup included, cancel monthly; the automation stays yours if you leave.
$3,500–6,000 one-time
Your systems, your rules, your edge cases. A one-off build delivered into your accounts to keepon Claude and n8n, delivered into your accounts to keep, with documentation and a recorded walkthrough.
Covers one billing platform and up to 2,000 billing events a month. Multi-currency tax logic, usage-based billing or a custom cancellation flow inside your app are a custom build.
One-time, in your own accounts
Do it yourself $49 — the workflow file for your automation toolthe n8n workflow and the Make blueprint with the setup guide, prompts, message templates and test checklist; you import it. Installed for you $249 — we put it into your accounts within $two working days of access, in your voice, with 30 days of fixes. The first is credited in full against the second for 30 days. No call for either.
When this becomes a custom build.
The subscription covers the standard version — $247/month, setup and maintenance included. Three things move it to a custom build ($3,500–6,000 one-time), delivered into your accounts to keep. If one of them is you, say so on the audit and the plan prices both.
Multi-currency tax logic, or usage-based billing where the amount to recover changes daily.
A cancellation flow inside your app — save offers, downgrades and pauses presented to the customer directly.
More than one billing platform, or above 2,000 billing events a month.
Running the standard version first is the usual path: the exceptions it logs in the first month are the scope of the custom build, with your own numbers. How custom builds work.
Frequently asked questions.
Does Stripe not already do dunning?
Stripe's Smart Retries and default emails are a baseline. The workflow adds decline-code-specific timing, personalised multi-channel messages, cancellation handling with save offers, owner alerts and the reporting — the parts that move the recovery rate.
Can it apply discounts automatically?
Only from the finance-approved offer set, and only in the cancellation flow. Discount values and eligibility rules live in a sheet finance owns.
Is this compliant with consumer-protection rules?
The workflow cancels promptly on request, never hides the cancel option and never adds friction beyond one offer. Message content is yours to approve. Local rules on retries and notice periods are configured per region.
Does Stripe not already do dunning?
Stripe retries and sends a generic email; that recovers some. The workflow adds what the generic path lacks: retry timing chosen from the decline code, a message written for the specific failure in your voice, a save flow for plan changes and cancellations with one approved offer, an alert to the account owner for high-value accounts, and a weekly report of what was recovered and what was lost. Stripe stays the billing system; the workflow runs around it.
Can it apply discounts or offers automatically?
Within rules you set — one offer per segment, a maximum discount, an expiry — yes; the offer is a rule, not the model’s judgement. High-value accounts and anything outside the rules go to a person before an offer is made.
Is automated dunning compliant with consumer-protection rules?
The messages carry the facts a regulator expects — what failed, what happens next, how to update the card, how to cancel — with no pressure language, and every message and retry is logged per customer. Card data never touches the workflow; it links to the billing provider’s update page. Multi-currency tax logic and usage-based billing are custom builds.
What this blueprint is built on.
Vendor documentation the steps rely on, and the rules the guardrails are written against.
- Stripe — Smart Retries docs.stripe.com/billing/revenue-recovery/smart-retries
- Chargebee — Dunning www.chargebee.com/docs/2.0/dunning.html
- FTC — CAN-SPAM Act compliance guide www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business