Resources

Reduce Failed Payments: 9 Proven Tactics

Failed payments feel inevitable — cards expire, banks glitch, customers get new cards. But "inevitable" and "unfixable" aren't the same thing. Roughly half of failed subscription payments are recoverable with the right tactics. Here are nine, ordered roughly by ROI.

1. Turn on card account updater

The single highest-ROI move. Card updater services (available through Stripe and most processors) automatically refresh expired, lost, or replaced card details. The charge succeeds and the customer never knows there was a problem. If you do nothing else on this list, do this — it silently resolves the largest single failure category.

2. Retry by decline code, not by calendar

Dumb retries — same card, fixed schedule — recover a fraction of what's possible. Route each failure by its decline code: never retry expired cards, time insufficient-funds retries to paydays, cool off bank declines 24–72 hours. Our decline code guide has the full routing table.

3. Send dunning emails that sound human

When retries can't finish the job, the customer needs to act — and the email that gets them to act is short, specific, and human. "Your April box ($49) is on hold — update your card here" beats "PAYMENT FAILURE NOTICE" every time. Frameworks with examples: dunning emails that actually get paid.

4. Alert customers before cards expire

Pre-dunning beats post-dunning. A simple "your card expires next month — update it here" email before the renewal charge converts a would-be failure into a routine update. This is nearly free to implement and catches failures retries never see.

5. Collect backup payment methods

Let customers keep a second card on file and cascade to it when the primary fails. It's a checkout/UX project, not a billing project — add it to your account page and mention it in onboarding. Backup methods silently resolve a meaningful share of failures.

6. Handle 3D Secure properly

For EU/UK customers, Strong Customer Authentication means some charges require the customer to authenticate. Build the flow that routes authentication_required declines straight to a payment link — no retry schedule will ever clear this code, and every day of delay risks the subscription.

7. Give failed payments a real grace period

Don't cancel on the first failure. A 7–14 day grace period with active recovery (retries + emails) recovers dramatically more than a 48-hour one. Match the grace period to your billing cycle — annual plans deserve more runway than weekly ones. And keep the service running during grace: nothing kills a recovery like the customer discovering they're already locked out.

8. Watch your retry velocity

Too many rapid retries trigger fraud filters and rack up authorization costs. Space attempts, cap them per card (3–5 across the grace period is plenty), and never retry hard-decline codes. More attempts isn't more recovery — smarter attempts are.

9. Measure recovery, not just churn

Add these to your dashboard: failed payment rate, recovery rate, involuntary churn rate, and recovered revenue by lever (retries vs. card updates vs. emails). Teams that measure recovery improve it; teams that only measure churn argue about whose fault it is.

The decline-code routing table, in full

Tactic 2 above does the heavy lifting, so here it is expanded into the routing most recovery systems actually run. The decline code on the failure is the instruction — read it before scheduling anything.

Decline code / cause	Retry behaviour	Customer contact
Insufficient funds	Wait, then time attempts around likely paydays — up to six attempts across roughly sixteen days	Light-touch email and SMS on day 1 and day 7; patience outperforms pressure here
Expired card	Never blind-retry — the card cannot succeed	Ask for a new card first, on a dedicated day 1 / 3 / 7 cadence across email and SMS
Lost or stolen card	Never retry, under any schedule	One clear request for a new card via the secure hosted link
Bank block / do-not-honor	Cool off before the next attempt	Tell the customer a quick call to their bank usually clears the block
Authentication required (3D Secure)	No retry schedule clears this code	Route straight to the payment-update / authentication link
Transient processing error	A short-delay retry is reasonable	Usually none — most resolve silently before the customer needs to hear anything

A worked example: applying the nine tactics to one store

Take a subscription box business billing monthly through Recharge on Shopify. A customer's renewal fails on the 1st. Here is the same failure with and without the system above.

Without it: the platform retries on its default fixed schedule — same card, same timing, no reference to why it failed. The card had been replaced by the customer's bank, so every attempt declines identically. No email goes out, or one generic "payment failed" notice does. On day 10 the subscription cancels automatically. The customer, who liked the product, finds out when the box does not arrive, and re-subscribing means starting over at today's prices. The store records it as churn and never learns it was a billing event.

With it: the failure arrives with its decline code attached. Because the card was replaced, the routing is "ask for a new card" — a day 1 SMS and email in the store's branding, naming the box and the amount, with one secure hosted update link. Card account updater may resolve it silently before the customer even acts; if not, the customer taps the link on day 2, enters the new card on the hosted page — raw card numbers never handled by the store — and the next attempt succeeds. The store's dashboard attributes the recovered subscription to the card update, not to a retry, which tells the owner exactly which tactic earned that revenue. If the customer had instead clicked "cancel" at any point in frustration, one more layer matters, covered next.

10. Deflect the cancellations that failed payments cause

A share of "voluntary" cancellations are really failed payments in disguise: the customer hits a billing problem, gets frustrated, and cancels instead of fixing it. Cancel deflection catches that moment. The merchant pastes one finished URL where their cancel button points. The page asks the subscriber for the email on their subscription, matches it automatically, and presents offers — Discount, Pause, or Service ("not happy? let us make it right") — before the cancellation completes.

