lost_card: what this Stripe decline code means and why the customer usually already knows
lane: stoplost_cardThe payment was declined because the card is reported lost. Stripe's guidance is that the specific reason shouldn't be reported to the customer, and that it should be presented as a generic decline.
What it means
The issuer is relaying a report. The cardholder told their bank the card was lost, and from the moment of that report the credentials are dead: the number, date and code you hold belong to a card that no longer transacts. On the networks this is response code 41. It shares finality with expired_card and nothing else about its shape, because an expiry is printed on the card and knowable long in advance, while a loss report lands without warning in the middle of a billing cycle.
On a subscription the ordinary story is mundane. A wallet went missing, the bank was called, a replacement is on its way, and your saved card died as collateral nobody thought about. Stripe's automatic card updates exist for exactly this: where the issuer takes part, replacement details for cards reported lost or stolen are applied to the saved payment method on Stripe's side, and the subscription never notices. Where the issuer doesn't take part, the old details are finished and only the customer can supply new ones.
The complication is the other reading. A lost card is, by definition, a card whose location the owner can't vouch for, and a payment attempted on one can be the finder rather than the customer. That is why Stripe's instruction is to keep the reason out of the customer-facing message and present it as a generic decline: the two cases are indistinguishable from your side, and whatever you send has to survive both.
Why it happens
A lost wallet, reported
The cardholder called their bank, the bank deactivated the card, and every saved copy of it died at once. Yours was one of them.
A report made from caution
Cards get reported lost while sitting in a coat pocket. Issuers act on the report rather than on certainty, and the deactivation is just as final when the card turns up.
A replacement that hasn't reached you
A new card exists, and where the issuer takes part in the networks' update services, Stripe applies its details to the saved payment method on its own. Where it doesn't, nothing updates until the customer does it.
Someone else has the card
The other reading of the same report. A charge on a lost card can be whoever found it, which is part of why issuers deactivate first and why Stripe says not to explain the decline.
Common mistakes
Explaining the decline
Stripe's instruction is to present this as a generic decline. The cardholder who made the report gains nothing from being told what they already know, and a different reader gains confirmation that the card is flagged. Since you can't tell which one you are writing to, write the version that is safe for both.
Retrying the dead card
The report deactivated the credentials, and the issuer will not change its answer on a later attempt. Each retry is a payment pressed on a card the owner asked to be killed, and it returns nothing.
Automating the card-update request
The trade is worse than it looks. The email can't say why it was sent without breaching the disclosure guidance, so it arrives vague, and in the compromised case it asks whoever controls the account for a fresh card. Meanwhile the innocent case often heals on its own through Stripe's automatic updates. The upside is thin and the downside is aimed at the wrong person.
How Lirova handles it
Lirova stops on lost_card: no retry and no email. The stop set is our own judgement, and this is the member where the choice costs most, because the common story behind the code is an ordinary customer holding an ordinary replacement card. We stop anyway. A retry is a payment on credentials the cardholder asked their bank to kill, and it cannot succeed. The email the other lane would send can't state its reason without breaching Stripe's guidance, and in the uncommon case it asks the wrong person for another card. Stripe's automatic card updates quietly repair some of these with no action from anyone; the rest wait for the customer, or for a person on your side who has looked at the account.
FAQ
Should I retry a lost_card decline?
No. The report deactivated the card, and no later attempt changes the issuer's answer. The only future that works involves different card details, whether the customer supplies them or Stripe's automatic updates do.
Should I tell the customer their card was reported lost?
No. Stripe's instruction is to present it as a generic decline. The real cardholder already knows they reported it, so the detail adds nothing for them, and if the message reaches someone else it confirms the card is flagged.
What should I do when a good customer's card comes back as lost_card?
Nothing automated. If the customer gets in touch, the honest line is that their bank declined the charge and a quick word with the bank will explain why. Their replacement card resolves it, applied automatically where the issuer supports updates or entered by the customer where it doesn't.
What is the difference between lost_card and stolen_card?
The word in the cardholder's report. The mechanics on your side are identical: dead credentials, a don't-disclose instruction, a decline nothing retries past. The difference lies in what the report implies about the account and its past charges, which the stolen_card page covers.
Can Stripe update a card that was reported lost?
Yes, where the issuer participates. Stripe's automatic card updates cover cards replaced after being reported lost or stolen, applying the new details to the saved payment method and emitting a payment_method.automatically_updated event when they do.
Related codes
Updated 2026-09-01