Every Stripe decline code explained. Learn what each code means for your SaaS revenue, why payments fail, and proven recovery tactics to reduce involuntary churn.
The customer's card does not have enough available balance to cover the charge. This is the most common decline code for SaaS subscription renewals and often resolves itself within a few days when the customer replenishes their account.
The customer's card has passed its expiration date and the issuing bank will no longer authorize transactions on it. This is a predictable decline that SaaS businesses can proactively prevent by monitoring card expiration dates and prompting customers to update their payment details before renewal.
The card verification code (CVC/CVV) provided does not match what the issuing bank has on file. This typically occurs during initial card entry rather than recurring charges, since CVC is not stored for subscriptions. For SaaS businesses, this usually means a customer mistyped their security code at checkout.
A generic decline where the issuing bank has refused the transaction without providing a specific reason. This is a catch-all code that banks use when they do not want to disclose the exact cause. For SaaS businesses, this is frustrating because it offers limited actionable information.
The card number entered does not correspond to a valid card. This is a checkout-time error that prevents the initial transaction from being created. For SaaS businesses, this means a potential customer could not complete their signup or payment update.
The ZIP or postal code provided does not match the billing address on file with the card issuer. AVS (Address Verification System) checks flag this mismatch. For SaaS businesses, this can indicate a customer moved or made a typo in their billing address.
The expiration month provided is not a valid value (must be 01-12). This is a data entry error that occurs at checkout when a customer enters an impossible month value. SaaS businesses should catch this client-side before it reaches Stripe.
The expiration year provided is not valid, typically because it is in the past or an unrealistic future date. This checkout-time error indicates the customer entered incorrect expiration details. SaaS businesses should validate expiry dates client-side.
The CVC value provided is not in a valid format (wrong number of digits or non-numeric characters). Unlike incorrect_cvc which means the value did not match, invalid_cvc means the format itself is wrong. SaaS businesses should validate CVC format client-side.
The card number is not a valid credit card number, typically failing the Luhn algorithm check or having an incorrect length. This is a checkout-time error that should be caught by client-side validation. SaaS businesses using Stripe Elements will rarely see this.
The card does not support the type of transaction being attempted. This can happen when a card is not enabled for e-commerce, international, or recurring transactions. SaaS businesses may see this with prepaid cards or cards from certain regions.
The card does not support the currency in which the charge was attempted. Some cards are restricted to their home currency or a limited set of currencies. SaaS businesses serving international customers may encounter this when billing in a single currency.
The customer's bank has declined the transaction without specifying a reason. This is one of the most common and frustrating decline codes because it provides no specific cause. For SaaS businesses, this often requires direct customer communication to resolve.
The card issuing bank could not be reached to authorize the transaction. This is typically a temporary network or system issue on the bank's side. SaaS businesses should retry these transactions as they usually succeed once the issuer is back online.
The card has been replaced with a new one and the bank is indicating that updated account information is available. This often happens when a bank proactively reissues a card. SaaS businesses should use Stripe's automatic card updater to fetch the new details.
The bank did not process the transaction and took no action. This vague response typically means the bank's systems did not fully process the authorization request. For SaaS businesses, this is similar to a do_not_honor and should be retried.
The bank does not allow this type of transaction on the card. This can mean the card is restricted from certain merchant categories, online purchases, or international transactions. SaaS businesses should guide the customer to contact their bank or use a different card.
The issuing bank has returned a temporary error and suggests retrying the transaction later. This is an explicitly retryable decline that usually resolves within hours. SaaS businesses should have automated retry logic to handle this seamlessly.
The customer has exceeded the maximum number of transactions or withdrawal attempts allowed by their bank in a given period. This is common with debit cards that have daily transaction limits. SaaS businesses should retry on the next business day.
The bank is requesting that the cardholder call them directly to authorize or resolve an issue with the transaction. This is a deliberate block that requires customer action. SaaS businesses need to communicate this clearly to the customer.
Similar to call_issuer, the bank is asking the cardholder to contact them about this transaction. The distinction is subtle but generally indicates a less urgent issue. SaaS businesses should treat this the same as call_issuer.
The bank would approve the transaction if the cardholder presented identification. Since this is not possible for online transactions, the bank is effectively declining. SaaS businesses should retry or ask the customer to contact their bank to pre-approve.
The issuing bank suspects the transaction is fraudulent and has declined it to protect the cardholder. This is a serious flag that indicates either genuine fraud or an overly sensitive fraud detection system. SaaS businesses should not retry these without customer verification.
The cardholder has reported this card as lost. The bank has deactivated the card and will decline all future transactions. SaaS businesses should stop retrying immediately and contact the customer to provide a new payment method.
The cardholder has reported this card as stolen. All transactions on this card will be declined permanently. SaaS businesses should stop retrying and flag this account for review, as the person who signed up may not be the cardholder.
The bank is requesting that the card be physically confiscated, typically because it has been reported as lost, stolen, or is being used fraudulently. For online transactions, this translates to a hard decline. SaaS businesses should treat this as a permanent block.
The card has been restricted by the issuing bank and cannot be used for this transaction. This can be due to fraud concerns, account standing issues, or geographic restrictions. SaaS businesses should not retry and should contact the customer.
The bank has flagged a security violation on this transaction or card. This is a serious fraud indicator suggesting the card or transaction has been compromised. SaaS businesses should stop retries and review the account carefully.
The card was declined because the cardholder has specifically requested their bank to block charges from your business, or Stripe's own fraud systems flagged the transaction. This is a strong signal that the customer does not want to be charged.
The cardholder has instructed their bank to revoke all authorizations and block all future transactions on this card. This is a definitive action by the customer and means the card is permanently blocked. SaaS businesses should respect this decision.
A generic error occurred while processing the transaction. This is usually a temporary issue in the payment network, not related to the customer's card or account. SaaS businesses should retry as these typically resolve quickly.
The bank detected this as a duplicate of a recent transaction and declined it to protect the cardholder from being charged twice. This can happen when your system sends the same charge request multiple times. SaaS businesses should verify their billing logic.
The charge amount is not valid, either because it is negative, zero, exceeds the card's single-transaction limit, or is not in the correct format for the currency. SaaS businesses should verify their pricing and billing calculation logic.
The bank is requesting that the transaction be submitted again. This is similar to try_again_later but specifically suggests resubmitting the same transaction. SaaS businesses can safely retry this charge.
The bank declined the transaction without providing any specific reason. This is the most common decline code and acts as a catch-all when the bank does not categorize the decline. SaaS businesses need robust dunning flows to handle these effectively.
A test mode card number was used in a live mode transaction, or vice versa. This is a development error, not a customer issue. SaaS businesses should ensure their environment configuration separates test and live API keys.
A Stripe test card number was used in live mode. This happens when developers or testers accidentally use test card numbers against the live API. It can also occur when a customer enters a test card number they found online.
Too many transactions have been attempted on this card in a short period, exceeding the bank's velocity limits. This can be triggered by your retry logic or by the customer using the card at many merchants. SaaS businesses should space out retry attempts.
The bank requires the cardholder to complete 3D Secure (3DS) authentication before the transaction can be approved. This is increasingly common due to Strong Customer Authentication (SCA) regulations in Europe and other regions.
The card requires an offline PIN for authorization, which is not possible for online transactions. This typically occurs with certain debit cards, especially in European markets. SaaS businesses should suggest an alternative card.
The card requires either an online or offline PIN for verification. For e-commerce, the online PIN option may be satisfied through 3D Secure. SaaS businesses should implement 3D Secure or ask the customer to use a different card.
The maximum number of PIN entry attempts has been exceeded for this card. The card is now temporarily or permanently locked until the cardholder contacts their bank. For online SaaS businesses, this means someone previously failed PIN verification at a physical terminal.
The cardholder has specifically revoked authorization for this charge or merchant. Unlike the blanket revocation_of_all_authorizations, this targets a specific transaction or recurring agreement. SaaS businesses should stop charging and reach out to the customer.
The card or account is not permitted to use this type of service or make this type of transaction. This is similar to not_permitted but specifically relates to the service category. SaaS businesses may see this with cards restricted from online subscriptions.
The card number does not correspond to a valid account. This can mean the account has been closed, was never opened, or the card number is wrong. SaaS businesses should ask the customer to verify their card details or use a different card.
The bank does not allow this specific transaction on the account. This is an account-level restriction that may be related to the transaction type, amount, or merchant category. SaaS businesses should ask the customer to contact their bank.
The PIN entered was incorrect. While this is primarily a point-of-sale decline code, it can appear in online transactions for certain card types that require online PIN verification. SaaS businesses rarely encounter this for standard e-commerce.
The account associated with this card has been permanently closed by the bank or customer. No further transactions will be authorized. SaaS businesses must obtain a new payment method to continue billing.
The debit transaction was not authorized by the cardholder or account holder. This typically appears for ACH or debit card transactions where the bank requires explicit prior authorization. SaaS businesses should verify the customer agreed to the charge.
The bank account linked to the payment method has been closed. This is similar to card_account_closed but may apply more broadly to bank accounts used for ACH or direct debit. SaaS businesses need to collect a new payment method.
Get a free churn health report. Find pending cancellations, failed payments, and expiring cards putting your MRR at risk.
Run Free Audit