Credit Card Decline Codes: The Complete List for SaaS & Subscription Merchants
Every credit card decline code explained. Learn what each code means, whether to retry, and how to recover failed payments for your SaaS or subscription business.
Every failed payment is a revenue leak, and the difference between a recovered subscriber and a lost one often comes down to how well you understand decline codes. Across the subscription economy, 15 to 25% of recurring payments are declined, with “Do Not Honor” and “Insufficient Funds” alone accounting for roughly 76% of all declined transaction volume according to Visa’s Global Declines Transaction Analysis. For SaaS businesses, involuntary churn from payment failures represents 20 to 40% of total churn. This guide provides the complete technical reference: every major ISO 8583 decline code, how Visa and Mastercard categorise them, how Stripe, Braintree, Adyen, and Square map them, and the data-driven recovery strategies that can reclaim more than half of failed payments.
Key Takeaways
-
Code 05 “Do Not Honor” is the single highest-volume decline code, accounting for 30 to 40% of all declines. Adyen’s analysis shows roughly 50% of these are actually insufficient funds in disguise, and Visa’s network remaps suspected fraud (code 59) to code 05 before merchants ever see it.
-
The soft decline vs hard decline distinction is the most important thing to get right. Retrying a hard decline wastes money and triggers scheme penalties. Not retrying a soft decline leaves recoverable revenue on the table.
-
Card networks are aggressively tightening retry penalties. Visa charges $0.10 to $0.25 per excess retry on hard declines from the very first attempt. Mastercard’s fee hit $0.50 per violation in January 2025 and will expand further in January 2026.
-
Every processor translates ISO 8583 codes into its own taxonomy. Stripe exposes raw network codes, Braintree explicitly labels soft vs hard declines, Adyen uses ML to infer the real reason, and Square hides network codes entirely.
-
Recovery rates of 50 to 80% are achievable with a layered stack of ML-driven retries, dunning communications, card updater services, and network tokenisation.
The ISO 8583 Decline Code Taxonomy Every Developer Needs
ISO 8583 is the international standard for financial transaction messaging. When a card payment is declined, the issuing bank returns a two-character response code in Data Element 39 (DE 39) of the authorisation response message that identifies the reason. These codes form the foundation upon which every payment processor, card network, and retry engine operates, though interpretation varies by network, issuer, region, and processor.
The most critical distinction for subscription merchants is between hard declines (permanent failures that should never be retried with the same credentials), soft declines (temporary failures where retries can succeed), and data quality declines (failures requiring corrected information before retrying).
Hard Declines: Never Retry These Codes
Hard declines indicate permanent conditions. Retrying wastes resources, damages your authorisation rate metrics, and incurs scheme fees from Visa and Mastercard. Under Visa’s Category 1 classification, zero retries are permitted and every reattempt incurs $0.10 domestically or $0.15 to $0.25 cross-border from the very first retry.
| Code | Name | Explanation |
|---|---|---|
| 04 | Pick Up Card (No Fraud) | Card restricted or reported; issuer requests capture |
| 07 | Pick Up Card, Special Conditions | Fraud-flagged account; issuer requests capture |
| 12 | Invalid Transaction | Transaction type not supported by issuer for this card |
| 14 | Invalid Card Number | PAN fails Luhn check or does not exist in the issuer’s system |
| 15 | No Such Issuer | BIN does not correspond to any known issuer |
| 41 | Lost Card | Card reported lost by cardholder |
| 43 | Stolen Card | Card reported stolen |
| 46 | Closed Account | Account has been permanently closed |
| 57 | Transaction Not Permitted to Cardholder | Card blocked for this transaction type, channel, or MCC |
| R0 | Stop Payment Order | Cardholder placed stop payment on this specific merchant (Visa VSPS) |
| R1 | Revocation of Authorisation Order | Cardholder revoked authorisation for this merchant; cancel subscription immediately |
| R3 | Revocation of All Authorisations | Cardholder revoked all recurring authorisations on this card |
Codes 41 and 43 deserve special attention: never expose “lost” or “stolen” language to end users, as this could alert fraudsters. Present these as a generic decline. Codes R0, R1, and R3 are Visa-specific and critical for subscription billing. R1 and R3 mean the cardholder has explicitly revoked permission, and continued billing will trigger chargebacks and fines.
Soft Declines: Retryable With the Right Strategy
Soft declines represent temporary conditions. Smart retry logic can recover 20 to 40% of these failures, and they account for the vast majority of decline volume. These fall under Visa’s Categories 2 and 4, permitting up to 15 to 20 retries within a rolling 30-day window.
| Code | Name | Retryable | Practical Guidance |
|---|---|---|---|
| 01 | Refer to Card Issuer | Yes | Catch-all; cardholder should contact their bank |
| 02 | Refer to Issuer’s Special Conditions | Yes | Similar to 01; rare in modern e-commerce |
| 03 | Invalid Merchant | Yes | Merchant ID configuration issue; verify your setup with acquirer |
| 05 | Do Not Honor | Yes | The #1 decline by volume (~30 to 40% of all declines). Catch-all where the issuer gives no specific reason. May mask insufficient funds, fraud suspicion, or velocity limits |
| 06 | Error | Yes | General processing error; retry after a short delay |
| 13 | Invalid Amount | Conditional | Amount is zero, negative, or exceeds limits; retry with corrected amount |
| 19 | Re-enter Transaction | Yes | Temporary processing error; safe to retry immediately with a 2 to 5 second delay |
| 51 | Insufficient Funds | Yes | Most recoverable code for subscriptions. Retry in 1 to 3 days around payday cycles |
| 59 | Suspected Fraud | Conditional | Issuer fraud detection flagged the transaction; may succeed with 3DS authentication. Note: Visa remaps this to code 05 before the merchant sees it |
| 61 | Exceeds Withdrawal Amount Limit | Yes | Single-transaction limit; retry with a smaller amount or wait for the daily reset |
| 62 | Restricted Card | Conditional | Geographic or channel restrictions; reclassified from Category 1 to Category 2 in Visa’s April 2024 update, making it now retryable |
| 65 | Exceeds Withdrawal Frequency Limit | Yes | Too many transactions in the current time period; velocity counter usually resets daily |
| 75 | PIN Tries Exceeded | Yes | Rare in card-not-present environments; wait for counter reset |
| 78 | Card Not Activated / Blocked, First Used | Conditional | Card needs activation; reclassified from Category 1 to Category 2 in April 2024 |
| 91 | Issuer or Switch Inoperative | Yes | Most benign decline. Issuer system temporarily down; retry after 15 to 60 minutes |
| 93 | Transaction Cannot Be Completed (Violation of Law) | Conditional | Regulatory compliance issue; review before retrying. Also reclassified to Category 2 in April 2024 |
| 96 | System Malfunction | Yes | Generic system error at the issuer or network; retry after a short delay |
Code 05 warrants special emphasis because of its sheer volume. Adyen’s analysis reveals that in roughly half of cases, “Do Not Honor” is actually insufficient funds in disguise, as many issuers run legacy authorisation systems that default to 05 for anything they cannot categorise cleanly. Additionally, Visa’s network remaps all “59: Suspected Fraud” responses to “05: Do Not Honor” for legacy reasons, further inflating this code’s volume. See our deep dive into code 05 for the full technical breakdown.
Data Quality Declines: Correct and Retry
These require the cardholder to provide updated information before retrying. They are not retryable with the same data. Under Visa’s Category 3, the retry limits mirror Category 2, but only after correcting the underlying data issue.
| Code | Name | Action |
|---|---|---|
| 54 | Expired Card | Not retryable with the same data. Trigger an Account Updater query or send a dunning email requesting updated card details |
| 55 | Incorrect PIN | Retry only with the correct PIN; rare in card-not-present environments |
| 63 | Security Violation | CVV/CVC mismatch; the customer must re-enter their security code |
| 82 | CVV/CVC Mismatch | Security code does not match; request updated CVV from the cardholder |
| 1A | Additional Customer Authentication Required | Visa-specific; redirect to 3D Secure flow (common SCA trigger in Europe) |
| N7 | CVV2 Failure | CVV2 specifically does not match the issuer’s records |
Code 54 is particularly important for subscription businesses. While technically a “data quality” issue in Visa’s Category 3, it functions as a hard decline in practice because the card will never work again without updated credentials. This is where card updater services matter most: Visa reports that $8 billion in card-not-present declines stem from expired cards alone.
How Visa and Mastercard Categorise Decline Codes Differently
Visa and Mastercard each impose their own categorisation systems on top of ISO 8583 codes, with distinct retry rules and escalating penalties for violations. Understanding both is non-negotiable for subscription billing compliance.
Visa’s Four-Category Framework
Introduced in April 2020 with fees rolling out from April 2021, Visa groups all response codes into four categories. The system evaluates reattempts using Acquirer ID, Card Acceptor ID, Token/PAN, and transaction amount. Critically, Visa evaluates retries by credential type, so a token decline followed by a PAN retry does not count towards the retry limit.
Category 1 (Issuer Will Never Approve): Codes 04, 07, 12, 14, 15, 41, 43, 46, 57, R0, R1, R3. Zero retries permitted. Every reattempt incurs $0.10 domestically or $0.15 to $0.25 cross-border from the very first retry.
Category 2 (Issuer Cannot Approve Presently): Codes 03, 19, 39, 51, 52, 53, 59, 61, 62, 65, 75, 78, 86, 91, 93, 96, plus newer codes 5C, 9G, N3, N4, and Z5. Up to 15 to 20 retries in a rolling 30-day window (regional variation exists; staying under 15 ensures compliance everywhere).
Category 3 (Data Quality / Revalidate): Codes 54, 55, 82, N7, 1A, 6P, 63. Same retry limits as Category 2, but only after correcting the data issue.
Category 4 (Generic Response Codes): All codes not assigned to Categories 1 through 3. Same retry limits as Category 2. Visa actively penalises issuers who overuse Category 4 instead of providing more specific codes.
The April 2024 reclassifications shifted several codes: 62, 78, and 93 moved from Category 1 to Category 2 (now retryable); code 14 was removed from Category 3 tracking but remains firmly Category 1; and new code Z5 (“Valid Account but Amount Not Supported”) was introduced as Category 2.
Mastercard’s Merchant Advice Code System
Rather than numbered categories, Mastercard consolidates issuer responses into three umbrella decline codes (79 for Lifecycle, 82 for Policy, 83 for Fraud/Security) and appends Merchant Advice Codes (MACs) that dictate merchant action.
The MAC system is more prescriptive than Visa’s categories. MAC 03 (Do Not Try Again) and MAC 21 (Payment Cancellation) are absolute hard stops. MAC 01 (New Account Information Available) tells merchants to check Account Updater for updated credentials when paired with codes 79 or 82, or to retry using EMV 3DS when paired with code 83. MAC 02 permits a generic retry later.
Most innovatively, MACs 24 through 30 provide specific retry timing guidance: MAC 24 says retry after 1 hour, MAC 25 after 24 hours, MAC 26 after 2 days, and so on up to MAC 30 (retry after 10 days). Launched in October 2023 in the US as part of Mastercard’s Authorisation Optimizer, these primarily target insufficient funds declines on recurring card-not-present transactions. MACs 40 and 41 identify non-reloadable prepaid cards and single-use virtual card numbers, which are informational flags that tell subscription merchants these cards are unsuitable for recurring billing.
Penalty Escalation Is Accelerating
Mastercard’s fee structure has escalated aggressively: the excessive authorisation fee rose from $0.10 in 2022 to $0.50 per violation in January 2025. Mastercard enforces a 10-decline limit in 24 hours and 35 in 30 days on the same card/merchant combination. Starting January 2026, the MAC 03/21 fee will expand to apply to all declined card-not-present transactions bearing these codes, not just retries.
| Dimension | Visa | Mastercard |
|---|---|---|
| Hard decline limit | 0 retries | 0 retries (MAC 03/21) |
| Soft decline limit | 15 to 20 in 30 days | 10 in 24h / 35 in 30 days |
| Hard decline penalty | $0.10 to $0.25 per retry | $0.50 per excess attempt (Jan 2025) |
| Timed retry guidance | None | MACs 24 to 30 (1h to 10 days) |
| Account updater | Visa Account Updater (VAU) | Automatic Billing Updater (ABU) |
How Stripe, Braintree, Adyen, and Square Translate These Codes
Each processor wraps ISO 8583 codes in its own abstraction layer. For developers integrating multiple processors or migrating between them, understanding these mappings matters.
Stripe
Stripe returns a decline_code string (such as insufficient_funds, generic_decline, expired_card) alongside a raw outcome.network_decline_code containing the original ISO 8583 code. Since API version 2024-12-18, Stripe also exposes outcome.advice_code with values like try_again_later, do_not_try_again, and confirm_card_data, which are directly actionable for retry logic.
Key mappings: ISO 05 becomes generic_decline or do_not_honor; ISO 51 becomes insufficient_funds; ISO 41/43 become lost_card/stolen_card; ISO 91 becomes issuer_not_available. Stripe adds its own codes without ISO equivalents, including fraudulent (Stripe Radar block), merchant_blacklist, and authentication_required.
Braintree / PayPal
Braintree’s processor_response_code uses a 2000-series numbering system: 2000 for Do Not Honor, 2001 for Insufficient Funds, 2005 for Invalid Card Number, and so on. Uniquely, Braintree provides a processor_response_type field that explicitly classifies each decline as SoftDeclined or HardDeclined. This makes it the only major processor to provide a declarative soft/hard classification. Braintree also distinguishes gateway rejections (Braintree’s own fraud rules blocking the transaction) from processor declines (the issuing bank refusing it), which is architecturally important for debugging.
Adyen
Adyen returns a refusalReasonCode (numeric) and refusalReason (a descriptive string like “Not enough balance”, “Expired Card”, or “Blocked Card”). Notably, Adyen consolidates ISO 41 (Lost Card) and 43 (Stolen Card) into a single code 5 (“Blocked Card”), and its own fraud engine generates codes 20 (“FRAUD”) and 22 (“FRAUD-CANCELLED”) that have no ISO equivalent. Raw acquirer responses can be enabled separately in the Customer Area for merchants who need the underlying network codes. Adyen also offers an “Inferred Refusal Reason” feature that uses machine learning across its platform-wide data to identify the likely actual cause behind a generic decline.
Square
Square uses SCREAMING_SNAKE_CASE error codes such as GENERIC_DECLINE, INSUFFICIENT_FUNDS, and CARD_EXPIRED, but does not expose raw network codes. Square merges ISO 41 and 43 into a generic CARD_DECLINED without distinguishing lost from stolen cards. Developers on Square’s forums have noted that GENERIC_DECLINE is frequently returned even when more specific codes exist in the network response.
Cross-Processor Mapping for the Most Common Codes
| ISO 8583 | Meaning | Stripe | Braintree | Adyen | Square |
|---|---|---|---|---|---|
| 05 | Do Not Honor | generic_decline | 2000 | 2 (Refused) | GENERIC_DECLINE |
| 14 | Invalid Card Number | incorrect_number | 2005 | 8 (Invalid Card Number) | PAN_FAILURE |
| 41 | Lost Card | lost_card | 2012 | 5 (Blocked Card) | CARD_DECLINED |
| 43 | Stolen Card | stolen_card | 2013 | 5 (Blocked Card) | CARD_DECLINED |
| 51 | Insufficient Funds | insufficient_funds | 2001 | 12 (Not enough balance) | INSUFFICIENT_FUNDS |
| 54 | Expired Card | expired_card | 2004 | 6 (Expired Card) | CARD_EXPIRED |
| 57 | Not Permitted | not_permitted | 2015 | 23 (Transaction Not Permitted) | CARD_NOT_SUPPORTED |
| 61 | Exceeds Amount Limit | card_velocity_exceeded | 2002 | 28 (Withdrawal amount exceeded) | TRANSACTION_LIMIT |
| 91 | Issuer Unavailable | issuer_not_available | 3000 | 9 (Issuer Unavailable) | TEMPORARY_ERROR |
Only Stripe, Braintree, and Adyen expose the raw network decline code to merchants. For developers building retry logic, this is a critical distinction.
What the Data Says About Decline Rates and Their Causes
The scale of payment declines is larger than most SaaS operators realise. Card-present transactions see roughly 1% decline rates, but card-not-present e-commerce transactions average 10 to 15%, and recurring subscription billing climbs to 15 to 25% with some geographies and industries pushing much higher.
The Geography Problem Is Severe
Mastercard data reveals dramatic regional variation. USD transactions see 5% credit card decline rates, while EUR and CAD transactions hit 13%, GBP reaches 13% credit / 24% debit, and Latin American markets are far worse with Mexican peso transactions facing 75% credit card decline rates. Cross-border transactions carry a 15 to 25% higher failure rate than domestic, and international purchases account for only 11% of total card volume but represent 63% of card fraud. For SaaS businesses selling globally without local acquiring bank relationships, these cross-border premiums can push annual payment-related churn above 30%.
Decline Reasons Cluster Around Two Codes
Visa’s analysis confirms that codes 05 (“Do Not Honor”) and 51 (“Insufficient Funds”) together represent roughly 76% of all declined transaction volume globally. The prevalence of “Do Not Honor” varies sharply by region, sitting at about 10% of declines in the US but 34% in India. Adyen’s research found that in approximately half of cases, “Do Not Honor” is actually insufficient funds in disguise.
Expired cards account for 10 to 12% of declines and $8 billion in card-not-present declines annually. Fraud detection generates 15 to 20% of declines, but many are false positives, as merchants reject about 6% of e-commerce orders on fraud suspicion, of which 2 to 10% are legitimate. The broader false decline problem costs merchants an estimated $443 billion globally per year, representing 13 times more lost revenue than actual fraud.
Recurly’s analysis of 1,300+ subscription businesses confirms that four of the top five decline reasons are soft declines (generic decline, insufficient funds, temporary hold, and restricted card), with only “Invalid Card Number” being a hard decline among the most common reasons. This is good news for recovery, as 60 to 70% of all declines are potentially recoverable.
For SaaS Specifically, the Benchmarks Are Clear
Recurly Research data across 1,200+ subscription businesses shows 7.2% of subscribers are at risk each month from involuntary churn. B2B SaaS sees 7.5% monthly risk, while B2C sees 6.6%. Without decline management, SaaS companies face the highest potential subscriber loss rate of any industry after consumer services and media.
The median SaaS churn rate is 3.5% monthly (2.6% voluntary, 0.8% involuntary), and the average SaaS business loses approximately 9% of recurring revenue to failed payments annually. That effectively negates a full month of growth each year.
Recovery Strategies That Actually Work, Backed by Data
The good news: sophisticated recovery can reclaim the majority of failed payments. Recurly reports saving 72% of at-risk subscribers through recovery events, with those recovered subscribers continuing for a median of 141 additional days. That means 38% of a subscriber’s total lifetime occurs after a recovery event. The key is layering multiple tactics.
Smart Retries Are the First Line of Defence
Machine learning-based retry optimisation consistently outperforms static retry schedules. Stripe’s Adaptive Acceptance recovered $6 billion in falsely declined transactions in 2024 alone, a 60% year-on-year increase. Its new AI model achieves 70% greater precision in identifying legitimate false declines while reducing retry attempts by 35%. Recurly’s Intelligent Retries generate an average 7% lift in recovery rate (some customers see 16%), and Cleverbridge’s Dynamic Retries recover up to 10% more declined transactions than static approaches.
The optimal approach varies by decline type. For insufficient funds (the most recoverable soft decline), retry timing around payday cycles matters enormously: the first few days of the month for monthly pay cheques and the 14th for fortnightly pay. Mastercard’s MACs 24 through 30 now provide network-level retry timing guidance specifically for these cases. For issuer unavailable (code 91), retry after 15 to 60 minutes. For “Do Not Honor” (code 05), a backoff strategy with 3 to 4 retries over 7 to 14 days balances recovery probability against network retry limits. Stripe’s default configuration runs 8 retries within 2 weeks, while Recurly caps at 7 gateway declines, 20 total attempts, or 60 days.
Hard declines should never be retried with the same credentials. Stripe will not execute retries on hard decline codes even if scheduled. Instead, these should immediately trigger dunning communications.
Dunning Sequences Recover What Retries Cannot
Research from Churn Buster, with over a decade of optimisation data, reveals that roughly 50% of successful recovery comes from smart retry timing and 50% from effective customer communication. Neither alone is sufficient.
Best-performing dunning sequences follow a pattern: immediate notification on payment failure (Day 1), follow-up with a one-click card update link (Day 3 to 5), and account suspension warning (Day 7 onwards). Most SaaS companies send 3 to 5 dunning emails across 7 to 14 days. In-app payment walls that block feature access but preserve existing data can sharply boost recovery for hard declines. Multi-channel approaches combining email, SMS, and in-app notifications outperform email-only strategies.
Well-optimised dunning alone recovers 20 to 40% of failed payments. Combined with retries and account updater, the figure reaches 70 to 80%.
Card Updater Services and Network Tokens Prevent Declines Before They Happen
About 40% of cardholders replace their cards annually due to expiration, loss, fraud, or upgrades, and most never update payment details with merchants. Visa Account Updater (VAU) and Mastercard Automatic Billing Updater (ABU) enable merchants to automatically receive updated card credentials from issuers. Chargebee reports card updater services can recover up to 20% more invoices before a retry is even needed.
Network tokenisation goes further. Unlike gateway tokens that are locked to a single processor, network tokens issued by Visa Token Service (VTS) and Mastercard Digital Enablement Service (MDES) are recognised across the entire payments ecosystem, include automatic lifecycle updates when cards are reissued, and carry dynamic cryptograms that boost issuer trust. Visa reports a 4.6% approval rate uplift with network tokens; Mastercard reports 2.1%. Network tokens also deliver a 26% decrease in fraud incidents and qualify for interchange reductions, with Visa offering a 0.10% reduction on card-not-present consumer credit transactions. Both Visa and Mastercard are now imposing Non-Secure Scheme Fees on merchant-initiated transactions processed without network tokens, and global adoption is projected to reach 70% by 2027.
The Involuntary Churn Problem Is Larger Than Most SaaS Companies Measure
Involuntary churn, meaning subscriber loss from payment failures rather than conscious cancellation decisions, accounts for 20 to 40% of total churn across the subscription industry. Multiple independent sources (ProfitWell, Paddle, Baremetrics, Stripe) converge on this range. Stripe’s data shows 25% of lapsed subscriptions are purely due to payment failures, and subscriptions recovered through Stripe’s tools continue for an average of seven additional months.
The financial impact compounds rapidly. A $10M ARR company experiencing 13 to 15% involuntary churn faces $130,000 to $150,000 in preventable annual losses. The false decline problem is even larger: merchants lose an estimated $443 billion globally to legitimate transactions mistakenly rejected, costing 13 times more than actual fraud. After a decline, 35% of cardholders will abandon a merchant entirely, and 27% of customers cancel when notified of a failed payment.
SaaS companies have the highest past-due recovery rate of any industry at 53.5% according to Recurly benchmarks, suggesting that SaaS customers are more willing to resolve payment issues if merchants reach them quickly enough with the right tools.
Wrapping Up
The decline code ecosystem is more nuanced than a simple pass/fail signal. Visa and Mastercard are actively tightening retry compliance, with Mastercard’s excessive authorisation fee hitting $0.50 per violation in 2025 and expanding MAC 03/21 penalties in 2026, making code-level handling not just an optimisation but a compliance requirement. The most impactful technical investment for subscription businesses is a layered recovery stack: ML-driven retries respecting network-specific retry windows, immediate dunning triggered by hard declines, card updater services preventing credential-rot declines, and network tokenisation lifting baseline approval rates by 2 to 5%. The data consistently shows that 38% of a recovered subscriber’s total lifetime occurs after the recovery event. Every failed payment handled correctly is not just saving a transaction; it is preserving months of future revenue.
Sources
ISO 8583 Codes and Card Network Categorisation
- Checkout.com: Visa Response Code Categories: Complete Visa Category 1 through 4 code assignments including April 2024 reclassifications.
- Bill1st: Merchant Advice Codes & Response Codes: Full reference for Mastercard MACs 01 through 41 and their corresponding response codes.
- EBANX: ISO 8583 Response Codes: Full ISO 8583 code list with descriptions and recommended actions.
- Payway: Visa Excessive Reattempts Rule & Fees: Visa retry categories, fee structures, and compliance requirements.
- PayPal: Cost of (Un)Compliance with Card Networks: Visa and Mastercard retry penalty details and compliance guidance.
- Merchant Cost Consulting: Mastercard Transaction Processing Excellence Fees: Mastercard fee escalation timeline from $0.10 (2022) to $0.50 (2025).
- Braintree: Mastercard Network Updates F23: MAC 24 through 30 retry timing codes and Mastercard Authorisation Optimizer details.
Payment Processor Documentation
- Stripe: Decline Codes Reference: Complete list of Stripe decline codes and recommended handling.
- Braintree: Authorization Responses: Braintree processor response codes with soft/hard classification.
- Adyen: Refusal Reasons: Adyen refusal reason codes and inferred refusal reason feature.
- Adyen: Raw Acquirer Responses: How to access underlying network codes through Adyen.
Decline Rate Statistics and Revenue Impact
- Adyen Knowledge Hub: Do Not Honor: Analysis showing ~50% of “Do Not Honor” declines are actually insufficient funds; VisaNet remapping of code 59 to 05.
- ClearSale: Understanding the True Cost of False Declines: $443 billion in global false declines, from the report “Balancing False Declines and Fraud Prevention.”
- PYMNTS x FlexPay: Subscription Churn from Payment Declines: 27% of subscribers cancel or switch providers after a payment decline.
- CoinLaw: Card Decline Statistics 2025: Regional decline rate data including USD, EUR, GBP, and Latin American benchmarks.
- Chargebacks911: Credit Card Decline Rates: Decline rate benchmarks across card-present, card-not-present, and recurring billing.
- Recurly: Top Payment Decline Reasons for Subscription E-Commerce: Breakdown of decline reasons across 1,300+ subscription businesses.
- Recurly: Subscriber Retention Benchmarks: 7.2% monthly at-risk rate, 53.5% SaaS recovery rate, and 141-day median post-recovery lifetime.
Recovery Strategies and Platform Data
- Stripe Blog: AI Enhancements to Adaptive Acceptance: $6 billion recovered in 2024; 70% greater precision in false decline identification.
- Stripe: Smart Retries Documentation: Default retry configuration, hard decline handling, and recovery rate benchmarks.
- Stripe: Network Tokens and Card Account Updater: Network tokenisation approval rate uplift data and card updater pricing.
- Recurly: 2024 State of Subscriptions Report: $1.2 billion recovered in 2023; 72% of at-risk subscribers saved; 38% of total subscriber lifetime occurs post-recovery.
- Churn Buster: Recovery Methodology: 50/50 split between retry recovery and communication recovery; 21% of payments recovered through retries alone.
- Optimized Payments: Network Tokenization as a Strategic Advantage: Visa 4.6% and Mastercard 2.1% approval rate uplift; 26% fraud decrease; interchange reductions.