Decline Recovery: How to Recover Failed Payments Without Burning Attempts

Where the recoverable money is

Not every decline is worth chasing. The first job is to sort failures into the three groups that behave differently.

Codes as returned by most US gateways; the exact code set varies by processor. The decline-codes guide has the full table.

The proportions matter because they decide where the effort goes. A merchant whose declines are mostly soft needs a good retry schedule and little else. A merchant with an ageing card file needs the update-your-card message working. A merchant retrying hard declines is paying to be told no.

The reattempt rules you are operating inside

Retrying used to be free. It is not any more. Both major networks limit reattempts and charge for excess, and the fees arrive on your processor statement months after the attempts.

• Visa prohibits reattempting a Category 1 decline (the issuer will never approve: closed, lost, stolen, invalid account, revoked authorization). For other declines it allows up to 15 reattempts in 30 days on the same card for the same transaction and charges a per-attempt fee beyond that, and for any reattempt of a Category 1 decline. Rules as published at the time of writing.
• Mastercard returns a merchant advice code with many declines: 01 means get updated card details, 02 means try again later, 03 means do not try again, 21 means the cardholder has cancelled this recurring payment. Attempts that ignore 03 or 21 are charged. Mastercard also caps repeated attempts on a card within 24 hours and across 30 days.

A recovery process that needs more than four or five attempts per failure is not recovering more; it is paying more. Count attempts per card, not per invoice, because the limits do.

The retry schedule

A retry recovers money when the issuer's answer can change and the retry lands when it is likely to have changed. The schedule below works for most recurring billers; adjust the days to your customers' pay cycles once you have data.

Soft declines only. Hard declines skip straight to the customer message. Codes that need new data (54, 14, AVS/CVV) are retried only after the customer updates the card.

Details that make the schedule work:

• Vary the time of day and avoid weekends. Issuer risk models see a 3:00 a.m. attempt repeated daily as a script.
• Flag every retry as a merchant-initiated transaction with the stored-credential indicators and the network transaction ID from the first payment. Unflagged retries are declined more often. See CIT vs MIT and the stored credentials guide.
• Do not retry by switching gateways. The issuer decides, and it sees the same card and merchant either way. The exception is a 91 or 96 caused by an outage at your processor.
• Stop on a cancellation signal. A Mastercard advice code 21, a Visa R0 or R1, or a customer reply saying "cancel" ends the schedule immediately. Billing a customer who has told their bank to stop is a chargeback waiting to happen.

Messages that get the card updated

The retry schedule recovers soft declines. Everything else is recovered by the customer, and the customer only acts on a message they notice, understand and can act on in under a minute.

Channel

Email alone recovers the least; it lands in a folder the customer checks weekly. A text with a link gets opened within minutes by most people, which is why text-to-pay recovers the needs-new-card group at several times the rate of email. Use both, text first, and keep the consent you collected for texting (the text-to-pay compliance guide covers what that requires).

Content

Every message has the same four parts: what happened, what it affects, the one thing to do, and the link that does it.

What makes it work: the customer's name, the amount, the last four so they know which card, a reassurance about service, a single action, a link that goes straight to a card form with nothing else on it, the date of the next attempt so they are not surprised, and a way to reach a person. What breaks it: "payment failed, please login to your account and navigate to billing settings", a link that lands on a login page, a tone that treats the customer as delinquent on day one.

Timing

• Day 0: first notice, the same day as the failure, for every decline. For soft declines this is optional but harmless; for needs-new-card and hard declines it is the recovery.
• Day 5 to 7: second notice, after the second retry has also failed.
• Day 10 to 15: final notice with the consequence and date.
• Before the next billing date: for cards that expire next month, a message now prevents the decline altogether. Expiry dates are in your card file; use them.

The card update page

The link should open a page that already knows who the customer is, shows the amount and what it is for, has a card form and a button, and nothing else. No login, no account menu, no upsell. When the customer saves the card, charge it immediately and confirm by the same channel. A page that charges on save recovers the balance and the future renewals in one step.

Preventing the decline in the first place

The cheapest decline to recover is the one that does not happen. Four habits remove a meaningful share of them:

1. Send the stored-credential indicators on every card-on-file charge, with the network transaction ID from the first payment. Issuers approve properly flagged merchant-initiated charges at higher rates than unflagged ones.
2. Keep tokens pinned to the merchant account that created them. A token reused through a different MID or gateway loses its history and looks like a first-time charge.
3. Turn phone orders into customer-initiated transactions by sending a payment link instead of keying the card. CIT approves more often than MOTO, and the customer's own entry removes typing errors.
4. Bill on the days that approve. Your authorization rate by day of month tells you when your customers have money. Move billing dates toward it where the contract allows.

Measuring recovery honestly

Three numbers, and a trap.

The trap is the authorization rate on the dashboard. If technical failures (gateway timeouts, your own errors, processor outages) are counted as declines, the number reflects your infrastructure, not issuer decisions, and every outage looks like a wave of customers with no money. Keep system failures out of the decline figures, or at least report them separately, before drawing any conclusion about customers or issuers.

Review the numbers monthly by decline reason. The pattern that usually appears: most recovered dollars come from the second and third attempts and from the first text message, and almost nothing comes from the fourth attempt or the third email. Cut what is not working and the cost per recovered dollar improves without the recovery rate falling.

The playbook on one page

1. Classify every decline as soft, needs-new-data or hard at the moment it arrives, per gateway.
2. Retry soft declines on a schedule of three to four attempts over two weeks, flagged as merchant-initiated, on weekdays, at varying times.
3. Never retry a hard decline, a Mastercard advice code 03 or 21, or a Visa Category 1 response.
4. Send a text and email the day of the failure with the amount, the last four, one link to a card page with nothing else on it, and the date of the next attempt.
5. Charge the balance immediately when a card is updated and confirm by the same channel.
6. After the final attempt, suspend or pause and hand the balance to a payment link; do not keep retrying.
7. Message customers whose cards expire next month before the billing date.
8. Keep system failures out of the decline figures.
9. Report initial decline rate, recovery rate and cost per recovered dollar monthly, by reason and by processor.
10. Cut the attempts and messages that recover nothing.

Where FloPay fits

FloPay's decline recovery classifies every response from NMI, USAePay, Authorize.net, Stripe, Maverick and FluidPay as hard, soft, fraud or system the moment it arrives, retries soft declines on installment plans and subscriptions up to three times on a schedule you set, and suspends the plan on a hard decline instead of burning attempts. Customers and staff can be notified at each attempt, and exhausted plans surface for a text-to-pay follow-up. Every card-on-file charge carries the stored-credential flags and network transaction ID, and the analytics keep technical failures out of your authorization rate so the number you manage to is the issuers' decision, not your uptime.