Soft vs hard card declines: A complete recovery guide for merchants
Payments 101
Updated 10 Sept 2026
13 min
Andrii Kononenko
Head of Merchant Operations, Solidgate
The difference between soft vs hard declines determines which recovery strategies actually work.
Most payment optimization comes down to retry mechanics and fallback logic – especially for , where a failed renewal means a lost paying customer.
At scale, the revenue math moves fast. An EdTech subscription business processing 100,000 monthly renewal attempts at $30 each, with a 6% decline rate, is looking at 6,000 failed payments and $180,000 in potential lost revenue every month.
Most merchants have the data – they just don't know what it's telling them. Network schemes return decline codes that distinguish between insufficient funds, expired credentials, fraud flags, and issuer-imposed restrictions. Alongside the decline reason, they signal what should happen next: retry immediately, wait, correct the data, or stop entirely.
In practice, the industry organizes declines into two categories – soft vs hard declines – that determine which recovery strategies apply.
The card decline recovery strategies that follow depend on getting that classification right. Misclassify a hard decline and you pay scheme fees for retrying a transaction that will never be approved. Misclassify a soft decline and you abandon revenue that a well-timed retry would have recovered.
This guide covers the differences between soft and hard declines, which are recoverable and how, what the scheme rules actually say about retrying, and the metrics that tell you whether your recovery strategy is working.
TL;DR
- Card declines split into two categories – soft (temporary, recoverable) and hard (permanent, do not retry). Treating them the same is where most recovery strategies fail.
- Soft declines account for 80–90% of all failures in subscription businesses. Recovery ceilings reach 40–70% with the right retry logic, routing, and tokenization.
- Hard declines make up the remaining 10–20%. Recovery is possible (20–30% ceiling) but requires customer action – updated card details, alternative payment methods, or clearer messaging.
- Retry limits are real: Visa allows up to 20 attempts per card within 30 days for retryable declines. Mastercard fees apply if attempts exceed 10 on the same card within 24 hours or 35 within 30 days – and any retry after a MAC 03 or MAC 21 triggers a fee immediately.
- Decline codes aren't standardized across payment providers. If you run multiple providers, a layer unifies them into one format – otherwise pattern analysis becomes manual and error-prone.
- The four recovery metrics to track: recovery rate, retry success rate, authorization rate per PSP, and cost per recovered transaction.
What is a card decline?
A card decline happens when a payment authorization request is rejected before the transaction completes. The rejection can come from the issuing bank, the card network, or the payment provider – each for different reasons, with different implications for what you should do next.
The issuer makes the final authorization decision on most declines. When a cardholder's bank receives a charge request, it evaluates it against account status, available funds, fraud signals, and card validity. If any of those checks fail, the issuer returns a decline code. The acquiring bank and card network relay that code to your payment provider, which passes it back to your system.
What matters operationally is the split between temporary (soft declines) and permanent (hard declines) failures. Some declines resolve themselves – the funds weren't there at midnight but are after a paycheck clears. Others will never resolve, because the card is closed, stolen, or flagged. Acting on that distinction correctly is what separates a recovery strategy from a retry loop.
Soft declines: Why they happen and how to recover them
Soft declines are temporary authorization failures on a valid payment method. The card exists and belongs to the cardholder, but something blocked the transaction at the moment of the attempt – insufficient funds, an authentication failure, a network error, or a temporary issuer flag.
In subscription businesses, soft declines account for 80–90% of all payment failures. Four of the top five decline reasons in subscription e-commerce are soft declines, including insufficient funds and temporary holds. Recovery ceilings reach 40–70% with the right combination of smart retries, routing, and credential management.
Soft decline codes
| Code | Reason | Description | Solution |
| 0.01 | General decline | The issuing bank didn't complete the transaction. | Ask the customer to retry a few times; subsequent attempts may succeed. |
| 0.02 | Order expired | The transaction wasn't completed within the allocated time. | Advise the customer to reattempt using the same card. |
| 1.01 | Authentication failed | The cardholder's authentication attempt failed. | Ask them to retry several times. Ensure your 3DS setup is working properly to reduce failures. |
| 2.01 | Invalid data / Order not found | Missing or incorrect transaction details. | Ask the customer to double-check and correct their payment information. If the issue persists, verify the order's existence and accuracy before reattempting. |
| 2.06 | Invalid CVV2 code | The CVV entered is incorrect. | If it's the first occasion, ask the customer to try again. If the CVV error recurs for the same customer, consider the potential for card fraud and advise them to contact their card issuer. |
| 2.08 | Invalid card number | The entered card number doesn't exist. | Ask the customer to verify and re-enter the card details or suggest using an alternative payment method. |
| 2.09 | Invalid expiration date | The transaction wasn't completed within the allocated time. | If the card has expired, ask the customer to update their card details or suggest a different card. As a merchant, you can verify the card expiration date in the order details within the Solidgate HUB. |
| 2.13 | Invalid IP | The provided IP address is incorrect. | Ensure a valid IP address is passed in the request. Double-check the IP address format and ensure it corresponds to the customer's actual IP. |
| 2.10 | Invalid 3DS flow on the merchant side | 3DS URL was not displayed to the cardholder during 3D Secure authentication attempts. | Ask the customer to describe the step-by-step payment flow they had and ensure all 3DS steps are displayed properly. |
| 2.11 | Invalid 3DS flow on the bank side | The bank did not complete 3DS authentication. | Ask the customer to try the payment again or suggest using another card. Ensure that the 3DS setup is properly configured and communicate any recurring issues with the bank. |
| 2.12 | Invalid 3DS flow | The customer hesitated during authentication. | Ask the customer to try again or suggest they use another card. Ensure the customer understands the importance of completing the 3DS authentication. |
| 2.15 | SCA requires 3D authentication | The transaction was attempted without 3DS, which is required for Strong Customer Authentication (SCA) in the EU. | Retry the transaction with 3DS enabled. Ensure your payment processing system supports 3DS for all applicable transactions to avoid unnecessary declines. |
| 2.14 | Subscription error | The customer already has an active subscription or multiple invoices in a processing state. | Verify the customer_account_id and ensure only one active subscription per product_id. Check for pending invoices, as some payment processors limit attempts to three per subscription. |
| 2.16 | Subscription is locked | A previous subscription order is still processing. | Wait until the previous attempt is resolved before retrying. To prevent lock issues, monitor ongoing subscription processes and handle retries correctly in your system. |
Soft card decline recovery levers
Intelligent payment routing
logic directs each transaction to the provider most likely to approve it, based on card type, geography, BIN range, and issuer behavior. Routing across multiple providers can lift approval rates by 5–10%. A decline on one provider can succeed on another – automates that fallback without the customer seeing a failure.
Smart retries
schedule retry attempts based on the decline type and the cardholder's likely payment behavior:
- After a paycheck date
- At a lower-fraud-signal time of day
- When the issuer's temporary flag has likely cleared
Timing improves first-retry conversion by 51–67%, but scheme limits define the boundary of how far you can push it.
allows up to 20 retry attempts per card within 30 days for retryable declines – fees apply from the 21st attempt onward. works differently: fees trigger when attempts on the same card exceed 10 within 24 hours or 35 within 30 days.
3DS and 3RI authentication
3D Secure (3DS) flow optimization prevents authentication-triggered soft declines. For subscription renewals, 3RI (3DS Requestor Initiated) authentication removes the cardholder challenge entirely. Standard 3DS can't render a challenge flow in Smart TV or in-app environments – 3RI handles the authentication on the merchant side instead.
Network tokenization (VTS/MDES)
replaces raw card numbers with network tokens that update automatically when a card is reissued or renewed.
reports a 4.6% authorization rate lift on tokenized card-not-present transactions. For subscriptions, this eliminates a class of soft declines that happen purely because stored credentials went stale before renewal.
Account updaters
work alongside network tokenization to catch credential changes that tokenization doesn't cover – cases where a cardholder gets a new card number rather than just a reissue of the same one. Both tools address the same underlying problem from different angles.
Pre-billing notifications
Pre-billing notifications sent 3–7 days before a renewal date reduce declines driven by insufficient funds and outdated payment details. Customers who know a charge is coming are more likely to top up their account or update their card before the attempt runs.
See how Hily combined smart retries with multi-provider routing to after moving off App Store billing.
Core insight: Soft decline recovery depends on timing, routing, and credential freshness. The merchants who recover 60–70% of soft-declined revenue are running retries on a schedule informed by issuer behavior, routing through multiple acquirers, and keeping credentials current through tokenization and account updaters.
Hard declines: Why they happen and what to do
Hard declines are permanent authorization failures. The payment method is invalid, the account is closed, or a fraud flag has been placed that won't clear. Retrying a hard decline wastes attempts, damages your relationship with the issuing bank, and can trigger scheme fines. It will not result in an approved transaction.
Hard declines account for 10–20% of all payment failures. Their recovery ceiling is lower – around 20–30% – and that recovery comes entirely from customer action: updating payment details, switching to an alternative payment method, or resolving an account issue with their bank.
Hard decline codes
| Code | Reason | Description | Solution |
| 4.04 | Lost card | The card was reported lost, and all transactions are blocked. | Show a generic decline message to avoid tipping off fraudsters. Internally, check the customer's account for fraudulent activity before allowing another attempt. |
| 4.02 | Stolen card | The card in use is stolen; all transactions are restricted. | Show a generic decline message to avoid tipping off fraudsters. Internally, check the customer's account for fraudulent activity before allowing another attempt. |
| 2.09 | Invalid expiration date | The entered or stored card expiration date is incorrect or has expired. | Ask the customer to enter a valid billing address. If mismatches persist, assess the fraud risk and take necessary action. |
| 4.03 | Restricted card | The card is listed on a security blacklist, often due to prior suspicions or fraud. | Contact the customer to confirm why payments stopped. If they didn't cancel, have them check with their bank. If the customer didn't initiate this action, advise them to check with their card issuer. |
| 4.01 | Card is in a blacklist | The acquiring bank blocked the transaction due to possible fraud. | Ask if the customer is aware of any restrictions. If not, suggest they contact their bank to resolve the issue. |
| 4.05 | PSP antifraud | The billing address provided by the customer doesn't match the bank's records. | Verify the settings and configurations to ensure they are correct. |
| 4.08 | AVS mismatch | The customer or issuer blocked recurring payments. | Double-check the merchant ID and ensure the account is active. |
| 3.11 | Recurring payment canceled | The customer has blocked transactions via this card, or their account is closed, and transactions are no longer allowed. | Use only supported API methods. If the error occurs on a zero-amount payment, your processor may not support that type of transaction. |
| 3.12 | Closed user account | Processing error. | Show a generic decline message to avoid tipping off fraudsters. Internally, check the customer's account for fraudulent activity before allowing another attempt. |
| 5.04 | Merchant is not configured correctly | Acquirer error. | Show a generic decline message to avoid tipping off fraudsters. Internally, check the customer's account for fraudulent activity before allowing another attempt. |
| 5.09 | Merchant not found | The selected API method isn't supported by the processor. | Ask the customer to enter a valid billing address. If mismatches persist, assess the fraud risk and take necessary action. |
| 5.10 | Processor does not support requested API method | The card is listed on a security blacklist, often due to prior suspicions or fraud. | Contact the customer to confirm why payments stopped. If they didn't cancel, have them check with their bank. If the customer didn't initiate this action, advise them to check with their card issuer. |
Hard card decline recovery levers
Card update prompts
Card update prompts catch expired or blocked cards before the next renewal attempt. Automated prompts via email, SMS, or in-app notification give customers a clear action – update now – rather than a confusing decline message they can't interpret.
Alternative payment methods
(APMs) give customers a fallback when their card is permanently unavailable. Offering PayPal, Apple Pay, Google Pay, or a relevant local method in the customer's market removes the friction of having to obtain a new card before resubscribing.
Local acquiring
addresses declines caused by regional issuer rules. When a pattern of declines traces to a specific geography, routing transactions through a local acquirer with established relationships in that market can reduce issuer-side friction on future charges.
Clear decline messaging
Clear decline messaging prevents abandonment. A vague "payment failed" message leaves customers unsure what to do. A specific, actionable message – "Your card has expired. Please update your payment details" – gives them a path forward.
Internally, check the customer's account for fraudulent activity before prompting a retry on lost or stolen card codes (4.04, 4.02) – never surface the reason to the customer to avoid tipping off potential fraudsters.
Merchant setup checks
(MID) settings, routing configurations, and compliance requirements all require periodic review. A misconfigured MID generates hard declines that look like issuer rejections but are fixable on your end.
Core insight: Hard decline recovery is a customer communication problem, not a retry problem. The 20–30% recovery ceiling is reached through timely prompts, clear messaging, and payment method alternatives – never by retrying the same declined card.
Soft vs hard declines compared
| Dimension | Soft decline | Hard decline |
| Definition | Temporary authorization failure on a valid card | Permanent authorization failure |
| Can be retried | Yes – with timing and routing logic | No – retrying risks fines and MID damage |
| Share of failures | 80–90% in subscription businesses | 10–20% |
| Recovery ceiling | 40–70% | 20–30% (via customer action only) |
| Primary recovery lever | Smart retries, routing, tokenization, account updater | Card update prompts, APM fallback, clear messaging |
| Scheme limits | Visa: up to 20 attempts / 30 days; Mastercard: fees above 10 attempts / 24 hours or 35 / 30 days; MAC 03 / MAC 21 = stop immediately | No retries – do not attempt |
| Decline type examples | Insufficient funds, authentication failure, temporary hold | Stolen card, closed account, invalid card number |
Core insight: The soft/hard split determines your entire recovery strategy. Getting it wrong in either direction – retrying a hard decline, or giving up on a soft one – costs revenue or damages your MID standing.
Why decline codes don't match across PSPs
Decline codes aren't standardized across payment providers or card schemes.
Card schemes built their own proprietary numbering, so the same underlying issuer decision arrives in a different format depending on which network processed it. Visa's N7 (Invalid CVV) maps to code 63 on Mastercard and "Security Code Invalid" on Amex. An expired card returns as code 6 on one provider and expired_card on another.
PSPs add a second translation layer on top. Each provider maps raw scheme codes to their own internal standards to simplify output for merchants. That works when you use a single provider – but add a second or third, and you're now reconciling two proprietary formats instead of one.
The result is that pattern analysis across your full transaction volume becomes a manual normalization exercise. Merchants processing at scale across multiple PSPs spend hours each week consolidating this data – and still miss recoverable declines that a unified view would surface immediately.
A payment orchestration platform solves this at the infrastructure level. maps all decline codes from payment schemes and major PSPs into one unified format, so every decline – regardless of which provider or scheme generated it – arrives with the same code structure. Cross-provider pattern analysis and consistent customer messaging become possible from a single integration.
Core insight: Decline codes don't match because schemes built their systems in isolation and PSPs added their own translation on top. A payment orchestration layer normalizes that fragmentation into one format – making recoverable declines visible across every provider in your stack.
How much revenue can you actually recover?
With a 50% recovery rate on soft declines – achievable with calibrated smart retries – a business running $180,000 in monthly exposure can potentially recover $90,000 of it. Pushing that rate to 70% with intelligent routing and network tokenization adds another $36,000. Hard declines contribute a further $9,000–$12,000 at a 20% recovery rate through card update prompts and APM fallback.
Each tool covered above recovers a slice of failed payments independently. is what sequences them into a system that runs on every failed payment automatically – so none of the recoverable revenue falls through the gaps between tools.
Core insight: How much you recover depends on which tools you have in place and how they're sequenced.
Card decline recovery metrics to monitor
Recovery strategy without measurement is guesswork. These four metrics tell you whether your efforts to reduce card decline rates are working.
Recovery rate measures the share of declined transactions that are subsequently approved. Track it separately for soft and hard declines – blending the two obscures which recovery lever is driving results.
Retry success rate shows how effective your retry logic is across attempts. A declining retry success rate per attempt signals retry timing is off, scheme limits are being approached, or the decline type mix has shifted toward harder-to-recover codes.
per PSP measures the share of approved transactions across your connected providers for equivalent transaction types. A persistent gap between two acquirers on the same card type and corridor points to a routing decision, not a cardholder issue.
Cost per recovered transaction tracks how much you spend recovering each failed payment – retry fees, notification costs, scheme charges for excess attempts – against the value of the recovered charge. This metric identifies when a retry sequence is recovering revenue at a cost that no longer justifies continuing it.
Core insight: Each of these metrics maps to a specific lever – dunning logic, routing rules, retry caps, or provider selection. Tracking them at the segment level (by PSP, card type, geography, decline code) is what makes the fix actionable.
Decline recovery is your growth strategy
Card decline recovery is a revenue lever, not a support function. The merchants who recover 60–70% of soft-declined revenue are running structured systems: retry logic calibrated to issuer behavior, multi-provider routing that finds the right rail per transaction, and credential management that prevents stale cards from triggering failures in the first place.
The and orchestration layer you run on determine how much of the recoverable ceiling you reach. Merchants on a single PSP with flat retry logic recover a fraction of what's available. Those operating across multiple providers with intelligent routing and network tokenization in place capture the rest.
Here's where to start:
- Use smart retry logic to recover soft declines at the right time
- Use network tokenization to prevent unnecessary declines due to expired or reissued cards
- Ensure 3DS and flows work for every payment surface – web, mobile, Smart TV
- Give customers fallback options via alternative payment methods
- Use to find the best provider per transaction
- Use account updaters and proactive prompts for expired or blocked cards
- Communicate with customers clearly and early when a decline is on their end
- If you run multiple PSPs, unify decline codes through a payment orchestration platform to make pattern analysis possible
If your authorization rates, retry success rates, or recovery ceilings are falling short, – we'll start with your current setup and identify where the gap is.
Frequently asked questions
A soft decline is a temporary authorization failure on a valid card. The payment method exists and belongs to the cardholder, but a short-term condition – insufficient funds, an authentication issue, or a network error – blocked the transaction. Soft declines are retryable and account for 80–90% of all subscription payment failures.
A hard decline is a permanent authorization failure. The payment method is invalid, the account is closed, or a fraud flag has been placed on the card. Retrying a hard decline will not produce an approval – it risks scheme fines and damage to your MID standing with issuing banks.
A soft decline is temporary – the card is valid, but something like insufficient funds, an authentication failure, or a network error blocked authorization, so a well-timed retry can recover it. A hard decline is permanent: the payment method is invalid or the merchant setup is wrong, and retrying it risks scheme fines and damage to your MID reputation with issuing banks.
Payment orchestration platforms are the most effective infrastructure for decline recovery at scale. They unify decline codes across PSPs, route each retry attempt to the acquirer most likely to approve it, and apply intelligent retry timing based on decline type and cardholder behavior. Solidgate's orchestration layer combines smart retries, multi-provider routing, network tokenization, and account updater in a single integration.
Visa allows up to 20 soft decline retry attempts per card within 30 days – the 21st attempt triggers a fee. Mastercard applies fees when attempts on the same card exceed 10 within 24 hours or 35 within 30 days. Any retry after a MAC 03 or MAC 21 response triggers a fee immediately, regardless of how many attempts have been made. Hard declines on both networks must never be retried.
Reducing soft declines requires action across three areas. First, keep credentials current with network tokenization and account updaters so stored cards don't go stale before renewal.
Second, optimize retry timing – retrying after a cardholder's pay date or at lower-fraud-signal times improves first-retry conversion by 51–67%.
Third, route retries through the provider most likely to approve the specific card type and geography. Pre-billing notifications 3–7 days before renewal also reduce the share of soft declines caused by insufficient funds.
A well-optimized subscription business typically runs an overall rate of 85–90%, with top-performing setups reaching 92–95%. Credit card decline rates above 10–15% usually point to a fixable problem – suboptimal routing, stale credentials, authentication configuration, or MID misalignment. Segment your decline rate by PSP, card type, geography, and decline code before drawing conclusions – the aggregate figure rarely identifies the cause.
