Smart Payment Retries: Which Declines Should Be Retried?

Smart payment retries recover failed transactions by re-attempting only the declines that can actually succeed: soft declines such as insufficient funds, issuer timeouts, and generic "do not honor" responses. Hard declines (closed accounts, stolen cards, cardholder-cancelled mandates) must never be retried; Visa and Mastercard now charge per-attempt penalty fees for doing so. The decision is no longer merchant intuition. Visa's four decline categories and Mastercard's Merchant Advice Codes tell merchants exactly which failures to retry, when, and how many times. Juspay, which orchestrates payments across 150+ countries, builds retry logic directly on these network signals.

Payment failures are a major issue for companies today. A study on involuntary churn by Churnkey and Stripe analyzed 5.4 million failed payments across 25 million subscriptions. They discovered that subscription businesses lose 39% of their new customers every year. A big part of this loss is known as involuntary churn, which means the customer is lost even though they never actually chose to cancel.

Industry experts estimate that involuntary churn makes up 20% to 40% of all subscription churn. Furthermore, Recurly predicted that failed payments would cost businesses around $129 billion in 2025. While this is just one vendor's prediction, it matches the massive financial impact that major payment platforms experience at scale.

"20% to 40% of your churn is completely unnecessary," says Patrick Campbell, Co-Founder and CEO of ProfitWell (now part of Paddle). This loss stems directly from failed, expired, and delinquent cards rather than customers being unhappy with your service.

The instinct is to retry everything. That instinct is now expensive. This guide covers which declines should be retried, which must not be, and how the card networks' 2024- 2026 rule changes have turned retry logic from an optimization into a compliance requirement.

What Is the Difference Between Hard Declines, Soft Declines, and Data-Quality Declines?

A hard decline is a permanent failure that no retry can fix: the account is closed, the card was reported stolen, or the cardholder revoked authorization. A soft decline is a temporary failure, such as insufficient funds, an issuer system outage, or a velocity limit, that a well-timed retry can convert into an approval. A third bucket, data-quality declines, fails because the payment data is wrong (expired card, bad CVV): retriable, but only after the credential is corrected.

Most merchant content stops at the hard/soft binary. The third bucket matters because it changes the action: a data-quality decline should trigger a credential refresh (an account updater call or a network token lifecycle update) before any retry is attempted. Retrying the same stale credential simply reproduces the failure.

The mix of these buckets is heavily skewed toward recoverable failures. In the Churnkey–Stripe dataset, insufficient funds alone caused 40.5% of all subscription payment failures, and the catch-all "do not honor" response, a soft decline issuers use when they won't disclose the real reason, accounted for another 7.5%. In other words, the single largest decline reason on the network is one that retries handle well.

How Do Visa's Decline Categories Decide What You Can Retry?

Visa groups every decline response code into four categories that carry explicit retry rules and fees, in force since April 2021. Category 1 ("Issuer Will Never Approve") permits zero retries. Categories 2, 3, and 4 permit up to 15 re-attempts in a rolling 30-day window. The table below summarizes the four categories and the correct merchant action for each; the key conclusion is that the category, not the merchant's optimism, determines whether a retry is allowed.

Important Visa Rules to Remember:

There are two specific details in Visa's rules that confuse even advanced merchants. First, codes R0, R1, and R3 are stop-payment and revocation codes. This means the cardholder has directly instructed their bank to block the recurring charge. Retrying these payments is not just a fee risk, because Visa's Stop Payment Service is designed specifically to block these authorization attempts at the network level.

Second, a 2026 analysis of network retry rules by ChurnWard shows that Visa counts retries based on each specific credential. For example, if a payment declines on a network token and you retry it using the original card number (the PAN), Visa counts those as separate attempts. Because of this, your strategy for handling payment credentials must be built directly into your retry logic rather than being treated as a separate process.

What Do Mastercard's Merchant Advice Codes Tell You to Do?

Mastercard's Merchant Advice Codes (MACs) are explicit retry instructions attached to decline responses: MAC 01 means updated account information is available, MAC 02 means try again later, MAC 03 means do not try again, and MAC 21 means the cardholder cancelled the payment. Retrying the same card and amount within 30 days after a MAC 03 or MAC 21 triggers a penalty under Mastercard's Transaction Processing Excellence (TPE) program. That fee escalated from $0.15 per attempt in 2023 to $0.30 in January 2024 and $0.50 in January 2025.

This increase in costs is a clear sign of the future for payment networks: making blind retries is becoming too expensive for businesses to afford. The TPE program also sets a strict limit on your total retry volume. If you make more than 35 attempts on the exact same transaction within a 30 day period, you will be charged a per-attempt fee for every extra try. On top of that, the program issues separate penalties for card-testing activities, such as running repeated authorizations for less than $1.

