Hard vs Soft Declines: The Complete Guide

A soft decline indicates a temporary condition that may change without any action from the cardholder or merchant. The card number is valid, the account is open, and the issuer is not permanently blocking the transaction.

Common soft decline scenarios:

• Insufficient funds (Code 51): The cardholder's balance is below the charge amount. It may increase after a paycheck deposit.
• Issuer unavailable (Code 91): The bank's system is down. It will come back online.
• Exceeds limit (Code 61): A daily spending cap was hit. It resets at midnight.
• Generic refusal (Code 05): The issuer declined without a specific reason. The condition may be temporary.

Soft declines are the entire reason retry logic exists. Without retries, every soft decline would result in a lost payment, even though many of them would have succeeded hours or days later.

A hard decline indicates a permanent condition. The card is closed, stolen, expired, or fundamentally invalid. Retrying will produce the same result every time.

Common hard decline scenarios:

• Lost/stolen card (Codes 41, 43): The cardholder reported the card compromised. A new card number will be issued.
• Expired card (Code 54): The expiry date has passed. The replacement card has a different CVV.
• Invalid card number (Code 14): The PAN fails the Luhn check. No amount of retrying fixes a typo.
• Account closed (Code 46): The issuer closed the account entirely.

Retrying hard declines wastes processing fees, accumulates network penalty charges (Visa charges $0.10-$0.15 per excess retry), and damages your standing with acquirers and card networks.

Code 05 (Do Not Honor) is the most common decline code on every card network, and it is the hardest to classify. Visa places it in Category 4 (Generic), which means it is technically retriable with up to 15 attempts in 30 days. But the label "generic" hides a bimodal distribution.

Roughly 50% of Code 05 declines mask what should be hard declines: suspected fraud, closed accounts, and permanent blocks that the issuer chose not to disclose. The other 50% mask genuinely recoverable conditions: insufficient funds, temporary risk flags, and velocity checks that will reset.

This split makes Code 05 the most important code to get right and the hardest. A blanket "always retry" approach wastes half your attempts on transactions that will never succeed. A blanket "never retry" approach abandons half the revenue you could have recovered.

Simple rules-based retry strategies plateau quickly on Code 05 because they cannot distinguish the recoverable half from the non-recoverable half. Effective Code 05 recovery requires additional context: the cardholder's payment history, the card type, the transaction amount, and ideally a model trained on historical outcome data for similar transactions. This is one area where the gap between default billing platform retries and purpose-built recovery systems is widest.

Here is something most payments engineers do not know: VisaNet remaps Code 59 (Suspected Fraud) to Code 05 before the response reaches the merchant. The issuer sends Code 59, but you receive Code 05.

This means a meaningful portion of your Code 05 declines are actually fraud declines in disguise. VisaNet does this to prevent merchants from learning which specific transactions the issuer flagged as fraudulent, since that information could theoretically be used to refine fraud techniques.

The practical impact: you cannot distinguish between a Code 05 that is "insufficient funds in disguise" and a Code 05 that is "confirmed fraud in disguise." This is one reason why Code 05 recovery rates plateau around 20-30% with simple retry logic. More sophisticated systems use ML models trained on transaction metadata (time of day, amount, customer tenure, card type) to predict which Code 05 declines are likely recoverable.

Visa uses a 4-category system:

• Category 1 = Hard (never retry)
• Categories 2, 3, 4 = Soft/retriable (up to 15 retries in 30 days)

Mastercard uses Merchant Advice Codes (MACs):

• MAC 03 (do not retry) and MAC 21 (payment canceled) = Hard stop
• MAC 01 (updated info available), MAC 02 (try again later), MAC 24-30 (timed retries) = Soft/retriable
• MAC 40 (non-reloadable prepaid) and MAC 41 (single-use virtual card) = Effectively hard for recurring billing

Amex is a different story entirely. See the next section.

American Express processes its own transactions (it is both the network and the issuer for most Amex cards), and it returns Code 05 for the vast majority of declines. Industry estimates and merchant reports consistently put the figure above 80%, with some datasets suggesting it may exceed 90%. The exact number varies by merchant category and geography, but the pattern is clear: Amex declines are far more opaque than Visa or Mastercard.

Amex does not publish a category system like Visa, and it does not provide merchant advice codes like Mastercard. The decline code alone carries almost no signal about whether a retry will succeed.

This is where the limits of a code-level retry strategy become obvious. The same Code 05 from Amex could be insufficient funds, suspected fraud, or a permanent block. Without supplementary signals from the network, you are guessing. Building effective Amex recovery requires transaction-level intelligence that goes beyond what the response code provides: customer history, behavioral patterns, and ML models trained on outcome data.

Recovery rates vary dramatically based on how a business approaches failed payments. At the low end, companies using their billing platform's default retry logic (typically a fixed schedule of 3-4 attempts) recover less than half of soft declines. At the high end, systems that combine ML-optimized timing, network signal parsing (MACs, Visa categories), and proactive card updates through Account Updater recover significantly more.

The gap between these tiers represents real revenue. For a subscription business with $10M ARR and a 7% decline rate, the difference between default retry logic and an optimized recovery system can be hundreds of thousands of dollars per year.

What separates the tiers is not just retry count or timing. It is the ability to incorporate multiple signals per transaction: the decline code, the network advice code, the card type (debit vs credit), the customer's payment history, and the time of day. No single signal is sufficient. The systems that perform best are the ones that weigh all of these together and adapt their approach per transaction.

This is the core problem with building retry logic in-house: the marginal gains come from compounding dozens of small optimizations, each requiring its own data pipeline and ongoing calibration. Most engineering teams underestimate the maintenance burden and plateau well below what a purpose-built recovery platform achieves.

Debit cards decline at roughly 10% compared to 5% for credit cards. And 52% of all payment declines now involve debit cards, even though debit represents a smaller share of total transaction volume.

The reason is structural. Debit cards draw from a checking account with a hard balance ceiling. Credit cards have a revolving credit limit that is typically much higher than the cardholder's average spend. A $200 subscription charge is much more likely to exceed a checking account balance than a credit limit.

Debit declines are also more time-sensitive. Checking account balances fluctuate daily with direct deposits, bill payments, and ATM withdrawals. The optimal retry window for a debit decline is narrower than for credit cards, where declines more often reflect issuer-side fraud flags or limit issues that resolve less predictably.

If your customer base skews toward debit (common in B2C SaaS, streaming services, and fintech), you should expect higher baseline decline rates. Effective debit recovery requires retry logic that accounts for this difference rather than treating all cards identically.

Between 20% and 40% of subscription churn is involuntary, caused by payment failures rather than conscious cancellation. The customer wants to keep paying. Their card just did not work that day.

This means your churn rate is not purely a product retention problem. A significant chunk of it is a payments engineering problem. Every percentage point of improvement in decline recovery translates directly to reduced churn and increased LTV.

The companies that treat payment recovery as a first-class engineering challenge (parsing network signals, implementing dynamic retry schedules, maintaining Account Updater integrations, and using ML to predict recoverability) consistently outperform those that rely on their billing platform's default retry logic.