Card decline codes explained: every reason a Stripe payment fails, and what to do about each

When a Stripe charge fails, the response includes a decline_code that tells you why. Most merchants treat all declines as identical — same retry timing, same dunning email, same outcome. That's wrong. Different decline codes have wildly different recovery rates, and the right action depends on the specific code.

This is the full reference, grouped by what to actually do about each.

The four categories

Every Stripe decline code falls into one of four recovery categories:

1. Retry-recoverable — the card is fine, the transaction failed transiently. A correctly-timed retry usually succeeds. 2. Dunning-recoverable — the card needs to be updated, but the customer relationship is intact. An email asking for a new card usually recovers them. 3. Hard declines — the card is permanently unusable. No retry will work. The customer can pay with a different card or churn. 4. Fraud signals — the issuer flagged the transaction as suspicious. Do not retry; you risk a chargeback that costs more than the original sale.

Retry-recoverable codes

These declines are transient. The card works; something about the specific moment didn't. Retry on the right schedule and most recover.

### insufficient_funds

The most common decline by volume. The customer has the card and uses it; they're just out of money in that account today.

• Best retry timing: within 48 hours of the customer's next paycheck. For W-2 employees, that's typically the 1st, 15th, or Friday.
• Median recovery rate: 75% with timing-optimized retries; ~30% with default Stripe Smart Retries.
• What not to do: Don't retry immediately. Don't retry daily. Both burn issuer goodwill and reduce future success rates.

### generic_decline / do_not_honor

The issuer declined the transaction but didn't say why. This is the second-most common decline category and the most maligned — most merchants treat it as a hard decline, but 40-60% are actually recoverable.

• Best retry timing: 24-72 hours later, ideally on a different day of the week than the original attempt.
• Median recovery rate: 45% with optimized retries.
• What it usually means: The issuer's fraud system flagged the transaction for a reason the issuer doesn't share. Most often: unusual transaction pattern, geographic mismatch, or amount different from typical spending.

### processing_error

A network-level error. Almost always transient.

• Best retry timing: within 1-4 hours.
• Median recovery rate: 85%.
• What to do: Retry quickly. This isn't a "save it for the right day" situation — it's a momentary outage.

### call_issuer

The issuer wants the customer to call them. Often a fraud-prevention flag.

• Best action: Send a dunning email asking the customer to contact their bank, then retry 3-5 days later.
• Median recovery rate: 30% with dunning + retry; 10% with retry alone.

Dunning-recoverable codes

These declines mean the card is dead or wrong. The customer needs to act. Retry won't help; a well-written email will.

### expired_card

The card's expiration date has passed. Common at month boundaries.

• Best action: Send a card-update email within 24 hours of the decline. Lead with the specific subscription/charge that failed. Provide a one-click update link.
• Median recovery rate: 60% with prompt email; 25% if you wait a week.

### incorrect_cvc / incorrect_number / invalid_expiry_*

The card details on file are wrong. Usually a fat-finger from initial signup.

• Best action: Email immediately. These are 70-80% recoverable if you ask.

### lost_card / stolen_card

Reported lost or stolen. The card is dead.

• Best action: Polite email asking the customer to update. Don't retry — you risk a chargeback.
• Median recovery rate: 40% if you email promptly and 0% if you keep retrying the dead card.

Hard declines

These declines mean the card is permanently bad. No action on your end recovers the original card. Either the customer provides a new card or they churn.

### closed_account

The customer closed the bank account.

### invalid_account

The account number is invalid (most often a typo at signup).

### pickup_card / restricted_card

The issuer has flagged the card and asked merchants to confiscate it.

• Best action for all three: One dunning email. If no update in 5-7 days, mark the customer as lost.
• Median recovery rate: 15-25%.

Fraud-signal codes

Do not retry. Each of these means the issuer believes the card is being used fraudulently.

• fraudulent
• merchant_blacklist
• reenter_transaction (in fraud contexts)
• pickup_card (when paired with fraud indicators)

Retrying these triggers a chargeback the issuer will side with. The chargeback fee ($15-$25) plus the lost transaction is usually 5-10x the value of the recovery attempt.

• Best action: Cancel the subscription immediately. Send a polite notice with a link to sign up again with a different card. Do not retry under any circumstances.

The decline codes most merchants never see

Stripe's decline_code is the cleaned-up, customer-friendly version. The underlying issuer response code (in the network_status and outcome objects) often carries more detail. Codes like 05, 51, 14, 54, and 91 from the issuer map to specific scenarios that change the optimal recovery strategy:

• 05 — Generic decline (often do_not_honor in Stripe's mapping).
• 14 — Invalid card number.
• 51 — Insufficient funds.
• 54 — Expired card.
• 91 — Issuer unavailable. Almost always retry-recoverable on a different network.

Omesta surfaces the underlying issuer code for every decline so you can build smarter retry logic.

The recovery hierarchy

For any failed charge, the decision tree is:

1. Is it a fraud code? Stop. Cancel. 2. Is it a hard decline? One dunning email, then move on. 3. Is the card invalid or expired? Dunning email with card-update link. No retry. 4. **Is it transient (insufficient_funds, generic_decline, processing_error, call_issuer)? Schedule a retry on the right day. 5. Did the retry succeed? Done. 6. Did it fail again?** Escalate through your dunning cadence.

How Omesta automates this

Omesta reads the decline code on every failed charge and routes the recovery automatically. Retry-recoverable codes hit our timing-optimized retry engine. Dunning-recoverable codes trigger a decline-specific email sequence with the right tone for the specific failure reason. Fraud codes are flagged and the customer marked dormant.

You see one dashboard with recovered dollars per decline category, so you know which leaks are worth more product effort.

Connect Stripe or see the leak scan.