Mastercard has gone further than prohibition. Its Authorization Optimizer program, rolled out for recurring card-not-present transactions from October 2023 in the US and January 2024 in Europe, responds to insufficient-funds declines with time-boxed advice codes: MAC 24 through 30 tell the merchant to retry after 1 hour, 24 hours, 2, 4, 6, 8, or 10 days respectively, based on the issuer's view of when the account is likely to be funded. MAC 40 and 41 flag non-reloadable prepaid and single-use virtual cards: credentials that will never support a subscription, so the right move is asking the customer for a durable payment method, not retrying.

And this is no longer a two-network story. Brazil's Elo scheme introduced its own retry limits in January 2025, grouping decline codes into reversible and irreversible sets and charging BRL 0.80 for each attempt beyond the group limit. Merchants operating across markets now face at least three distinct retry rulebooks, a coordination problem that grows with every market entered.

Which Declines Should Be Retried? A Four-Surface Decision Framework

The types of payment declines that can be retried include insufficient funds (code 51), issuer or network timeouts and system errors (91, 96), generic "do not honor" messages (05), and velocity or limit declines. You can also retry expired-card and CVV failures, but only after completing a credential refresh.

However, simply asking "should this be retried?" is the wrong approach if you are only thinking about the timing of the next attempt. A payment retry can actually adjust four different factors. The most advanced retry engines will evaluate all four of these areas when deciding what to do next:

1. Retry the route: Try sending the same transaction through a different payment processor, known as an acquirer or PSP. Problems like timeouts, gateway errors, and certain issuer risk declines are often tied to the specific route used. One acquirer's system might fail while another's succeeds. This strategy is called a cascading retry, and it is only possible if you use multi-provider setups.
2. Retry the credential: Try the same transaction again, but with better payment data. This could mean getting a fresh network token after a lifecycle update, using the actual card number (PAN) if de-tokenization fails, or getting updated card details from an account updater. This is the proper way to fix every Category 3 decline.
3. Retry the timing: Try the same transaction at a later time that is aligned to payday cycles, issuer business hours, and MAC 24-30 windows. This is the correct way to handle insufficient funds. Surprisingly, it is also the only retry method that most standard billing systems use.

Retry the customer: When silent retries are completely used up or not allowed, you must let the customer know about the failure. You can show them a backup payment method at checkout or run dunning outreach for recurring subscriptions. Data from Juspay's Retry Engine proves how effective this can be, as 40% of users who are shown a backup payment method after a failure will choose to pay with it.

The decision matrix below shows how to match specific decline signals to the correct retry surface. The main takeaway is that the error signal from the payment network tells you which retry surface you should choose. From there, additional context like the specific payment method, the geographic region, and the credential type helps you fine-tune exactly how the retry is executed.

As Juspay's engineering team put it in its analysis of recurring-payment churn: "Recurring transaction retries are ineffective without considering the diverse parameters." Important factors like the issuer BIN, card type, geographic region, payment credential, time of day, total retry count, and penalty exposure all affect one another. Because these details are so complex and interconnected, basic rule tables are eventually replaced by advanced models that are trained on real transaction outcome data.

When Should a Decline Never Be Retried?

A decline should never be retried when the network has said the answer is permanent: Visa Category 1 codes, Mastercard MAC 03 and MAC 21, and Visa's R0/R1/R3 revocation codes. Smart retries are also not applicable to flows that require fresh customer authentication (a 3DS challenge, an Apple Pay or Google Pay confirmation), because no system can silently supply the customer's consent.

There are two more rules that keep retry programs working properly. First, a retry engine is not designed to be a fraud tool. If your payment declines are clustering around suspected-fraud signals, such as a Mastercard decline 83 with MAC 03, you should fix the issue using better authentication and risk screening instead of just running more re-attempts.

Second, using smart retries is not a replacement for good credential hygiene. Tools like an account updater and network tokenization help prevent the expired-card declines that would normally waste your retry attempts. Every year, roughly 40% of cardholders replace a card due to expiry, loss, or a reissue. These types of payment failures are much cheaper to prevent ahead of time than to recover after they happen. For more details on how this prevention layer works

There is also a reputational cost that never appears as a line-item fee. Issuers score merchants on authorization quality; a merchant that floods the network with doomed re-attempts degrades its approval odds on legitimate traffic too. Knowing when not to retry protects every future transaction.

How Much Do Timing and Context Change Retry Success?

