Most subscription churn isn't customers leaving — it's cards expiring, banks declining renewals, and stored credentials drifting out of date. The technical name for this is involuntary churn, and on a typical Shopify subscription store it runs 8-12% of monthly billing volume. The good news: most of it is recoverable without a human ever touching it. This guide is the product-feature view of how that happens. It explains exactly what your subscription app does in the seconds after a card decline, the schedule it follows for retries, the emails it sends, the account-updater networks it queries behind the scenes, and the recovery-rate metric that tells you whether the system is working. For the strategy side — how to design retry schedules and dunning copy from scratch — see the companion guides on dunning management and dunning email design.
What payment recovery actually does, end to end
Payment recovery is a chain reaction. The renewal cron fires, your app calls Shopify's BillingAttempt API, Shopify forwards the charge to the payment gateway, the gateway either succeeds or returns a decline code. If it succeeds, an order is created and the next renewal is scheduled. If it fails, recovery starts — and that's where the work really begins.
The full chain has six stages, and a well-built subscription app runs all of them without merchant intervention: classify the decline, decide whether to retry now or later, schedule retries on optimal days, query account-updater networks for replacement card details, send recovery emails with a one-click update link if retries fail, and finally pause the contract rather than cancelling if everything is exhausted. Each stage exists because removing it materially drops the recovery rate.
- Decline classification — soft (try again later) vs hard (need new payment details)
- Retry scheduling — calendar-aware retry attempts spread over 7-14 days
- Account-updater query — Visa VAU, Mastercard ABU, Amex Cardrefresher push new card numbers automatically
- Customer recovery email — sent only when retries can't fix it without customer action
- Hosted update page — tokenised link, no login, mobile-first form
- Pause-not-cancel — contract enters a pause state with a deterministic resume path
The decline taxonomy: soft vs hard
Not every decline means the same thing, and treating them all identically is the single most common recovery configuration mistake. Card networks return a decline reason code with every failed charge, and those codes split cleanly into two operational categories: soft declines that will probably succeed on a later retry, and hard declines where retrying with the same card is wasted effort.
Soft declines are temporary states. The customer is fine, the card is fine, but something blocked the specific charge at this specific moment. The most common is insufficient funds — the card balance is below the charge amount today but will likely be above it after payday. Other soft declines include velocity limits (too many recent charges), bank-side fraud holds that auto-clear in 24-48 hours, and processor-side temporary issues. Soft declines have a meaningful chance of clearing on a well-timed retry.
Hard declines are state changes. The card is gone, the account is closed, the issuer has marked the merchant as not-allowed, or the credentials are wrong. The most common hard declines are expired-card, stolen-card, account-closed, and lost-card. Retrying with the same details will fail every time. The right move is to skip retry mode entirely and go straight to customer-facing recovery: tell the customer the card needs updating and give them a one-click way to do it.
Card issuers track repeated declines from the same merchant on the same card. Multiple consecutive declines within a short window can flag your merchant ID for elevated fraud screening — meaning future legitimate charges from new customers start getting declined too. Always check the decline code before retrying. If it's hard, do not retry; email the customer instead.
Smart-retry scheduling: the days that actually work
There's a substantial body of payment-processor data on which retry days have the highest success rate, and the pattern is consistent enough across processors to treat as canonical. The optimal retry schedule is three attempts spread over 7-10 days, with the first retry 2-3 days after the initial failure, the second around day 5, and the third around day 7-10.
The reasoning is straightforward. Day 2-3 catches insufficient-funds declines after most US biweekly paydays. Day 5 catches the customer's next bank-side reconciliation window when soft holds clear. Day 7-10 covers cases where the customer's monthly deposit cycle (mortgage payments, salary deposits, bill auto-debits) has caused short-term cashflow holes that have since resolved. Retrying every day burns issuer reputation. Retrying once a week is too slow — the customer forgets why they signed up.
- Attempt 1 + 2 days — first retry catches the largest single bucket (insufficient funds after payday)
- Attempt 1 + 5 days — second retry catches bank-side holds that auto-clear
- Attempt 1 + 7-10 days — third retry catches monthly cashflow recoveries
- Never more than 3 retries before sending a customer email — beyond 3, marginal recovery is near zero
- Never retry on the same day as the original failure — issuers treat back-to-back attempts as adversarial
A best-in-class app modifies the schedule based on what failed. Insufficient-funds declines: bias toward day 2-3 (post-payday). Card velocity limits: longer first gap (day 4+). Fraud-suspected holds: skip retry entirely and email the customer immediately, because the bank has already flagged the merchant and further attempts add risk without recovery upside.
Customer-facing recovery emails: what they say and what they link to
Once automated retries are exhausted (or skipped because the decline was hard from the start), the next stage is customer-facing email. This is where recovery rates split dramatically between mediocre and excellent apps. A poorly designed recovery email recovers only a small share of the cases it reaches. A well-designed one recovers several times more.
The structure of an effective recovery email is consistent across categories. Subject line: matter-of-fact, not alarming. Body: one sentence explaining what happened, one sentence on what the customer needs to do, one prominent button to do it. No marketing copy, no upsells, no "we miss you" tone. The customer hasn't churned — they just need to update a card. Treat it as a logistical message, not a retention message.
The most important element is the call-to-action button. It must go to a hosted update page, not the storefront login. The customer should be able to update their card in under 30 seconds without logging in. Every login wall between the customer and the card form costs you recovery rate. For copy patterns and full email design, see dunning emails.
The hosted update page: what makes it convert
The update page is the single highest-leverage surface in your entire recovery flow. Get it right and you'll recover a meaningfully higher percentage of failed charges. Get it wrong and the rest of the chain is wasted effort because customers reach the page and bounce.
The non-negotiables are: the link must be tokenised (no login, no password reset, no "please verify your email" wall), the form must be mobile-optimised (most customers open recovery emails on phones), and the existing customer data (name, billing address, email) must be pre-filled so the customer is only typing the new card number, expiry, and CVV. The fewer keystrokes between landing and submitting, the higher the conversion.
- Tokenised one-click link — no login required, link itself authenticates the session
- Token expires after 7 days for security — past that, sender re-authentication is required
- Mobile-first card form, large tap targets, OS-level card autofill enabled
- Pre-filled billing address — customer only enters new card details
- Confirmation email sent automatically on success — closes the loop visibly
- Apple Pay / Google Pay button shown above the card form when available — 2-tap recovery
The single biggest update-page anti-pattern is routing the recovery email link to the storefront customer-account login. Customers who haven't logged in for months have forgotten the password. The forgot-password flow takes multiple emails and several minutes. By the time they're back at the card form, many have bailed. Tokenised links bypass the login entirely and improve recovery rate substantially.
Account-updater networks: recovery without the customer knowing
The recovery your customer never sees is the recovery they're happiest about. Visa, Mastercard, and Amex all run network-level services that push updated card credentials to merchants of record when a customer's card is reissued, replaced, or has its expiry extended. If you're enrolled, expired-card declines fix themselves silently — Shopify charges the renewal, the network rewrites the card details before the request even hits the gateway, and the renewal succeeds.
The three services to know are: Visa Account Updater (VAU), Mastercard Automatic Billing Updater (ABU), and Amex Cardrefresher. Shopify Payments has all three enabled by default for eligible merchant categories. Other gateways vary — Stripe requires explicit dashboard enablement, Adyen requires merchant configuration, some legacy gateways don't support them at all.
- Visa Account Updater (VAU) — push notifications for new card numbers and updated expiries on reissued Visa cards
- Mastercard Automatic Billing Updater (ABU) — equivalent service for Mastercard, runs on a similar cadence
- Amex Cardrefresher — Amex's network-level credential refresh service
- Shopify Payments — all three enabled by default for eligible merchants in supported regions
- Stripe / Adyen — enrollment is opt-in via dashboard settings; check that it's enabled before assuming it's running
Account-updater hit rate (the percentage of expired-card declines that auto-resolve via network credential refresh) typically runs 30-50% for stores on Shopify Payments. That's recovery you don't have to email the customer for, don't lose to dunning fatigue, and don't take customer-service time on. Watch this metric in your recovery dashboard — if it's near zero, your gateway isn't enrolled and you're leaving money on the table.
Multi-attempt limits: when to stop and pause
Every recovery system needs a stopping rule. Past a certain attempt count, marginal recovery approaches zero and continuing to bill or email becomes counterproductive — fraud risk, customer annoyance, support volume. The right rule is built around two concepts: total attempts and elapsed time. Whichever limit hits first ends the recovery cycle.
A typical stop rule is: 3 charge attempts OR 21 days from initial failure, whichever comes first, then pause the contract. "Pause" is critical — not cancel. The customer hasn't asked to cancel. They've failed to update payment, which is functionally a different state. Paused contracts stay in the system, the customer can resume themselves from the portal when they're ready, and you keep the relationship alive instead of forcing them to re-sign-up.
A paused subscriber has a meaningfully higher reactivation rate than a cancelled-then-restarted subscriber over the following 90 days. The friction of fully re-subscribing (find the product, re-select cadence, re-enter card, re-disclose terms) is enough to lose most paused customers if you force them through it. Auto-pause is the kindest stop state for both sides.
Recovery analytics: the rate that tells you it's working
Recovery rate is the headline metric, and the definition matters more than the number. The correct formula is: (failed charges that eventually succeeded within 30 days) / (total failed charges in the period). Anything below 50% means your chain has a missing or broken link. 60-70% is healthy. 75%+ is excellent and usually requires the full stack — smart retries, all three account updaters, a clean hosted update page, and well-designed recovery emails.
The breakdown by stage is what makes the rate actionable. A dashboard that says "recovery rate is 52%" is less useful than one that says "retry stage recovers 28%, account updater adds 14%, customer email adds 10%, total 52% — your customer email conversion is the weak link". Each stage has different levers, and the diagnostic value of the breakdown is what guides where to invest.
- Retry success rate — percentage of soft declines resolved by retries alone
- Account-updater hit rate — percentage of expired-card declines resolved silently by VAU/ABU
- Email-to-update conversion — percentage of recovery emails that result in a successful card update
- Overall recovery rate — combined; the headline number
- Time-to-recovery — median days from initial failure to successful charge
- Dollars recovered — the only metric your finance team will care about
Tracking recovered revenue in dollars
Percentages don't pay bills. Dollars do. Every recovery dashboard should answer the question "how much money did this system make me this month" in a single number that you'd be comfortable showing your CFO. The number is straightforward: sum of the order totals from charges that succeeded only after recovery effort, minus the cost of running the system itself.
A useful frame: take your monthly subscription billing volume and multiply by your involuntary churn rate (8-12% is typical). That's the dollar amount at risk every month. Multiply by your recovery rate. That's the dollar amount your recovery stack saves per month. For a store doing $50k MRR with 10% involuntary churn and a 60% recovery rate, that's $3,000/month recovered, $36k/year. Most subscription apps cost less than one month of that recovered amount.
- Overall recovery rate above 55%?
- Account-updater hit rate above 25% (proves networks are enrolled)?
- Email-to-update conversion above 20% (proves email + update page work together)?
- Median time-to-recovery under 10 days?
- Paused contracts trending flat or down (not accumulating)?
- Dollar amount recovered visible to finance / leadership?
Common payment-recovery pitfalls
Most stores running below a 50% recovery rate have one of the same set of misconfigurations. They aren't subtle, and they all have known fixes. Walking through this list usually surfaces at least one quick win.
- Retrying hard declines — wastes attempts and triggers fraud blocks. Check decline codes before retrying.
- Routing recovery emails to the storefront login — costs a large share of recovery rate vs a tokenised hosted page.
- Account updaters not enrolled — the most common silent failure on Stripe and Adyen merchants who assumed enrollment was automatic.
- Recovery emails styled as marketing — "we miss you!" tone underperforms matter-of-fact "your card needs updating" by a wide margin.
- Retrying within 24 hours of decline — issuers treat this as adversarial and elevated fraud screening kicks in.
- Auto-cancelling instead of pausing — destroys win-back potential and forces a full re-signup if the customer returns.
- No mobile optimisation on update page — most recovery emails open on phones; desktop-only forms cost a large share of the conversion.
- No dollar tracking — without it you have no way to justify the system to finance or to see when it stops working.
When you need to go beyond the defaults
The defaults described in this guide are what your subscription app should run out of the box. They recover the majority of recoverable revenue for the majority of stores. If you're running at a higher MRR scale, in a high-decline-rate category (international, sub-prime credit segments, high-ticket recurring), or with unusual customer demographics, you'll eventually need to customise.
That's where the companion guides come in. Dunning management covers the strategy layer: designing custom retry schedules per customer segment, building escalation paths beyond the standard 3-email sequence, integrating SMS, and the operational decisions about when to involve human customer service. Dunning emails covers the copy and design layer: subject-line patterns, body structure, CTA placement, A/B testing recovery email variants, and the visual design rules that distinguish a recovery email from a marketing email.
If you're a typical Shopify subscription store under $100k MRR, you almost certainly don't need to customise — the defaults will get you to a 55-65% recovery rate, which is most of the available recovery. Customisation is what gets you from 65% to 75%, and the lift requires substantial effort. Make sure the defaults are running correctly first.
Payment recovery questions
What percentage of failed payments can actually be recovered?
A well-configured recovery stack typically recovers 55-70% of failed charges within 30 days. The breakdown is roughly: a third to half via smart retries on soft declines, a third to half of expired-card declines via network account updaters (silent), and a fifth to a third of remaining failures via customer-facing recovery emails. Stores recovering below 50% usually have a fixable misconfiguration.
How many times does the app retry a failed charge?
The standard schedule is three retries spread over 7-10 days — first retry 2-3 days after the initial failure, second around day 5, third around day 7-10. More than three retries adds negligible recovery and risks triggering issuer-side fraud blocks against your merchant ID. The app should classify the decline code first and skip retries entirely for hard declines (expired-card, account-closed).
Can I disable retries entirely?
Yes, but it's almost never the right choice. Smart retries recover a substantial share of soft declines with zero customer touch and zero email volume. Disabling them means every soft decline goes straight to a customer email, which costs you both recovery rate and customer goodwill (people don't want "your card failed" emails when the card actually works and was just blocked for a minute). The right adjustment is usually to tune the schedule, not turn it off.
Do customers know there was a payment problem?
Only if the retries fail and customer action is required. Soft-decline retries that succeed on day 2-3 happen silently — no email, no notification, the customer never knows. Account-updater resolutions are also silent. Customers only receive a recovery email when the system has exhausted automated attempts and genuinely needs them to update payment details. This is by design — the goal is to fix the problem without bothering them when we can.
How do account updaters work and what's my hit rate?
Visa Account Updater, Mastercard Automatic Billing Updater, and Amex Cardrefresher are network-level services that push new card numbers and updated expiries to enrolled merchants when a customer's card is reissued. Shopify Payments has all three enabled by default. Hit rate (percentage of expired-card declines auto-resolved) typically runs 30-50%. Check your recovery dashboard — if it's near zero, your gateway isn't enrolled or you're on a region/merchant category that doesn't qualify.
What happens if all retries and recovery emails fail?
The contract should be paused, not cancelled. The customer stays in the system, can resume themselves from the customer portal when they're ready, and you keep the relationship alive. Auto-cancelling forces a full re-signup if they ever come back, which most won't bother with. Paused subscribers reactivate at a meaningfully higher rate than cancelled-then-restarted ones over the following 90 days.
Should retries happen at the same time each day?
No. Network-level data shows that retries spread across different times of day perform better than retries at the same hour. The reason is that issuer-side velocity rules and customer-side cashflow events both vary by time of day. Most subscription apps pick a randomised hour within a window for each retry attempt rather than firing them all at midnight.
What's the difference between this and dunning?
Payment recovery is the umbrella; dunning is one stage of it. Specifically, dunning refers to the customer-facing communications (emails, SMS) that ask the customer to update payment. Payment recovery also includes the automated retries before customer contact and the network account-updater integrations that resolve failures silently. A complete payment-recovery system includes dunning but isn't limited to it.
Will retries hurt my standing with payment processors?
Properly configured retries (max 3 attempts, never within 24 hours, decline-code-aware) are accepted industry practice and won't hurt your standing. Aggressive retries (daily attempts, retrying hard declines, no decline-code logic) will trigger elevated fraud screening and eventually a merchant-level decline-rate review. The standard 3-over-7-10-days schedule is well within accepted norms.
How long does it take for a recovery to complete?
Median time-to-recovery for the wins is 5-10 days from initial failure. Soft declines that retry-recover tend to close within 2-5 days. Account-updater resolutions are typically same-day or next-day once the network has propagated. Customer-action recoveries (email click then card update) average 3-7 days from first email. After 21 days from initial failure, marginal recovery is essentially zero — that's the right place to draw the pause line.
Do recovered renewals create the order on the recovery date or the original date?
The order is created on the recovery date — i.e. the day the charge actually succeeds — and the order date in Shopify reflects when the customer was successfully billed. The next renewal is calculated forward from this recovery date, not the originally-scheduled date. This keeps the billing cycle consistent and avoids stacking renewals if the next cycle would otherwise fall within days of the recovered one.
How do I see what my recovery rate actually is?
Your subscription app should expose a recovery dashboard with at minimum: overall recovery rate, breakdown by stage (retry success, account-updater hit, email-to-update conversion), dollar amount recovered per month, and time-to-recovery distribution. If your app doesn't show these, you can't manage what you can't measure — it's a strong signal to evaluate alternatives or pressure the vendor for transparency.