Execution differs by platform, and it is worth knowing before you promise a customer anything: offers execute automatically on Stripe, Recharge, Chargebee, Recurly, and Paddle; Seal and Skio execute pause and cancel; Braintree executes cancel only; and on Loop the request is recorded for the merchant to action. Either way the subscriber gets a real alternative at the exact moment they were about to leave, and a pause today is worth more than a win-back campaign next quarter.

Running the audit: a one-week procedure

1. Day 1 — Count the leak. Pull the last 90 days of failed payments from your platform. Group them by decline code. This grouping is your worklist: each group gets the routing from the table above, not a generic sequence.
2. Day 2 — Check prevention. Is card account updater on? Are expiring-card alerts sent before the renewal, not after the failure? Are backup payment methods offered on the account page?
3. Day 3 — Check the retry schedule. Whose schedule is running — yours, your processor's, or both? Built-in retries are layer one: automatic, but uncoordinated and invisible. If two systems can retry the same card, we recommend turning the built-in one off so one system runs the only schedule — recommended, never required, but two uncoordinated schedules are how double charges happen.
4. Day 4 — Read your own dunning emails as a customer. Trigger a test failure. Read every message in order, on your phone. If any message could be mistaken for a collections notice or a phishing attempt, rewrite it before it sends again.
5. Day 5 — Check the endgame. What happens at lapse — pause or cancel, what the customer keeps, and whether a win-back path exists. Then check the cancel flow itself: if a frustrated customer cancels, do they see a pause or discount offer first?

If that audit sounds like a lot of moving parts to assemble across Stripe, Recharge, Seal, Skio, Loop, Chargebee, Recurly, Paddle, or Braintree, that is because it is — it is one system with nine platform-specific wirings. The integrations page lists how Swipe Again connects to each, and setup includes the step most people skip: we recommend turning the processor's own built-in retries off so Swipe Again runs the only schedule — recommended, never required; recovery runs and counts either way.

The four numbers, defined — and how to calculate each one

Tactic 9 says to measure recovery. This is the arithmetic behind it — four numbers, each computable from a billing export, no tooling required.

Failed payment rate = failed charges ÷ total charges attempted in the period. Count charges, not subscribers — one subscriber can fail three times. This is the size of the leak before anyone works on it.

Recovery rate = failed payments eventually collected ÷ failed payments that occurred. Judge it at a fixed horizon — 30 days after the failure month closes is a fair one — or the number keeps moving and month-to-month comparisons mean nothing.

Involuntary churn rate = subscriptions cancelled for non-payment ÷ subscriptions active at the start of the period. Keep it separate from voluntary churn in every report; the fixes, the owners, and the timelines are entirely different. The full measurement method is in our involuntary churn guide.

Recovered revenue by lever = for each collected failure, the dollar amount, credited to whichever lever landed it — a retry, a card update, or a customer acting on a dunning message. This is the number that tells you which tactic on this page is paying for itself, and it is the one most dashboards get wrong by crediting everything to retries.

A quick example with round numbers: 2,000 renewal charges in a month, 160 fail — an 8% failed payment rate. If 70 of the 160 are collected within the horizon, the recovery rate is about 44%. The other 90 are the month's involuntary churn (before win-backs). Multiply 90 by whatever your average subscription is worth and you have the monthly cost of the leak — and the ceiling on what any recovery system, built or bought, can earn back.

Frequently asked questions

Which single tactic should I start with? Card account updater, if your processor offers it — it resolves failures silently, before retries or emails are needed. Then fix the retry schedule, because every later tactic assumes retries are decline-code-aware rather than fixed-calendar.

How many retries is too many? A working ceiling is up to six attempts over roughly sixteen days, scheduled by decline code — and zero attempts for codes that can never succeed, like lost or stolen cards. Attempts past the point of possible success only cost authorization fees and bank goodwill.

Does this work on my platform? Swipe Again covers nine platforms — Stripe, Recharge, Seal, Skio, Loop, Chargebee, Recurly, Paddle, and Braintree — with the last 90 days of failed payments pulled in automatically on connect, so the backlog gets worked, not just new failures. It is $179/mo flat or $1,799/yr with a 14-day free trial, and a guarantee: Recover $179 in 30 days, guaranteed — or Swipe Again is free the next 30 days. Recovered revenue means every failed payment collected while Swipe Again is active, from any recovery source, as defined in Section 3 of our Terms. How we count: how Swipe Again counts recovered revenue Details on the pricing page. Recharge merchants get the full walkthrough in Recharge dunning.

Should I keep service running during the grace period? Yes. Locking a customer out on day two converts a fixable billing problem into a cancellation decision. Keep the service on, run the recovery sequence, and let the lapse date — stated honestly in your final email — be the deadline.

What ties it together

Notice the pattern: updater, smart retries, human emails, prevention, measurement. That's dunning management as a system rather than a scramble. You can assemble it piecemeal — or run it as one engine: see how Swipe Again handles all nine.

Related reading: Why payments fail