← Decline Codes
Hard Decline

Stripe Decline Code · Glossary

lost_card

lost_card is a hard decline fired when the customer's issuing bank has been notified that the physical card is lost — the card has been permanently flagged at the network level and will reject every future charge attempt regardless of timing, amount, or merchant.

Non-recoverable·10–20%·Updated May 2026

What It Means

What lost_card actually means.

lost_card is a hard decline fired when the customer's issuing bank has been notified that the physical card is lost — the card has been permanently flagged at the network level and will reject every future charge attempt regardless of timing, amount, or merchant. Critically, Stripe explicitly instructs merchants never to reveal this specific reason to the customer — you must present it as a generic decline, because the person attempting the transaction may not be the legitimate cardholder.

Not sure if this code is recoverable for your specific situation? Use the Stripe Failure Lookup →

Why It Happens

The root causes.

  • 1Cardholder reported the card missingThe customer contacted their bank and reported the card lost, triggering an immediate block across all card networks — any existing subscription using that card will fail on next billing cycle
  • 2Bank proactively flagged the cardThe issuer detected suspicious activity patterns and preemptively flagged the card as lost/compromised before the customer even noticed — common with modern fraud detection systems
  • 3Old card remained on file after replacementWhen a lost card is replaced, the bank issues a completely new card number, CVC, and expiry — but if the customer didn't update their Stripe payment method, the dead card remains on file and fails silently
  • 4Fraudster testing a stolen cardIn some cases, lost_card fires when someone is attempting to use a card that the legitimate owner has already reported missing — making this a dual-signal for both churn and potential fraud on your platform

What NOT to Do

Common mistakes that make it worse.

Never tell the customer their card was reported lost

This is Stripe's explicit official guidance — and it's not just a courtesy rule. If a fraudster is attempting to use the card, disclosing the lost_card status tips them off and could enable social engineering attacks. Always surface this as a generic payment failure to the person attempting the transaction.

Don't retry — not even once

lost_card is a permanent hard decline. The card is dead at the network level — no retry interval, no paycheck cycle logic, no "try one more time" automation will ever succeed. Every retry wastes an API call, adds a failed attempt to your merchant health record, and does exactly zero for recovery.

Don't treat it identically to expired_card

While both require a new payment method, expired_card is a predictable lifecycle event you can pre-empt. lost_card is sudden, unannounced, and has a fraud-signal dimension that expired_card never has. Your response workflow, email tone, and internal flagging logic must be completely separate for these two codes.

Retry Timing

Optimal retry schedule.

There is no retry timing for lost_card — this is a zero-retry, new-payment-method-only recovery path.

Recovery Benchmark

What good looks like.

MetricResult
Overall recovery rate10–20%
Recovery from legitimate customers (card replaced)30–40% of the recoverable subset
Recovery via alternate payment method offer+8–12% additional lift
Recovery with blind retries~0%
Non-recoverable (fraud attempts, true card loss)~60–70% of all occurrences
Median recovery window3–7 days if customer is legitimate

A 15–20% overall recovery rate on lost_card is realistically the ceiling — because a significant portion of occurrences involve either genuine card abandonment or fraud scenarios where the "customer" has no intention of updating a legitimate payment method. Focus your energy on speed of outreach and frictionless alternate payment method capture, not retry optimization.

At Scale

How to handle it at scale.

Automated

  • Webhook trigger: invoice.payment_failed → check failure_code === 'lost_card' → immediately route to a completely separate, isolated workflow from soft declines — zero retries, zero retry scheduler enrollment
  • Internal fraud risk tag: Auto-tag the account as high-risk-flag if it's a new customer (< 30 days) — lost_card on a brand-new account has significantly higher fraud probability than on a 12-month subscriber
  • Email Day 0 — neutral framing: Subject: "We couldn't process your payment — action needed" — generic language, no mention of lost card, direct CTA to payment update page. Show last 4 digits of the declined card so the legitimate customer immediately knows which card to replace
  • Block all retries at the automation layer: Add lost_card to your hard-decline blocklist in your retry engine (n8n, Zapier, custom dunning) — no retry node should ever fire for this code
  • Alternate method prompt — Day 5: Trigger a dedicated email offering multiple payment options — emphasize PayPal or bank transfer as zero-card alternatives for customers whose replacement card hasn't arrived yet
  • Stripe Account Updater: Enable this — in cases where a bank proactively reissues a card (not a customer-reported loss), Account Updater can sometimes silently update to the new card number before the failure compounds

Manual Escalation

  • New accounts with lost_card on first charge: Human review mandatory before any outreach — this is the strongest fraud signal combination in subscription billing; verify account identity before sending any email
  • High-ACV accounts: Personal outreach on Day 2 from a human, using neutral language — "We had an issue processing your latest payment and wanted to reach out directly" — a personal touch from a founder or CSM recovers 20–30% of legitimate high-value customers
  • Repeat lost_card pattern across multiple customers in short window: Alert your team immediately — this pattern can indicate a card data breach upstream (shared checkout, compromised integration) rather than individual losses
  • No-login customers: If a legitimate customer hasn't logged in within 30 days and their card shows lost_card, email + LinkedIn outreach before cancelling — they may simply be unaware their subscription is at risk

FAQs

Frequently asked questions.

What does the Stripe lost_card decline code mean?

The lost_card decline code means the customer's issuing bank has flagged the card as reported lost, permanently blocking all future charge attempts on that card number. It is a hard decline — no retry will ever succeed — and Stripe recommends never disclosing the specific lost_card reason to the customer, instead presenting it as a generic decline.

What are the most common causes of a lost_card error in Stripe?

The most common causes are: the customer reported their card lost to the bank and received a replacement with a new card number; the bank proactively flagged the card after detecting suspicious activity; or the old card remained on file in Stripe after the customer received a replacement card but forgot to update their payment method.

Should I tell my customer their card was reported lost?

No. Stripe's official guidance is to never disclose the lost_card reason to the person attempting the transaction. The person making the payment may not be the legitimate cardholder. Always present it as a generic payment failure and direct the customer to update their payment method.

Should I retry a payment after a Stripe lost_card decline?

Never. lost_card is a permanent hard decline — the card is blocked at the network level and every retry will fail with zero exception. Remove this code from all retry schedulers immediately and focus entirely on getting the customer to add a new payment method.

What is the recovery rate for Stripe lost_card failures?

Overall recovery rates for lost_card are 10–20%, significantly lower than soft declines. Among legitimate customers who simply need to update to their replacement card, 30–40% recovery is achievable with fast, neutral-toned outreach and an alternate payment method offer. A large portion of lost_card failures involve true card abandonment or fraud scenarios that are not recoverable.

Before you retry

Most lost_card failures are retried on the wrong schedule — which recovers the payment about 30% of the time. The other 70% leaves permanently. See what this code is actually costing at your MRR before deciding how to handle it.

See what lost_card costs me →

Stop leaving revenue on the table

lost_card can't be retried — but it can be caught earlier.

Recurflux handles code-specific retry scheduling, adaptive dunning, and dispute intelligence across all 30 Stripe decline codes. Connect in under 5 minutes.