Decline Code Cheat Sheet: 40+ Codes & Actions

Every failed payment comes back with a decline code, and that code — not a calendar — should decide what happens next. Retry the wrong code and you burn attempts on a card that can never pay. Refuse to retry the right code and you walk away from a subscriber who was never trying to leave. This is the reference version: the standard generic decline codes used across Stripe, Braintree, and similar processors, what each means, its hard or soft class, and the action that follows.

Two companions: Stripe decline codes explained covers where codes surface in a Stripe account, and hard declines vs. soft declines covers the classification logic in depth. This page is the fast lookup.

How to read this table

Class is the first decision. A soft decline is a temporary no: the card is a real, open payment method and the same card can succeed on a later attempt. A hard decline is a permanent no for that card as presented: only new payment details, or direct action by the customer with their bank, can move the subscription forward.

Action is one of three moves. Retry means another attempt on the same card, spaced so the underlying condition has time to change. Card update means stop spending retries and get the customer to a card-update page or their bank. Never retry means exactly that: further attempts are wasted at best, and at worst read as abuse to the issuer.

One piece of context. Across 5.4M failed payments analyzed by Churnkey from Stripe data, insufficient funds is the largest decline category at 40.6% — and it is soft, usually a timing problem rather than a lost customer. The biggest bucket in your queue is one of the most recoverable, provided you retry it around pay cycles instead of hammering it daily.

The decline code table

Code	What it means	Class	Action
insufficient_funds	The account does not hold enough money for this charge right now.	Soft	Retry spaced around likely paydays; send a dunning email in parallel.
do_not_honor	The issuer refused without giving a specific reason.	Soft	Retry a limited number of times, spaced out; if it repeats, ask for card update.
generic_decline	A catch-all refusal with no detail from the issuer.	Soft	Retry once or twice spaced; then route to card update.
try_again_later	The issuer asks you to attempt the charge again later.	Soft	Retry after a delay; do not retry immediately.
processing_error	A temporary error occurred while the charge was processed.	Soft	Retry after a short delay.
issuer_not_available	The card issuer could not be reached to approve the charge.	Soft	Retry after a delay, when the issuer is reachable again.
reenter_transaction	The issuer wants the transaction submitted again as-is.	Soft	Retry once after a short delay.
card_velocity_exceeded	The card has hit a limit on how often it can be used in a period.	Soft	Retry after the velocity window passes; space attempts wider.
withdrawal_count_limit_exceeded	The account has hit its withdrawal or transaction count limit.	Soft	Retry in a later period, or ask for a different card.
duplicate_transaction	The issuer believes an identical charge was just submitted.	Soft	Check the original attempt's status before retrying anything.
call_issuer	The issuer wants the cardholder to contact them about this charge.	Soft	Ask the customer to call their bank, then retry once they confirm.
approve_with_id	The charge can proceed if the cardholder provides identification.	Soft	Customer action first; retry after they complete it.
authentication_required	The issuer requires customer authentication, such as 3D Secure, before approving.	Soft	Send an authentication or card-update link; do not blind-retry.
no_action_taken	The issuer declined and took no action on the underlying account.	Soft	Retry spaced, limited attempts; then card update.
new_account_information_available	The issuer holds updated account details for this card.	Soft	Retry with network-updated card details if available.
partially_funded_card	The card is a prepaid or partially funded instrument with limited balance.	Soft	Retry later may work; ask for a standard card.
expired_card	The card's expiration date has passed.	Hard	Card update. Never retry the expired card.
incorrect_number	The card number entered is wrong.	Hard	Card update. Never retry the same number.
invalid_number	The card number is not a valid number.	Hard	Card update. Never retry.
incorrect_cvc	The security code does not match the card.	Hard	Card update with re-entered details. Never retry as-is.
invalid_cvc	The security code is malformed or unacceptable to the issuer.	Hard	Card update. Never retry as-is.
invalid_expiry_month	The expiration month on file is not valid.	Hard	Card update. Never retry.
invalid_expiry_year	The expiration year on file is not valid or has passed.	Hard	Card update. Never retry.
incorrect_amount	The amount submitted does not match what the issuer expects.	Hard	Fix the amount or invoice first; do not retry until corrected.
invalid_amount	The amount itself is invalid for this type of transaction.	Hard	Correct the charge setup; never retry the invalid amount.
invalid_account	The account behind the card is invalid or closed.	Hard	Card update. Never retry.
lost_card	The card was reported lost.	Hard	Card update. Never retry; a replacement card may already exist.
stolen_card	The card was reported stolen.	Hard	Card update. Never retry.
pickup_card	The issuer says retain the card — reported lost or stolen.	Hard	Card update. Never retry.
restricted_card	The card carries restrictions that block this type of charge.	Hard	Ask for a different card. Never retry.
fraudulent	The issuer flagged the transaction as suspected fraud.	Hard	Never retry. Contact the customer separately if the relationship is real.
merchant_blacklist	The payment method is blocked from use with your business.	Hard	Never retry that payment method; offer another way to pay.
security_violation	The issuer blocked the charge on security grounds.	Hard	Never retry as-is; the customer must resolve it with their issuer.
transaction_not_allowed	The issuer does not permit this kind of transaction on this card.	Hard	Card update with a different card. Never retry.
not_permitted	The transaction is not permitted for this cardholder or card.	Hard	Card update. Never retry.
service_not_allowed	The service or transaction type is not allowed on this account.	Hard	Card update. Never retry.
card_not_supported	The card type is not supported for this transaction.	Hard	Ask for a different card type. Never retry.
currency_not_supported	The card does not support the currency the charge was submitted in.	Hard	Charge in a supported currency or take a different card.
revocation_of_authorization	The cardholder revoked authorization for this recurring charge.	Hard	Never retry. Any return is the customer's decision, by re-subscribing.
revocation_of_all_authorizations	The cardholder revoked all recurring authorizations on the card.	Hard	Never retry. Stop all scheduled attempts on this card.
stop_payment_order	The cardholder placed a stop payment on this charge.	Hard	Never retry. Respect the stop; contact the customer only to understand why.
incorrect_pin	The PIN entered for a PIN-based transaction was wrong.	Hard	Customer must re-enter correct details. Never retry the same attempt.
invalid_pin	The PIN is invalid for this card.	Hard	Customer action required. Never retry as-is.
pin_try_exceeded	Too many incorrect PIN attempts; the PIN is now blocked.	Hard	Never retry until the customer unblocks it with their issuer.
offline_pin_required	The transaction requires an offline PIN that was not provided.	Hard	Never retry the same session; use a payment method that works online.
online_or_offline_pin_required	A PIN is required and was not supplied for this transaction.	Hard	Never retry as-is; route to a card that does not need a PIN.
test_mode_live_card	A real card was used against a test-mode setup, or the reverse.	Hard	Fix your configuration. Never retry until modes match.

