Decline classification

Reflects the code as of 28 July 2026. If the product changes and this page does not, that is a bug worth emailing about.

Every failed payment is sorted into one of three buckets, and that decision drives everything downstream: whether a retry is scheduled, which email goes out, and what the backtest estimates you could recover.

Never retried: the nine Stripe will not execute

For these, Stripe keeps the retry schedule running and keeps incrementing attempt_count, but never sends the charge to the card network until a new payment method is attached. Scheduling our own retry against them would add delay and nothing else.

Decline code	Why we do not retry it
`incorrect_number`	The card number itself is wrong. No amount of waiting fixes a typo.
`lost_card`	The cardholder reported the card lost. The issuer will keep saying no.
`pickup_card`	The issuer wants the physical card retained. Treat it as permanently dead.
`stolen_card`	Reported stolen. Never tell the customer this is the reason.
`revocation_of_authorization`	The customer told their bank to stop this specific merchant.
`revocation_of_all_authorizations`	The customer told their bank to stop all recurring charges.
`authentication_required`	The charge needs SCA. Only the cardholder can complete it.
`highest_risk_level`	Stripe Radar blocked it. Retrying does not lower the risk score.
`transaction_not_allowed`	The issuer does not permit this type of transaction on this card.

This list is held in one place in the source and is checked against Stripe's Smart Retries documentation. It was last verified on 28 July 2026.

Not retried by choice

Four more codes are retryable as far as Stripe is concerned, but we do not retry them: fraudulent, merchant_blacklist, restricted_card and security_violation. The answer is settled, and repeatedly re-asking looks like card testing.

Retried

Everything temporary: insufficient_funds, processing_error, generic_decline, expired_card, incorrect_cvc, card_declined, try_again_later, do_not_honor, card_velocity_exceeded, and the invalid expiry codes.

Two of those need a caveat. expired_card and incorrect_cvc are classified as soft, but the scheduler returns no retry date for them, because the fix is new card details rather than another attempt. They go straight to the card-update path.

Unrecognised codes

A code we do not know is treated as recoverable rather than ignored. Stripe adds codes, and the failure mode of guessing wrong in that direction is a wasted retry. The failure mode of guessing wrong in the other direction is silently abandoning revenue.

Which declines trigger a card update

Bad card data (expired_card, incorrect_cvc, incorrect_number, the invalid expiry codes) and reissues (lost_card, stolen_card, pickup_card). Reissues matter more than they look: the customer usually already has the replacement card, so the fix costs them under a minute.

What we never put in an email: for lost, stolen and blocked cards, the reason is not named. Stripe's guidance is that a precise message is useful to whoever is holding a card they should not have. The email says the payment did not go through and asks for updated details.

Common questions

Which decline codes does RecoverFlow refuse to retry?

The nine Stripe will not execute without a new payment method (incorrect_number, lost_card, pickup_card, stolen_card, revocation_of_authorization, revocation_of_all_authorizations, authentication_required, highest_risk_level, transaction_not_allowed), plus fraudulent, merchant_blacklist, restricted_card and security_violation, which we choose not to retry.

Does RecoverFlow retry insufficient_funds?

Yes. It is a temporary condition and one of the better codes to retry, so it gets its own schedule aimed at the 1st and 15th of the month.

What happens with a decline code RecoverFlow does not recognise?

It is treated as recoverable and retried on the default schedule. Abandoning revenue because Stripe added a code we had not seen would be the worse mistake.

Is expired_card retried?

No retry is scheduled for it, even though it is classified as a soft decline. An expired card needs new details, not another attempt, so it goes to the card-update path instead.