blog.post12Title

Why Stripe Decline Codes Matter for Your Business

Stripe is the most widely used payment processor for SaaS and subscription businesses, processing hundreds of billions of dollars in transactions annually. Despite its reliability, 5% to 10% of recurring Stripe charges fail each billing cycle. When these failures occur, Stripe returns a decline code that explains why the payment was rejected. Understanding these codes is not just a technical exercise. It is the foundation of effective payment recovery. Each decline code tells you something specific about why the payment failed, and more importantly, what you should do next. A payment declined for "insufficient_funds" calls for a different response than one declined for "expired_card" or "fraudulent." Yet the majority of subscription businesses treat all Stripe failures identically, retrying them on the same fixed schedule regardless of the underlying cause. This one-size-fits-all approach recovers only 10% to 15% of failed payments. Companies that classify Stripe decline codes and route each to an optimized recovery workflow achieve recovery rates of 50% to 65%, representing tens of thousands of dollars in additional monthly revenue for mid-market SaaS businesses.

Stripe Soft Decline Codes: Temporary Failures You Can Retry

Soft declines are temporary conditions that may resolve with properly timed retries. They represent your highest-opportunity recovery targets with Stripe. The "insufficient_funds" code is the most common Stripe decline, accounting for roughly 40% of all payment failures. The cardholder's account does not have enough money to cover the charge right now, but it may have funds tomorrow or on the next payday. Recovery strategy: retry with payday-aware timing. In the US, retries on the 1st and 15th of the month succeed 40% more often than retries on random dates. The "processing_error" code indicates a temporary issue within Stripe's or the issuing bank's systems. These are purely transient and can be retried within 15 to 60 minutes. Recovery rates for processing errors exceed 85% with prompt retries. The "card_velocity_exceeded" code means the card has hit a transaction limit set by the issuer. Wait at least 24 hours before retrying. The "issuer_not_available" code means the cardholder's bank is temporarily unreachable. Retry after one to four hours. For all Stripe soft declines, the key is timing your retries to match when conditions are most likely to have changed. LostChurn's smart retry engine analyzes historical patterns to determine the optimal retry moment for each specific decline code and customer profile. Browse all 52 Stripe decline codes in our decline codes reference.

Stripe Hard Decline Codes: When Customer Action Is Required

Hard declines indicate a permanent problem with the payment method that will never resolve through retrying. Attempting to retry hard declines wastes processing resources and can damage your reputation with Stripe and the card networks. The "stolen_card" and "lost_card" codes mean the cardholder has reported the card as stolen or lost. Do not retry under any circumstances. Contact the customer immediately to collect a new payment method. The "card_not_supported" code means the card type is not accepted by the merchant account configuration. This requires either the customer to use a different card or a configuration change on your end. The "merchant_blacklist" code (also called "pickup_card") means the issuer has flagged the card for the specific merchant. The customer needs to contact their bank or use a different card. For all hard declines, the correct response is immediate dunning outreach. Speed matters enormously: customers contacted within four hours of a hard decline update their payment method 70% of the time. After 24 hours, that rate drops to 25%. After seven days, it falls below 10%. Your dunning email for hard declines should clearly explain that the current card cannot be charged, provide a secure one-click link to enter a new card, and reassure the customer that their account is safe during the grace period.

Card-Update Decline Codes: The Predictable Failures

Card-update declines are the most preventable category because they involve information known in advance. The "expired_card" code is entirely predictable. Every card has a printed expiration date. If you are not monitoring card expiry dates and sending proactive update reminders before the expiration, you are leaving money on the table. Best practice is to send reminders at 14, 7, and 3 days before expiry, reducing card-expiry failures by 45%. Stripe's "invalid_number" code often occurs after a bank reissues a card with a new number, typically due to a data breach or routine replacement. Stripe supports automatic card updates through its integration with Visa Account Updater and Mastercard Automatic Billing Updater. Enabling this feature in your Stripe dashboard automatically refreshes stored card numbers when banks reissue cards, recovering payments with zero customer friction. The "invalid_cvc" code indicates that stored payment data has become stale. Card-update declines have the highest recovery potential of any decline category when handled promptly. Customers asked to update their card within 24 hours of an expiry-related decline recover at rates above 60%. Our card expiry alerts feature automates this entire workflow, combining pre-expiry reminders with post-failure dunning to maximize recovery.