Timing is the most important factor when dealing with the largest category of payment declines. Failures due to insufficient funds make up 40.5% of subscription declines (Across 5M failed subscriptions) according to the Churnkey and Stripe data. These payments are most likely to recover when re-attempts perfectly match up with salary cycles. However, these pay cycles change depending on the market. For example, there are bi-weekly paydays in the US, monthly cycles in much of Europe and India, and various regional patterns everywhere else. Mastercard's MAC 24 to 30 windows formalize this exact same idea from the issuer's point of view.

Static schedules simply cannot handle this complexity. Fixed retry ladders that automatically fire every three, six, or nine days regardless of the decline reason are the legacy default in most billing systems. Unfortunately, the industry data on these older setups is not good. In 2025, the Merchant Risk Council reported that merchants who rely on basic retry rules and email notifications only recover about 15% of failed payments.

On the other hand, layered programs mentioned in the Churnkey and Stripe study recovered up to 70% of detected involuntary churn. The huge gap between recovering 15% and 70% does not come down to extra effort. Instead, it is entirely based on whether the retry system actually reads the decline signal and the surrounding context or just ignores both.

Looking Beyond the Calendar

The context of a failed transaction involves far more technical data than simply picking a new day to retry. Issuer behavior changes based on the BIN, the specific card product since debit recovers differently than credit, the transaction amount, and even the time of day compared to the issuer's processing windows.

Juspay has a massive cross-market view of 300 million daily transactions across more than 150 countries. This is exactly the kind of large dataset where these patterns become highly learnable instead of just being guesswork. This is why Juspay's approach to reducing involuntary churn treats the retry construct, frequency, and timing as a complex modelling problem rather than just a simple configuration checkbox.

Where Do Smart Retry Implementations Commonly Fail?

Smart retry implementations most often fail in four ways: retrying on masked or normalized decline codes, ignoring per-credential retry accounting, letting multiple systems retry the same failure, and measuring recovery without measuring penalty exposure.

Masked decline codes: Payment processors, known as acquirers, often translate and sometimes hide the original issuer response codes. Some will pass along the Merchant Advice Codes, while others drop them completely. If a retry engine only receives a basic "generic_decline" message, it is just guessing what went wrong. The solution requires a structural fix. You need to capture the raw network responses and Merchant Advice Codes directly at the integration layer. This is a hidden benefit of using an orchestration layer that connects directly to over 300 providers while preserving the exact response codes.

Wrong retry accounting: Different payment networks have different rules for counting retry attempts. Visa counts attempts based on the specific credential, the acquirer, and the transaction amount over a rolling 30 day period. Mastercard counts attempts based on the card and the amount, while Elo counts them per calendar month. If a merchant runs retries using both their billing platform and a built-in recovery tool from their PSP, they can easily exceed these limits without either system noticing. This creates a double-retry problem. To fix this, only one centralized system must be in charge of making the retry decisions.

Retrying data-quality declines without fixing the data: Trying to charge an expired card again is the most common way subscription businesses waste their retry attempts. Doing this burns through your allowed network attempt budget, which takes away attempts that a fully funded retry might actually need later.

Counting recovery instead of net recovery: A retry program might look successful on paper if it recovers $50,000. However, if that program also collects scheme penalties, damages your standing with the issuer, and adds per-attempt TPE fees, the real value is much lower than what your dashboard shows. Advanced programs always report the recovered revenue after subtracting all of the fees. They also closely track the health of their authorization rates for each issuer. This provides the exact type of decline-level visibility discussed in Juspay's guide to payment observability.

What Results Can Merchants Expect From Smart Retries?

Merchants should expect smart retries to recover a portion of eligible failed payments. They should not expect to turn every decline into an approval. The actual opportunity for recovery depends on your specific decline mix.

• Temporary failures: Issues like insufficient funds, issuer unavailability, or processing timeouts might succeed if the retry happens under better conditions.
• Permanent declines: Issues involving invalid credentials or transactions that require direct customer action will not improve simply by trying them again.

Because of this, a healthy program increases recovery by being selective. It only retries a payment when the underlying problem can change, and it stops when it cannot.

Immediate Results and Improvements

The most immediate results of a good system should be fewer wasted attempts, more revenue recovered from retryable declines, and less unnecessary disruption for your customers.

The exact size of the improvement will vary based on several factors, including issuer behavior, card type, geography, transaction amount, credential quality, and the merchant’s existing retry process. Merchants who are starting with a basic fixed schedule applied to every failure will have much more room to improve than those who are already using decline-specific rules and updated payment credentials.

How to Measure Real Value

To truly understand whether smart retries are creating real value, merchants should measure much more than just the number of payments they eventually recover. You should track the following metrics:

• The recovery rate by specific decline reason.
• The number of attempts required per recovered payment.
• The recovered revenue after subtracting network and processing fees.
• The time to recovery.
• The share of cases that still require customer action.

