Dunning is the unglamorous half of subscription billing — the workflow that fires when Shopify's renewal charge fails and your subscriber's card declines. Almost nobody plans for it at launch, and almost everybody discovers in month two that 5-10% of renewals fail every single cycle. That's not a fraud problem; it's a math problem. Cards expire, banks reissue them, balances dip below a threshold, an issuer flags a recurring merchant by mistake. Without an active dunning strategy you're simply absorbing that 5-10% as silent churn. With one, you'll typically recover 60-75% of those failed renewals — meaningful money on a base of any size. This guide is the operational manual: when to retry, on what schedule, through which channels, when to stop, and what to track. The copy itself — what your emails should actually say — lives in the sister guide on dunning email playbooks.
What dunning is and why involuntary churn is your biggest hidden leak
Dunning is the polite industry term for the workflow that runs after a recurring charge fails: retries, customer notifications, payment-method updates, and the eventual decision to suspend or cancel. The word comes from "to dun" — to repeatedly demand payment — and it carries baggage. Most merchants react to dunning the way they react to debt collection: as an adversarial process. That framing is wrong and it's why most stores leak so much revenue here.
Across consumer subscription categories, a steady 5-10% of recurring charges fail on any given renewal day. That number is remarkably stable across product types, basket sizes, and customer demographics — it's driven by card-network mechanics, not by customer intent. Roughly two-thirds of those failures are recoverable with a polite nudge: the card was simply replaced, the balance was momentarily low, the issuer's fraud system saw a recurring merchant and over-corrected. Without dunning you cancel all of these. With smart dunning you keep most of them.
The numbers compound fast. If you're at $20k MRR with a 7% renewal failure rate, that's roughly $1,400 of revenue at risk every billing cycle. Recovering 65% of it puts $910/month back on the books — call it $11k/year on a single mid-sized store. The same workflow on a $100k MRR store recovers $55k/year. Dunning isn't a growth lever; it's a leak-plug, and the math holds at every scale.
Voluntary churn (customer actively cancels) needs a retention strategy — pause offers, discount saves, win-back. Involuntary churn (card just failed) needs an operational system — retries and reminders. The two cause similar revenue loss but require completely different interventions. Stores that conflate them end up with elaborate cancel-flow logic and no dunning, which is the worst possible allocation of engineering time.
The two failure modes: hard fails vs soft fails
Card networks classify declines as either hard or soft, and your dunning strategy should treat them very differently. A hard fail means the card is structurally unusable for this charge — expired, closed account, account holder reported it stolen, do-not-honor with a permanent code. A soft fail means the card is fine, but this specific attempt didn't go through — insufficient funds, temporary issuer-side decline, transient network error, fraud-system false positive.
Soft fails are recoverable by simply waiting and trying again. The customer's balance refills on payday; the issuer's fraud system clears the flag; the network error doesn't repeat. About 70% of failures across consumer subscription portfolios are soft, and most of these recover on a single retry within 72 hours. This is why even a primitive retry layer outperforms no retry layer by a wide margin.
Hard fails are different. Retrying the same expired card 48 hours later won't help — it's still expired. The only recovery path is a new payment method. Your dunning workflow needs to detect the decline reason from the payment processor's response and branch: soft fail goes into the retry queue, hard fail goes straight to a card-update notification with a deep link to the customer portal. Treating hard fails as if they were soft fails wastes retry attempts and risks triggering chargeback fraud signals from the issuer.
- Hard decline codes: expired card, closed account, stolen/lost card, do-not-honor (permanent), card not supported — skip retries, go straight to card-update flow
- Soft decline codes: insufficient funds, generic decline, temporary issuer decline, processor timeout, fraud-suspected (transient) — retry on schedule
- Ambiguous codes: "call issuer," pickup card, restricted card — treat as hard fail; one retry max before requesting card update
Smart retry schedules vs naive immediate retries
The single biggest improvement most subscription stores can make to dunning is changing when retries fire. Naive systems retry immediately on failure, then again an hour later, then again the next day — burning through three attempts before the customer's balance has any realistic chance of refilling. Smart-retry schedules spread attempts across days, aligned with how real people use their accounts.
The schedule that consistently performs well across consumer subscription categories is approximately 24 hours, 72 hours, then 7 days — three attempts spread over 10 days. The 24-hour delay covers transient issuer or network issues. The 72-hour delay catches the most common pattern: customer got paid Friday and the balance recovers by Monday. The 7-day delay catches monthly pay cycles. Smart-retry schedules with this kind of spacing typically reduce involuntary churn by 30-50% versus immediate-retry systems.
Time of day matters too. Retrying at 03:00 UTC against a US customer's card is worse than retrying at 10:00 local time — the customer is more likely to see the issuer's SMS alert, recognise the charge, and clear the fraud flag. Better dunning systems retry on the customer's local business day, not your server's wall clock. If your subscription app exposes a retry-timezone setting, use it.
Card networks penalise merchants who retry an expired or closed card more than a handful of times. Visa, Mastercard, and Amex all monitor the ratio of authorisation attempts to successful charges; cross their threshold and your merchant account gets flagged. The safe cap is 4 retries total per failed renewal — and you should stop before that for hard fails. Treat "more retries = more recovery" as false past attempt 3 or 4.
Channel mix: email, SMS, and in-portal banners
A retry that fires silently in the background recovers fewer renewals than a retry the customer expects. The other half of dunning is communication: telling the subscriber the charge failed, why, and exactly how to fix it. The channel mix matters because different subscribers respond on different channels, and stacking channels recovers materially more than any single channel.
Email is the workhorse — high inbox-time on mobile, easy to make actionable with a single button. SMS is the urgency channel — much higher open rate (often 90%+ within minutes), but more expensive and more easily perceived as spam. In-portal banners are the safety net — when the subscriber logs in to do anything else, they see the problem and the fix. Most stores running modern dunning use all three, in sequence, escalating as attempts fail.
- Attempt 1 fails — immediate email ("we couldn't charge your card; we'll try again in a day")
- Attempt 2 fails — email + persistent in-portal banner with one-click card update
- Attempt 3 fails — email + SMS (if opted in), tone shifts from informational to actionable
- Attempt 4 (final) fails — final email + SMS, framed around what happens next (pause vs cancel), with the card-update link as the easy resolution
SMS deserves a specific note. In the US and most EU markets, transactional SMS to existing customers about an active subscription is generally permitted under the underlying consent the customer gave at signup. But your sign-up flow should explicitly mention SMS for billing notifications, and you must honour STOP responses. Sending dunning SMS to subscribers who didn't opt into SMS at all is both legally risky and a brand-reputation hit. If you didn't capture phone numbers at signup, retro-fitting them into the dunning flow is a separate project.
The involuntary-cancel question — how many retries before you stop
Every dunning workflow eventually faces the same decision: this subscription has failed 3 or 4 charges, the customer hasn't responded to email or SMS, what now? There are two valid answers and one wrong one. The wrong one is "keep retrying forever" — that gets your merchant account flagged and harms your brand. The two valid answers are suspend and cancel, and the trade-off between them is worth thinking through.
Suspend means the subscription stays alive in your system but no further charges are attempted. The customer keeps access to the portal, the subscription history, and the ability to reactivate by adding a working card. This is the right default for most consumer subscriptions where the customer might just have forgotten — they update the card three weeks later, click "reactivate," and you keep the lifetime value. Suspend-state is recoverable; cancel-state usually isn't.
Cancel means the subscription is terminated and the customer has to re-subscribe from scratch. Use this when retention math says the recovered customer isn't worth the operational cost of keeping a stale contract alive — or when you've contacted the customer multiple times across multiple channels with no response. A reasonable threshold for most stores: suspend after the 4th failed attempt, then auto-cancel after 30 days of suspension if the customer hasn't updated the card.
Across consumer subscription categories, roughly 15-25% of suspended subscriptions reactivate within 60 days of suspension. That's free LTV — no acquisition cost, no win-back campaign, just a card update. If your billing system jumps from "failed" straight to "cancelled," you're throwing all of this away. Always have an intermediate suspended state.
Updating the payment method without a support ticket
The single highest-leverage piece of dunning infrastructure is a frictionless card-update flow. The customer's intent is already there — they saw the email, they want to fix the problem — and your job is to remove every barrier between that intent and a successful card on file. Stores with great card-update flows recover 70-85% of soft fails; stores that require an email to support recover under 30%.
The minimum viable flow looks like this: every dunning email contains a magic-link button that goes directly to a card-update page, logged in, no password required. The page shows the current (failed) card, the amount that failed, and a single Stripe or Shopify-hosted payment form. On successful update, the failed renewal is automatically retried immediately, the customer sees a confirmation, and the subscription is back to active. The whole flow should take under 60 seconds. Anything longer leaks customers.
A subscription-friendly customer portal handles this without a separate page, but the magic-link entry point is still essential — customers don't remember portal URLs and don't want to dig through their email for a login link. Embed the update link in every dunning email, with the failed amount and the date of next attempt visible above the fold.
- Magic-link card update — no password, no portal navigation, single page
- Visible failure context — amount, date, last 4 of failed card, next retry date
- Immediate auto-retry on successful update (don't wait for the next scheduled retry)
- Confirmation email on successful update ("You're all set. Next delivery: 2026-06-12.")
- Mobile-first design — 70%+ of subscribers will tap the link on a phone
Network-level account updater — what it fixes and what it doesn't
Visa and Mastercard both run "account updater" services that quietly refresh expired or reissued cards on file. When a customer's card is replaced (expiry update, lost/stolen reissue, brand-network reissue), the network can push the new credentials to merchants on a periodic basis. Your subscription app or payment processor may or may not be enrolled in this; if it is, a meaningful chunk of would-be hard fails simply never become failures. The card on file just gets quietly updated.
Shopify Payments is enrolled in the Visa Account Updater and Mastercard Automatic Billing Updater by default. If you're billing through Shopify's native subscription contracts, you get this for free — and it's responsible for materially fewer hard fails than the raw card-expiration rate would suggest. Stripe Billing also includes network updater coverage. Older or third-party gateways often don't, and you'll see hard-fail rates 1.5-2x higher as a result.
Account updater isn't a substitute for dunning, though. It doesn't fix soft fails (insufficient funds, fraud false positives), it doesn't help with closed accounts, and it has a lag — typically days to a couple of weeks between the customer's card being reissued and the new credentials landing on your system. A subscription whose renewal date hits during that lag still needs the retry-and-notify workflow. Account updater reduces the population of failures dunning has to handle; it doesn't replace dunning itself.
If you're seeing hard-fail rates above 4-5% of renewals, your processor probably isn't enrolled in Visa/Mastercard account updater. Switching to a processor that is — even at marginally higher per-transaction fees — usually pays back many times over in recovered subscriptions. Shopify Payments and Stripe Billing both include this; many smaller gateways don't.
Communicating with the customer — tone, frequency, framing
The strategy decisions in this guide — when to retry, how many times, which channels — only deliver their full recovery rate if the messages themselves land well. A customer who reads the first email, feels accused or threatened, and tunes out the rest of the cadence is operationally a churn even if your retry schedule was perfect.
Three principles drive everything else. First, blame the bank, not the customer — "your bank declined the charge" is true and removes the implicit accusation that the customer is broke. Second, escalate tone slowly — the first email should sound like a routine notification, not a warning. Third, focus every message on the action, not the problem — the single button to update the card is the email's job, everything else is context.
The full copywriting playbook — exact subject lines, the four-email cadence, real template skeletons, mobile design, and from-name/reply-to choices — lives in the dunning email guide. The strategic guide here covers the operational layer; the copy guide covers the words. Treat them as a pair: smart retries with bad copy still under-perform, and good copy can't compensate for a broken retry schedule.
Tracking recovery rate as a KPI
Recovery rate is the single number that tells you whether your dunning workflow is working. It's defined as recovered renewals divided by total failed renewals, measured over a 30-day window. A renewal counts as recovered if any retry within the dunning cadence ultimately succeeds; it counts as failed if the subscription ends up suspended or cancelled.
Typical recovery rates on consumer subscriptions land in the 60-75% range with a well-designed dunning workflow — smart retries, multi-channel notifications, frictionless card update, account-updater coverage. Below 50% suggests a broken link somewhere: either retries are too aggressive (chargebacks accumulating), notifications aren't being delivered (deliverability problem, check SPF/DKIM/DMARC), or the card-update flow has friction (test it on mobile). Above 80% is plausible only with deep account-updater coverage and a high-engagement subscriber base.
- Recovery rate — recovered renewals / total failed renewals (target 60-75%)
- Failure rate — failed renewals / total renewal attempts (typically 5-10%)
- Net involuntary churn — failure rate × (1 − recovery rate); this is the actual MRR you lose to dunning failure
- Time-to-recovery — median hours from first failure to successful retry; tells you whether smart retries are working
- Card-update conversion — clicks on dunning email / successful card updates; tells you whether the email and update flow are working
Track these in your subscription analytics dashboard alongside your voluntary-churn metrics, not separately. Many stores discover that their dunning failure is significantly worse than their voluntary-churn — and dunning is far cheaper to fix than voluntary-churn drivers like price sensitivity or product-market fit.
When to write off and cancel vs keep retrying
Past attempt 4, the marginal recovery rate falls below the marginal cost of another attempt — additional retries risk merchant-account flags, additional emails risk unsubscribes, additional SMS risk spam complaints. There's a point where the right move is to stop, suspend, and accept that the customer didn't want to renew.
Two signals tell you it's time. First, the customer hasn't opened any of the dunning emails — your email service can tell you this, and a customer who hasn't engaged with three messages probably won't engage with a fourth. Second, the failure pattern looks like deliberate cancellation — the customer cancelled their card around the time of failure, or the issuer is returning "customer-requested" decline codes. In both cases, additional retries just create friction and risk chargebacks.
When you do cancel, the cancellation email is your last chance to recover lifetime value indirectly. A win-back campaign 30/60/90 days later — offering a re-subscription discount, a one-time order, or a different product entirely — typically recovers 3-5% of cancelled customers over 6 months. That's small but free; the alternative is treating the cancelled customer as gone forever.
A surprisingly common dunning configuration: failures generate a ticket in your support system, a human reads it, and emails the customer manually. This is slow (often days), inconsistent (different agents send different tone), and doesn't scale. Dunning belongs in the automated billing pipeline, not the support inbox. Reserve human support for the edge cases (chargebacks, billing disputes), not the volume cases.
Common dunning pitfalls that quietly burn revenue
Stores that get dunning wrong tend to make the same small set of mistakes. Here are the ones worth specifically guarding against, ranked by frequency.
- Retries fire too fast — same-day or hourly retries waste attempts and trigger issuer-side fraud flags. Spread them: 24h, 72h, 7d.
- One channel only — email-only dunning hits inbox deliverability and 20-30% of subscribers never see the message. Add in-portal banner and SMS for late-cycle attempts.
- No card-update magic link — every extra click between "I want to fix this" and "my card is updated" loses customers. Magic-link directly to the update page.
- Same cadence for hard and soft fails — retrying an expired card four times is wasted work. Branch on decline code.
- No suspended state — jumping from failed to cancelled throws away the 15-25% of customers who would have reactivated.
- Not testing in dev — most subscription apps let you trigger a failed renewal in test mode. If you've never seen your dunning emails arrive, they probably look wrong.
- Notifying your team instead of the customer — dunning is automated revenue rescue, not a support workflow.
- Ignoring deliverability — dunning emails sent from misconfigured domains (no SPF/DKIM/DMARC) land in spam at much higher rates than transactional confirmations.
- No recovery-rate tracking — without the KPI, you can't tell whether changes are working. Add it to your dashboard from day one.
Dunning management questions
How many times should I retry a failed subscription charge?
Three to four attempts maximum, spaced over roughly 10 days — typically at 24 hours, 72 hours, and 7 days after the initial failure. More than four attempts puts you at risk of merchant-account flags from Visa/Mastercard, and the marginal recovery rate falls sharply past attempt 4 anyway. Stop earlier for hard fails (expired cards, closed accounts) since retrying won't change the outcome.
What's a typical subscription recovery rate?
A well-designed dunning workflow recovers 60-75% of failed renewals across most consumer subscription categories. Below 50% suggests a fixable problem — usually deliverability (emails in spam), card-update friction (broken on mobile), or too-aggressive retry timing. Above 80% is plausible only with deep network-account-updater coverage and a highly engaged subscriber base.
Should dunning be on by default in subscription apps?
Yes. Any subscription app worth using has dunning enabled out of the box with a sensible default schedule. If you have to configure dunning manually before launch, you'll almost certainly forget — and you'll discover the gap when 5-10% of your month-2 MRR quietly disappears. Confirm dunning is active and that test emails actually arrive before going live.
What's the difference between a hard decline and a soft decline?
Hard declines mean the card is structurally unusable (expired, closed account, lost/stolen, do-not-honor permanent) — retrying won't help, only a card update will. Soft declines mean the card is fine but this specific attempt failed (insufficient funds, fraud false positive, temporary issuer decline) — most of these recover within 72 hours if you simply retry. Read the decline code from your processor's response and branch your dunning flow accordingly.
Does Shopify automatically retry failed subscription charges?
Shopify's native Subscription Contracts API does not retry failed charges itself — that's the subscription app's responsibility. Your app reads the failed payment status from Shopify and decides whether and when to retry. The good news is that Shopify Payments is enrolled in Visa Account Updater and Mastercard Automatic Billing Updater, so many would-be expired-card failures are silently prevented before they happen.
What happens to a subscriber's account during dunning?
The standard pattern: the subscription stays in an "active" state during the retry window (typically 10 days), then moves to "suspended" if all retries fail. While suspended, no charges are attempted, the customer can still log into the portal and update their card, and reactivation is one click. After 30 days of suspension with no card update, most stores auto-cancel — though the exact threshold is configurable.
Should I cancel after N failed attempts?
Suspend rather than cancel. Suspended subscriptions retain about 15-25% reactivation within 60 days — customers update the card, click reactivate, and you keep the lifetime value with zero acquisition cost. Cancelling immediately throws that away. The standard cadence is suspend after 4 failed attempts, auto-cancel after 30 days of suspension.
What about chargebacks during dunning?
Aggressive dunning increases chargeback risk in two ways: too many retry attempts against the same failing card trigger network-level fraud flags, and overly-urgent emails can prompt customers to call their bank instead of updating the card. Cap retries at 4, keep the email tone calm, and make sure every email has a one-click card-update path. Stores that follow these patterns see dunning-related chargebacks below 0.1% of attempts.
How do I track whether my dunning is working?
The core KPI is recovery rate: recovered renewals divided by total failed renewals over a 30-day window. Target 60-75%. Track it alongside failure rate (failed / total attempts), net involuntary churn (failure rate × (1 − recovery rate)), and card-update conversion (dunning email clicks → successful updates). If recovery rate drops below 50%, audit deliverability, retry timing, and the card-update flow on mobile.
Can I run dunning manually instead of automated?
Technically yes; operationally no. Manual dunning means a human reads each failure, emails the customer, and retries the charge — which works for a handful of failures per month and falls apart at any scale. Above 50 active subscriptions you need automated dunning; above 500 it's the difference between a working business and a part-time customer-service job. Use the subscription app's built-in workflow.
Does dunning apply to one-time orders too?
No. Dunning is specifically the workflow for retrying failed recurring charges where the customer already authorised future billing. One-time orders that fail at checkout are abandoned-cart territory and need a different workflow — usually an email reminder with a checkout link, not retry attempts against the same card.
Should I offer a discount in a dunning email?
Generally no. A discount in a dunning email reframes the conversation from "your card failed, please update it" to "you have leverage to renegotiate." That's the wrong message for an involuntary churn workflow. Reserve discounts for voluntary cancellations where the customer is actively choosing to leave. The exception is the final dunning email before suspension — a small "come back" offer there is closer to a win-back than a save.