A payment failure is a customer who wanted to pay and could not. That is a different problem from a customer who changed their mind, and it deserves a different response. Yet many stores treat both the same way: a generic error at checkout, or a cancelled subscription after one failed charge, with no attempt to recover the money.
This guide covers the two settings where payment failure matters most: checkout, where the customer is present and can fix it, and recurring payments such as subscriptions or instalments, where the customer is absent and the store must reach them. It explains why payments fail, how to categorise the failures, which recovery tactics work and how to measure results. It complements card testing attacks, chargeback prevention and order status update messages. Processor features differ, so check your provider’s documentation.
Why payments fail
| Cause | Soft or hard? | Typical fix |
|---|---|---|
| Insufficient funds | Soft | Retry later, often after payday; ask for another method |
| Expired card | Hard until updated | Card updater service or ask the customer to update |
| Card replaced or reissued | Hard until updated | Card updater; ask the customer |
| Bank security block or generic decline | Soft or hard | Customer contacts bank; retry; offer another method |
| Authentication required (such as 3D Secure) | Recoverable | Bring the customer back to authenticate |
| Incorrect details | Hard until corrected | Clear inline errors at checkout |
| Exceeded limit | Soft | Retry later or another method |
| Suspected fraud decline | Hard | Do not retry repeatedly; review |
| Processor or network error | Soft | Retry automatically with idempotency |
| Currency or region restrictions | Hard | Offer a local payment method |
Processors return decline codes that group failures into categories. Use them. A retry makes sense for a soft decline, never for a stolen-card decline, and repeated attempts on a hard decline can damage your standing with the issuer and the card networks. Your processor’s documentation lists the codes and recommended handling; see the sources at the end.
At checkout: rescue the sale in the moment
- Say what happened in plain words. “Your card was declined. Please check the details or try another method” is better than a code. Avoid revealing sensitive reasons such as fraud flags.
- Keep the cart and the entered details. Do not make the customer start over.
- Offer alternatives. Wallets, bank payments, buy now pay later where appropriate and local methods.
- Validate before submit. Catch typos in card number, expiry and postcode with inline checks.
- Support authentication smoothly. If the bank requires it, make sure the flow handles it, especially on mobile.
- Limit attempts. After several failures, slow down, both for fraud protection and to avoid blocks.
- Follow up. Treat a failed checkout with an email as a recoverable abandoned checkout, with a secure link; see abandoned checkout email examples.
Look at your gateway’s dashboard for decline rates by method, country and issuer. A sudden rise for one card type often points to a technical problem on your side or the processor’s, not to customers.
Recurring payments: involuntary churn
For subscriptions, memberships and instalment plans, a failed charge happens when the customer is not looking. If nothing recovers it, the subscription lapses and the revenue disappears, though the customer never chose to cancel. This is sometimes called involuntary churn, and for many subscription businesses it is a meaningful portion of all churn. Recovery comes from several layers.
| Layer | What it does | Notes |
|---|---|---|
| Card updater | Card networks and processors refresh expired or reissued card details automatically where supported | Enable in your processor; availability varies by region and card |
| Smart retries | Processor retries failed payments at times more likely to succeed, based on data | Check the retry window and limits |
| Pre-expiry reminders | Email customers before a card expires | Prevents the failure |
| Dunning emails | A short sequence asking the customer to update payment | Secure link; plain language |
| Grace period | Keep access or hold shipments for a limited time | Balance goodwill and risk |
| Alternative methods | Invite customers to pay another way | Wallets, bank debit |
| Final notice and cancellation | Close the subscription clearly | Offer easy reactivation |
A dunning sequence
Dunning is the polite repetition of a payment request. The aim is clarity and ease, not pressure. Three or four messages over about two weeks is typical, aligned with the retry schedule.
| Message | Timing | Content |
|---|---|---|
| 1. Heads-up | Immediately after the first failure | Payment did not go through; here is a secure link to update; we will try again |
| 2. Reminder | A few days later, after a retry | Still unable to take payment; steps to fix; what happens next |
| 3. Warning | About a week in | Access or shipment will pause on [date] unless updated |
| 4. Final notice | At the end of the grace period | Subscription cancelled or paused; how to restart in one click |
- Use the customer’s name, the product and the amount.
- Link to a secure page hosted by your processor or store; never ask for card details by email or reply.
- Offer help: “Reply if you would like to pay another way”.
- Keep tone neutral. Cards expire; nobody did anything wrong.
- Send from a recognisable address and check authentication, so messages reach the inbox.
- Suppress the sequence once payment succeeds, immediately.
Retry strategy
Retries should be informed by the decline category. Retry soft declines on a schedule spread over days, not hours, and consider timing around typical paydays. Do not retry hard declines such as lost or stolen cards. Respect card network rules on retry limits, which restrict how many times you can retry a declined payment within a period; your processor can tell you the current rules. Always use idempotency keys so that a retry after a network error cannot create a double charge; see duplicate orders and idempotency.
Communicate with care
Failed payment messages are transactional but they touch on money and trust. Be accurate about what was charged, avoid threatening language and make cancellation and support easy. Remember that fraud criminals imitate such emails, so train customers to expect them from a known address with a link to your own domain, and warn that you will never ask for card details by email.
Special cases: instalments, high-value orders and marketplaces
- Instalment plans. A failed instalment needs the same dunning flow, with the remaining balance and the consequences stated plainly. Check local credit and consumer rules before using collection language.
- High-value orders. A failed payment on a large order justifies a personal email or call from a person, not just an automated sequence.
- Pre-orders. If payment is taken at dispatch, a failure at that point should pause shipment and ask for an update; see backorder and preorder management.
- Marketplaces. The marketplace handles payment; your job is to ship and communicate, not to chase payment.
- International customers. Offer local payment methods and show prices in local currency, since cross-border declines are common.
Reconcile recovered payments
Recovered payments reach your books as ordinary payouts, but they also change reports. Make sure that orders marked failed and later paid are linked, that you do not double count revenue and that any fees on failed attempts are recorded. A monthly report of failed amounts, recovered amounts and written-off amounts keeps the accounts honest and shows whether recovery work is paying for itself. The method is the same as in the monthly bookkeeping checklist.
Metrics
| Metric | Why it matters |
|---|---|
| Payment failure rate | Overall and by cause, method and country |
| Recovery rate | Share of failed payments eventually collected |
| Revenue recovered | The money; compare with the cost of tools |
| Time to recovery | Faster is better; shows which step works |
| Involuntary churn | Subscriptions lost to failure |
| Support contacts about payments | Friction indicator |
| Dispute rate after recovery | A rise suggests unclear communication |
A worked example
A subscription store bills 3,000 customers monthly at $32. About 6 percent of charges fail, or 180, worth $5,760. Before any recovery, it retries once and recovers about 25 percent. After enabling card updater, spaced smart retries and a four-message dunning flow, recovery rises to about 62 percent, or 112 payments, an improvement of around 67 recovered payments, roughly $2,150 a month. Over a year that is about $25,700 of revenue, plus retained customers who go on to pay again. Costs are mainly the setup time and any processor fees for the services. The figures are illustrative; actual rates depend on your customers and processor.
Mistakes to avoid
- Cancelling after one failure.
- Retrying hard declines.
- Generic error messages at checkout.
- Dunning messages that ask for card details.
- Not stopping the sequence after payment succeeds.
- No idempotency, so retries double-charge.
- Ignoring decline rate spikes that signal a technical fault.
Sources and further reading
Figures and rules in this guide come from the primary pages below. Platform limits and prices change, so open the page before you build on a number.
- Stripe Docs: decline codes, what each decline code means and how to respond
- Stripe Docs: automatic card updates, how card details are refreshed
- Shopify Help Center: failed payments, handling payments and declines in Shopify