RecoverGuide
lost_card and stolen_card on Stripe: what to do, and what never to say
Last updated 13 August 2026 · written by Bruce McGinley, who builds RecoverFlow
The card was reported lost or stolen, and retrying is over. Stripe's decline codes reference documents lost_card as the payment being declined because the card is reported lost, and stolen_card as declined because the card is reported stolen.
Both are on Stripe's list of nine hard decline codes. Scheduled retries continue to exist on paper, but Stripe only executes a payment again once you obtain a new payment method.
And both carry an unusual documented next step aimed at you rather than the customer: the specific reason should not be reported to the customer. Present it as a generic_decline instead.
On this page
Why Stripe tells you to say nothing
For lost_card, Stripe's reference says the specific reason for the decline should not be reported to the customer, and that you should present it as a generic_decline. For stolen_card the instruction is the same: do not report more detailed information to your customer.
The logic is not hard to reconstruct. Whoever receives your email may be the legitimate cardholder who reported the card and forgot a subscription was attached to it. They may also not be. An email announcing that a card is flagged as stolen tells the wrong reader exactly what their situation is, so the documentation asks you to keep the reason generic.
In practice that means your dunning email for these codes reads like any other: the payment did not go through, here is a secure link to update the card. No reason named, no speculation.
What happens to retries
lost_card and stolen_card are both on the nine code list in Stripe's Smart Retries documentation. Stripe's wording is precise: for these failures the scheduled retries continue, but the payment only executes if you obtain a new payment method, and unexecuted retries do not create a new charge.
That produces the counter behaviour that trips up home built recovery logic: attempt_count on the invoice keeps climbing while nothing is actually being sent to the issuer. If your escalation logic branches on attempt count, branch on the decline code first. The webhook guide covers this trap in detail.
The only path back is a new payment method
Since no retry will execute, the recovery channel is the customer adding a card, which makes the email the whole game. One reason-blind message with an update link, and patience.
There is one passive channel worth knowing about: Stripe can update some saved card details automatically when issuers reissue cards, which is covered in our guide to automatic card updates. A lost or stolen card is precisely the scenario where the issuer prints a replacement, so it is worth understanding what that feature does and does not pick up before you assume the subscription is dead.
If you want to see how much of your own failed volume lands on these codes, the free decline code lookup flags the codes you should never name in an email, and our free backtest reads your last 90 days of failures and shows the split.
Questions people actually ask
Is lost_card a hard decline?
Yes. It is one of the nine decline codes in Stripe's Smart Retries documentation for which Stripe cannot automatically retry the payment. Scheduled retries continue but only execute after a new payment method is obtained.
Is stolen_card a hard decline?
Yes, in exactly the same way as lost_card. It is on the nine code list, so no retry executes until a new payment method exists.
Should I tell the customer their card was reported lost or stolen?
No. Stripe's decline codes reference is explicit for both codes: the specific reason should not be reported to the customer. Present it the same way you would a generic_decline, with a plain payment-failed message and a card update link.
Will Stripe keep retrying a lost_card or stolen_card decline?
Stripe keeps scheduling retries and attempt_count keeps incrementing, but per the Smart Retries documentation the payment only executes if you obtain a new payment method. Unexecuted retries do not create a new charge.
What is the difference between lost_card and stolen_card?
Only the report the cardholder made: lost versus stolen. Operationally they are identical. Both stop retry execution and both carry the documented instruction not to share the specific reason with the customer.
Where this came from
Checked against primary sources on 13 August 2026. If Stripe changes something and this page has not caught up, tell us and it gets fixed.
- Stripe: Decline codes reference — the documented meaning and next steps for every code on this page.
- Stripe: Smart Retries — the source for the nine hard decline codes and what happens to scheduled retries after one.
If you would rather not build this yourself
RecoverFlow watches your Stripe account for failed subscription payments, stops retrying the ones that cannot succeed, and emails the customers whose card simply needs replacing. It charges 25% of what it can attribute to a specific action it took, with a $29 monthly floor and a $299 monthly ceiling, and the floor is waived for the first 30 days.
It is early. It is run by one person. If Stripe's own free retry settings are enough for you, use those instead, and there is a page on this site that says exactly when that is the right call.
See how the pricing works