P
Glossary
Payment Retry
Payment retry is the practice of reattempting a declined card charge on a scheduled cadence, using the issuer's decline code to decide whether another attempt can succeed. Card networks cap how many reattempts a merchant may make and charge fees past that limit, so the schedule matters as much as the attempt.
Key Takeaways
Visa caps reattempts on category 2 and 3 declines at 15 per rolling 30 days, then bills $0.10 per excess domestic attempt plus $0.05 cross-border, live since April 2022.
Stripe recommends "a maximum of eight retries for charges that permit retries," warning that more can read as fraud and raise declines on legitimate charges.
Mastercard names the interval outright: merchant advice codes 24 through 30 run from "Retry after 1 hour" to "Retry after 10 days," and codes 03 and 21 mean stop.
A lost_card, stolen_card, or expired_card decline fails identically every time, so those need new credentials rather than a schedule.
Network tokens survive card reissue because the stored value isn't the card number. Adyen reports "an average uplift of 3% in authorization rates" from them.
What does a decline code tell you about whether to retry at all?
The decline code tells you whether the issuer refused this attempt or refused this card, and only the first is worth reattempting. Stripe's decline code reference gives a next step per code, and this is the split that governs retry logic:
Decline code | What the issuer signalled | Worth retrying? |
processing_error | Error while processing the card | Yes, then later if it repeats |
issuer_not_available | Issuer couldn't be reached | Yes, quickly. The card is fine |
insufficient_funds | Card lacks the funds | Yes, later |
expired_card | The card has expired | No. Use another card |
lost_card, stolen_card, pickup_card | Reported lost or stolen | No, and repeats carry fraud exposure |
incorrect_cvc | The CVC is wrong | Not unchanged. Correct it first |
revocation_of_authorization | Recurring authority pulled | No |
Stripe also returns an advice_code collapsing the table into three instructions:
do_not_try_again: the card "shouldn't be used again for the same transaction."
try_again_later: the issuer "declined the transaction, but you can retry it."
confirm_card_data: some detail is wrong and needs correcting first.
If you read one field, read that one. It hides a nuance: Stripe points insufficient_funds customers at another payment method while Visa treats the same failure as retryable. Both are right at their own layer.
How long should a retry schedule run before it stops helping?
The networks set the outer bound, and it's tighter than most schedules assume. Published limits bind before your own judgment does:
A Visa decline category of 2 (wait and retry) or 3 (correct and retry) allows 15 reattempts per 30 days. Past that comes an excessive reattempt fee: $0.10 domestic, $0.05 more cross-border.
Visa category 1 codes mean "no circumstance in which the Issuer will grant an approval." One reattempt of those is excessive by itself.
Stripe recommends "a maximum of eight retries," because "card issuers might see creating additional retries as potential fraud."
Mastercard skips the guesswork. Its merchant advice codes name the wait outright:
Merchant advice code | Meaning |
01 | New account information available |
03 | Do not try again |
21 | Payment cancellation |
24 | Retry after 1 hour |
25 | Retry after 24 hours |
26 | Retry after 2 days |
27 | Retry after 4 days |
28 | Retry after 6 days |
29 | Retry after 8 days |
30 | Retry after 10 days |
We've found the practical read is simple. Honor the interval the code names, stay inside the cap, and stop the moment a code turns into never-retry. Attempts made after the issuer said no cost money, hurt approval rates, and push a subscription toward involuntary churn without improving the odds. Log each against an idempotency key so a late-clearing charge reconciles to one invoice.
Which card-side services remove the need to retry?
Account updater and network tokenization fix the stored credential before the renewal charge, which beats any schedule because nothing needs recovering:
Account updater. Visa, Mastercard, and Cartes Bancaires run services reporting changes to a stored card: new expiry date, replacement card, loss report, or revoked authorization. Adyen's real-time variant checks on decline, fixing it inside the same attempt.
Automatic card updates. Stripe attempts an update whenever a customer gets a new card, covering "most American Express, Visa, Mastercard, and Discover cards" issued in the United States. Support elsewhere varies and participating cards aren't identifiable.
Network tokens. A network token is a 16-digit stand-in for the card number, unique to one shopper and one merchant. Per Adyen's docs, "if the shopper receives a new card because the old one expired or was lost, the network token remains the same." Adyen reports a 3% average authorization uplift.
The webhook. Stripe's payment_method.automatically_updated event carries the new expiry date and last four digits, so your records stay current without a failed charge finding out first.
Related terms
Payment retry sits between the processor and the billing ledger, alongside these:
Involuntary churn is what a subscription becomes when retries run out.
Idempotency key keeps a reattempted charge from posting twice.
Billing cycle sets the renewal date the retry window runs from.
Draft invoice holds the charge while attempts remain outstanding.
Revenue leakage names the wider problem of earned money that never lands, failed retries included.
FAQ
How is payment retry different from dunning?
Payment retry is the machine reattempting the charge, dunning is the messages asking the customer to act. Retries run against the issuer, dunning against the inbox. Most flows run both, because a do_not_try_again code kills the retry while the email is still right.
Do payment retries need an idempotency key?
Yes, on the request layer. An idempotency key stops a timeout or an ambiguous response from turning one retry into two live charges, a real risk when the issuer succeeds but the response never arrives. It scopes to the attempt, not the invoice.
What does Mastercard merchant advice code 01 mean?
Merchant advice code 01 means new account information is available for that card. The issuer is saying the stored credential is out of date and a current one exists through account updater or a network token. Retrying the old details wastes an attempt.
Can a charge succeed after an authentication_required decline?
Only after the customer authenticates. Stripe returns authentication_required when the transaction needs 3D Secure, and off-session charges can't complete that flow alone. The fix is an on-session prompt, not another silent attempt.
Back to glossary
















