Retry strategies that actually move approval rate
Timing, cascade order, and decline-code awareness separate retries that recover revenue from ones that burn issuer goodwill.
Most retry logic is a loop with a sleep in it. It fires on every decline, waits a fixed interval, and tries again — sometimes against the same acquirer, sometimes until a counter runs out. It recovers some revenue, which is why nobody looks closely. What it also does is spend issuer trust and scheme fees on attempts that were never going to succeed.
The difference between a retry that recovers revenue and one that costs money is almost entirely in the decline code. Retrying is not one decision — it is three: whether, when, and where.
Whether: the decline code already told you
Visa response codes fall into four behavioural categories, and only two of them are worth another attempt. The categories matter more than the individual codes, because the same code can mean different things across schemes.
| Category | Examples | Retry? |
|---|---|---|
| Hard decline — the credential is bad | 04 pick up card, 07 pick up (fraud), 41 lost, 43 stolen, 14 invalid PAN | Never. The card will not become valid. Retrying risks fraud-monitoring flags. |
| Soft decline — the issuer said not now | 51 insufficient funds, 61 exceeds limit, 65 activity limit | Yes, but with real delay. State changes on the issuer side, not yours. |
| Auth / data — the request was wrong | 1A SCA required, 05 do not honor, 10 partial approval | Yes, but only with something changed — authentication, fields, or route. |
| Unknown — no useful signal | Issuer-specific and unmapped codes | Once, then treat as terminal. You are guessing. |
When: fixed intervals are the wrong model
A soft decline and a data problem need opposite timing. 51 depends on the cardholder's balance changing — retrying in 30 seconds tests nothing, while retrying in 24–72 hours catches payday and deposit cycles. 91, issuer unavailable, is the opposite: it is a transient systems failure, and the right retry is seconds later, possibly through a different acquirer whose connection to that issuer is up.
For subscription billing the calendar matters more than the interval. Attempts clustered around the 1st and 15th compete with everyone else's billing runs against the same balance. Moving a retry off those days is often worth more than adding another attempt.
Where: the same card can succeed on a different route
Approval is not a property of the card. It is a property of the card, the acquirer, the MCC, and the amount together. An issuer that declines a cross-border authorization from one acquirer may approve the identical transaction presented by an acquirer with local presence in the cardholder's market — different interchange, different risk profile, a relationship the issuer's rules recognise.
That makes cascade order a routing decision, not a fallback list. The second attempt should go to the acquirer with the best historical approval rate for that issuer and MCC, not simply the next one configured.
The ceiling nobody plans for
Both major schemes cap retry behaviour and charge for exceeding it. Visa limits attempts on a declined authorization within a rolling window, with tighter limits for codes that indicate the credential is dead. Mastercard applies fees for excessive attempts against the same declined transaction. Aggressive retry logic hits these ceilings quietly — the cost lands as scheme fees on the monthly statement, months after the code shipped.
Retry budget is finite. Spending it on hard declines means not having it for the soft ones that would have converted.
Measure against a holdout or do not claim the lift
Retry recovery is the easiest number in payments to overstate. A share of retried transactions would have succeeded on a later organic attempt by the cardholder — a repeat purchase, a manual re-entry — and counting those as recovered revenue attributes to the retry logic something it did not cause.
The only honest measurement is a holdout: a random slice of eligible declines that gets no retry. The difference between cohorts is the lift. It is always smaller than the gross recovery number, and it is the one that survives scrutiny.
See these patterns in your own traffic
Apex analyzes every transaction against the decline, routing, and cost signals described here.
Request a demo