Stripe-Specific Decline Codes You Should Know

Beyond the common categories, Stripe has several unique decline codes worth understanding. The "do_not_honor" code is one of the most frustrating because it is deliberately vague. The issuing bank has declined the transaction but has not provided a specific reason. This code can indicate anything from a temporary fraud hold to a permanent account restriction. Treat "do_not_honor" as an ambiguous decline: use a conservative retry schedule (retry after 24 hours, then 3 days, then 7 days) while simultaneously sending a dunning email, since customer outreach may be needed. The "generic_decline" code is similarly vague and should be handled the same way. The "try_again_later" code is a clear soft decline indicating temporary issuer issues. Retry after one to four hours. The "testmode_decline" code appears only in Stripe's test environment and indicates you are using a test card number. If this appears in production, it means your Stripe integration is misconfigured. The "approve_with_id" code is unusual: the issuer approved the transaction but requires additional identification from the cardholder. This typically occurs for high-value transactions or new merchants. Contact the customer to verify the charge through their bank. Understanding these Stripe-specific codes allows you to fine-tune your recovery strategy beyond the broad soft, hard, and card-update categories.

How Stripe Radar and 3D Secure Affect Decline Rates

Stripe Radar, the built-in fraud detection system, can block legitimate transactions, increasing your decline rate. Radar uses machine learning to score every transaction for fraud risk, and transactions above a configurable threshold are blocked before they reach the card network. While Radar prevents fraud, overly aggressive settings can create false positives that appear as "fraudulent" decline codes. Review your Radar rules periodically and consider adjusting the threshold if you see a high rate of fraud-related declines on customers you know are legitimate. 3D Secure (3DS) adds another layer of complexity. When 3DS authentication is required and the customer fails to complete it, Stripe returns an "authentication_required" decline code. This is increasingly common in regions with Strong Customer Authentication (SCA) requirements, particularly Europe under PSD2. The best approach for 3DS-related declines is to send the customer a dunning email with a link to complete the authentication process, rather than simply retrying the charge. Some issuers will decline repeated charges that have not completed 3DS, so retrying without authentication is counterproductive.

Building a Stripe Recovery Strategy

An effective Stripe recovery strategy combines everything above into a coordinated system. Step one: classify every decline. Map each of Stripe's 52 decline codes to one of four categories: soft decline (smart retry), hard decline (immediate outreach), card update (customer action), or ambiguous (conservative retry plus outreach). Step two: configure optimized retry timing for each category. Soft declines get payday-aware retries with time-of-day optimization. Hard declines get zero retries and immediate dunning. Card-update declines get one retry (in case Stripe's automatic card updater resolves it) followed by dunning if it does not. Ambiguous declines get a conservative three-retry schedule over 10 days. Step three: design your dunning email sequence following the three-email framework. Customize messaging for each decline category. For hard declines, be direct about needing a new card. For soft declines, let the customer know you are retrying and they may not need to do anything. Step four: coordinate retries and emails so they do not conflict. Suppress dunning when a retry is imminent. Cancel the sequence when recovery succeeds. Step five: monitor and iterate. Track recovery rate, time to recovery, email engagement, and retry efficiency by decline code. Adjust timing and messaging based on what the data shows. LostChurn automates all five steps for Stripe merchants. Connect your Stripe account in under two minutes and start recovering failed payments with AI-optimized timing and personalized dunning. See our Stripe integration page for setup details.