PaymentRetryAlertWhat a payment retry is
A payment retry is a second authorization request for the same charge after the first was declined. In recurring billing it is usually merchant-initiated: the customer is not present, the card is on file, and your billing system decides when to try again.
That decision is worth more than it looks. Involuntary churn, customers lost because a payment failed rather than because they chose to leave, is one of the biggest controllable leaks in a subscription business. Industry research from Paddle, Baremetrics and others puts it at somewhere between a fifth and two fifths of all churn. Most of those failures are soft declines that would have approved if you had asked again at the right time.
Which declines to retry
The first rule of retries is that the decline reason decides everything. Card networks return a response code with every decline, and those codes split into two families.
Soft declines are temporary. The card is valid, the customer is real, and something about this particular attempt failed. Insufficient funds (code 51), exceeded limits (61 and 65), issuer unavailable (91) and most “do not honor” responses (05) fall here. These are retry candidates.
Hard declines are permanent until something changes. Expired, lost, stolen, invalid or restricted cards, and any decline accompanied by a Mastercard Merchant Advice Code 03 (“do not try again”) or 21 (“recurring payment cancelled”). Retrying these cannot work, and both networks penalise merchants who do it anyway.
If you only fix one thing in your retry logic, make it this split. A surprising number of billing systems retry every failure on the same schedule, which burns attempts on cards that can never approve and dilutes your authorization rate with the issuers who matter most.
Rule of thumb. Retry soft declines. Route hard declines to your account updater or to the customer. Never retry a card the issuer has told you to stop charging.
Why insufficient funds deserves its own strategy
Among soft declines, insufficient funds is in a class of its own. Mastercard’s own data puts it at around 60 percent of recurring-payment declines. It is also the one where timing is everything: the card works, the customer wants the product, and the only variable is whether money is in the account at the instant you ask.
That makes it the decline where a schedule fails most expensively. Retry too early and you add a processing fee and another decline to the card’s history. Retry too late and the customer has churned, or spent the money that arrived. Every other recovery tactic, from dunning emails to backup cards, is a fallback for getting this timing wrong.
Retry timing: schedules, heuristics and signals
There are three ways to decide when to retry, and most billing stacks use the first two.
Fixed schedules are what WooCommerce Subscriptions, Braintree’s recurring billing settings, Recurly’s retry rules and Chargebee’s dunning schedules do by default. Their one virtue is that they exist.
Heuristic and machine-learned timing is genuinely better than a fixed schedule. It is still a prediction. The model has no visibility into the cardholder’s balance and learns only from the outcomes of its own attempts, each of which costs an attempt and a fee.
A network signal is newer and narrower. It is not a prediction; it is an observation made where the money actually moves. It covers Mastercard insufficient-funds and limit declines only, and it slots in alongside whatever retry tooling you already run rather than replacing it.
The practical combination for most teams is a heuristic scheduler for breadth plus a network signal for the highest-value slice, with a hard cap on total attempts.
Retry limits and what reattempts cost
Both networks now police reattempts, and the rules have tightened every year since 2021.
Visa allows at most 15 reattempts on the same card for the same merchant within 30 days, and treats attempts beyond that as excessive under its Excessive Reattempts rule, with fees passed through by your acquirer. Visa also classes some declines as “do not retry” outright.
Mastercard runs the Transaction Processing Excellence programme, which charges for authorization attempts beyond its thresholds. The programme is framed around limits on declined attempts per card within 24 hours and within a rolling 30-day period, and it adds a separate fee to every attempt made after a Merchant Advice Code 03 or 21. Fee amounts and thresholds are updated in network bulletins, so confirm the current figures with your acquirer.
On top of the network fees, each authorization attempt costs you a processing fee whether it approves or not. A retry that had no realistic chance of approving is pure cost.
What this means in practice. Fewer, better-timed attempts beat more attempts. If your billing system retries eight or ten times per failed invoice, you are almost certainly paying fees on attempts that were never going to approve.
Building a retry policy
A defensible retry policy for recurring billing looks like this.
- Classify every decline by response code and, on Mastercard, by Merchant Advice Code. Store both.
- Stop immediately on hard declines and on MAC 03 or 21. Trigger account updater on lifecycle declines (expired, MAC 01).
- Respect issuer timing where it is given. Mastercard’s Authorization Optimizer returns MAC 24 to 30 on insufficient-funds declines, telling you to wait one hour to ten days. Retrying earlier wastes the attempt.
- Use a signal where you have one. For Mastercard insufficient-funds declines under monitoring, wait for
RETRY_NOWand retry immediately when it arrives, because the approval likelihood decays with delay. - Fall back to timing heuristics for everything else: paydays, mid-morning in the cardholder’s time zone, spacing of at least a day between attempts.
- Cap attempts well below the network limits. Three or four is plenty.
- Escalate to the customer only after the retries you have good reason to expect will fail. A dunning email that arrives after a silent recovery has already succeeded is worse than no email.
- Measure recovery per attempt, not just overall. The first retry usually recovers the majority; if your fourth attempt approves less than a few percent of the time, remove it.
Retries and your authorization rate
Issuers score merchants. A merchant who sends many doomed authorizations looks, from the issuer’s side, like a merchant with poor controls, and that can lower approval rates on future good transactions. This is the hidden cost of aggressive retry schedules and the reason the networks introduced reattempt rules in the first place.
The corollary is that a retry policy which only sends attempts likely to approve does more than recover revenue. It improves the approval rate on first attempts too.
Where PaymentRetryAlert fits
PaymentRetryAlert is deliberately narrow. It covers one decline family, Mastercard insufficient funds and exceeded limits, and it does one thing: tells you when a retry is more likely to succeed. You keep your processor, your billing platform and your existing retry schedule. The alert is an additional, high-priority trigger, and monitoring cancels itself if your own retry gets there first.
If most of your failed recurring payments are insufficient-funds declines on Mastercard cards, which for many subscription businesses they are, that one trigger addresses the largest and most time-sensitive slice of your retry problem.
- Stripe, Automate payment retries (Smart Retries)
- Stripe, Decline codes
- Mastercard, Decline details and Merchant Advice Codes
- Mastercard, Turn more declines into approvals with smarter payment optimization
- Chargebacks911, Visa Excessive Reattempts rule