Turning the table into a retry policy

Three rules turn this table into a working policy:

• Soft declines get spaced retries, not rapid ones. The condition behind a soft decline — an empty account, a busy issuer, a velocity window — changes with time. Attempts bunched into one day mostly re-test the same failing condition. Spread them across days, and bend the schedule around pay cycles for insufficient funds.
• Hard declines get zero retries and an immediate card-update ask. Every hour a hard decline sits in a retry queue is an hour the customer has not been told their card is dead. The email goes out when the failure lands, not after retries exhaust.
• Revocation and fraud codes end the sequence entirely. stop_payment_order, both revocation codes, and fraudulent are not recovery opportunities. Retrying them can create chargebacks, network penalties, and a customer who now actively distrusts you.

For the day-by-day version — which attempt lands on which day, for which class — see the retry schedule matrix.

Where Swipe Again fits

Swipe Again is failed-payment recovery software built for subscription businesses, and this table is effectively its rulebook. It classifies every failure by decline code, runs decline-code-aware smart retries — up to 6 attempts over ~16 days — for the soft codes, never retries the hard ones, and sends branded dunning emails and card-update pages for the failures only a customer can fix. It connects in about 2 minutes across Stripe, Recharge, Seal Subscriptions, Skio, Loop Subscriptions, Chargebee, Recurly, Braintree, and Paddle, and works a 90-day backfill of existing failed payments on connect. $179/mo flat — no percentage of recovered revenue, no MRR tiers — with a 14-day trial, card upfront.

The bottom line

Bookmark the table, but internalize the pattern: soft means retry with spacing, hard means ask for a new card immediately, revocation or fraud means stop entirely. Most recovery systems fail not because their emails are weak but because every code gets the same treatment. Classify first, and timing, messaging, and escalation mostly decide themselves.

Frequently asked questions

What is the difference between a hard decline and a soft decline?

A soft decline is a temporary refusal: the card is still valid and a later attempt can succeed, as with insufficient funds. A hard decline is permanent for that card as presented — expired, lost, stolen, or revoked — and only new payment details or action by the customer with their bank can fix it.

Which decline codes should you never retry?

Never retry revocation codes, stop payment orders, fraud flags, and cards reported lost or stolen — retrying them ignores an explicit instruction from the cardholder and can create chargebacks and network penalties. Expired and invalid cards also get zero retries and go straight to a card-update request.

How many times should you retry a soft decline?

A small number of attempts, spread across days rather than hours, spaced widely enough for the underlying condition to change. Spacing matters more than count: several attempts in one day usually re-test the same empty account or busy issuer.

Why is insufficient funds such an important code?

It is both the most common and one of the most fixable. In Churnkey's analysis of 5.4M failed payments from Stripe data, insufficient funds accounted for 40.6 percent of failures, and it is a soft decline — typically a timing problem around pay cycles, not a customer who wants to leave.

Do decline codes mean the same thing on every processor?

The generic codes in this table are used consistently across Stripe, Braintree, and similar systems, which is what makes a shared cheat sheet possible. Issuers can still be vague — do_not_honor deliberately says little — so treat borderline codes as soft with limited, spaced attempts, and route repeat failures to a card update.

Related reading: Fraudulent declines