It is also important to monitor your overall authorization rates and customer complaints as safety guardrails. The clearest test is to run a controlled comparison against your existing retry approach. A highly successful platform will recover more eligible payments with fewer unnecessary attempts, all while keeping costs, compliance exposure, and customer friction completely under control.

The sheer scale behind these numbers is incredibly important. Juspay processes over 300 million daily transactions across more than 150 countries. Because of this massive volume, their retry models can learn from issuer behavior, BIN-level patterns, and specific decline-code outcomes at a level that no single merchant could ever experience on their own.

This massive scale provides a strong practical reason for running your retries directly inside a dedicated orchestration layer instead of just attaching them to a basic billing system. The exact same layer that routes the transaction, securely holds the payment credential, and reads the raw decline response is simply in the best position to decide what needs to happen next.

Key Takeaways:

• Know What to Retry: You should only retry soft declines (like insufficient funds, timeouts, and "do not honor" messages) or data-quality declines after the information has been corrected. You must never retry permanent errors like Visa Category 1, Mastercard MAC 03/21, or revocation codes R0, R1, and R3.
• Avoid Financial Penalties: Payment networks now enforce these rules by charging businesses money. Visa charges $0.10 to $0.15 for every improper or excessive re-attempt. Mastercard's TPE fee reached $0.50 per attempt in January 2025, and Elo charges BRL 0.80 for these errors in Brazil.
• Time Your Retries Properly: Insufficient funds is the biggest reason for payment failures, causing 40.5% of subscription failures according to the Churnkey and Stripe data. You can fix this best by using timing intelligence, such as payday alignment and Mastercard's MAC 24 to 30 windows, instead of using basic fixed schedules.
• Change Your Approach: A retry can change four different things about a transaction: the route, the credential, the timing, or the party asked. A smart retry system looks at the decline signal to choose exactly which of these surfaces to change, rather than just using brute force.
• Improve Your Recovery Rate: Basic retry rules only recover about 15% of failed payments. On the other hand, layered and signal-aware programs have recovered up to 70% of detected involuntary churn.
• Centralize Your System: A single system must own all retry decisions from beginning to end while ensuring that raw decline codes and MACs are preserved. This type of control is the natural purpose of an orchestration layer when you are using a multi-PSP stack.

Frequently Asked Questions

Which payment declines can be safely retried?

Soft declines can be safely retried: insufficient funds (code 51), issuer or network timeouts (91, 96), generic "do not honor" (05), and velocity-limit declines. Data-quality declines such as expired cards can be retried only after the credential is corrected via an account updater or token refresh. Hard declines, meaning Visa Category 1 codes and Mastercard MAC 03/21, must never be retried.

What happens if you retry a hard-declined transaction?

Retrying a hard decline triggers per-attempt network penalties: Visa charges $0.10 domestic or $0.15 cross-border for any re-attempt after a Category 1 decline, and Mastercard charges up to $0.50 per attempt after a MAC 03 or MAC 21 within 30 days. Repeated violations also degrade the merchant's standing with issuers, which lowers approval rates on legitimate traffic.

How many times can you retry a declined card payment?

Visa allows up to 15 re-attempts within a rolling 30-day window for Category 2, 3, and 4 declines, with excessive-reattempt fees beyond that. Mastercard penalizes attempts beyond 35 in 30 days under its Transaction Processing Excellence program and prohibits any retry after MAC 03 or 21. Elo, in Brazil, applies monthly limits by decline group. Staying well under the strictest limit is the safe cross-network policy.

What is the difference between a hard decline and a soft decline?

A hard decline is a permanent failure (closed account, stolen card, revoked authorization) that no retry can recover, and card networks penalize re-attempts. A soft decline is a temporary failure such as insufficient funds or an issuer timeout that a well-timed retry can convert to an approval. A third category, data-quality declines like expired cards, becomes retriable once the payment data is refreshed.

What are Mastercard Merchant Advice Codes and why do they matter for retries?

Merchant Advice Codes (MACs) are issuer instructions attached to Mastercard declines that tell merchants what to do next: MAC 01 signals updated account data exists, MAC 02 says try later, MAC 03 says never retry, and MAC 24–30 specify optimal retry windows from 1 hour to 10 days. Retry engines that read MACs recover more while avoiding the penalty fees charged for ignoring MAC 03 and 21.

How does Juspay decide which failed payments to retry?

Juspay's retry system reads the raw decline code and network advice signals, then selects among retry surfaces: cascading the transaction to an alternate PSP, refreshing the credential (network token or clear PAN), re-timing the attempt around payday and issuer patterns, or prompting the customer with a backup payment method. Juspay reports a 12% lift in overall success rates, with up to 25% of failed transactions recovered.