stolen_card: what this Stripe decline code means and why it points backwards too
lane: stopstolen_cardThe payment was declined because the card is reported stolen. Stripe's guidance is not to report more detailed information to the customer, and to present it in the same manner as a generic decline.
What it means
The issuer is relaying a theft report. The cardholder told their bank the card was stolen, the bank deactivated it, and the credentials you hold stopped working at that moment. On the networks this is response code 43, one digit along from the lost-card report, and the machinery is identical: dead details, a decline that repeats forever, an instruction from Stripe not to name the reason. What changes with the word stolen is everything around the decline.
There are two stories, and the decline doesn't say which one you are in. In the first, your customer is a victim: a card skimmed, taken or exposed in a breach, then reported and replaced, and your renewal failed as a side effect. In the second, the card was stolen before you ever saw it, the subscription was funded with it from the start, and this decline is the first honest thing that account has told you. The second story is the one that reaches backwards. Charges you already collected on that card were made against a cardholder who didn't agree to them, and cardholders who report theft tend to review their statements.
The disclosure rule has a sharper edge here than on lost_card. If the person your message reaches is the one who took the card, the word stolen tells them the window has closed and which merchant noticed. Stripe's instruction is the same as for the neighbouring codes: keep the detail out and present a generic decline.
Why it happens
A theft, reported
Physical theft, a skimmer, a breach that exposed the number. The cardholder reported it, the issuer deactivated the card, and every merchant holding those details got the same dead credentials at once.
Misuse noticed first
Stolen reports often follow the cardholder spotting charges they didn't make. By the time the code reaches you, the issuer may already be unwinding other merchants' transactions on the same card.
The subscription was funded with it
The harder reading. The card was stolen goods before it reached your checkout, and the account it pays for was never a customer. The decline is the report catching up with your records.
A replacement in flight
As with lost cards, where the issuer takes part in the networks' update services, Stripe applies the replacement card's details to the saved payment method on its own. The innocent version of this decline sometimes resolves without anyone acting.
Common mistakes
Putting the word stolen in front of anyone
Stripe says to present this as a generic decline, and the reason bites harder here than anywhere. To the victim the detail is old news. To the thief it is operational feedback. No message you could send needs the word.
Retrying it
The credentials are deactivated and the answer is permanent. Worse, in the second story every retry is you pressing a charge on a card you have been told was stolen. There is no version of this where the attempt helps.
Not looking backwards
lost_card is mostly about the next payment; stolen_card is also about the previous ones. Check what that card paid for, when the account appeared and whether disputes or early fraud warnings are arriving. If the story is innocent the check costs little, and if it isn't, you want to know before the disputes tell you.
How Lirova handles it
Lirova stops on stolen_card: no retry and no email. The stop set is our judgement rather than a rule, and this member has the least ambiguous reasoning of the three. A retry presses a charge on a card reported stolen and cannot succeed. An email can't explain itself without breaking the disclosure guidance, and in the second story it is addressed to the person who caused the decline. And because this code can mean the account was never real, the automation's job is to add nothing to the relationship until someone has looked at it. The stop leaves the guessing to a person.
FAQ
Should I retry a stolen_card decline?
No. The card was deactivated when the theft was reported, and the issuer's answer will not change. If the customer is legitimate, recovery runs through a replacement card; if the account was funded with the stolen card, recovery is not the goal.
Should I tell the customer their card was reported stolen?
No. Stripe's instruction is to present it as a generic decline. The real cardholder already knows, and any other reader learns something useful to them and harmful to the cardholder from the word stolen.
Does a stolen_card decline mean my customer is a fraudster?
Usually the opposite: most of these are victims whose card was cancelled out from under a legitimate subscription. But unlike most declines, this one justifies a look at the account's history, because the other explanation is that the subscription was paid for with stolen details from the start.
Will charges I already collected on a stolen card be disputed?
They can be. A cardholder who reports theft tends to review recent charges, and ones they don't recognise become disputes. Legitimate charges from a real customer usually survive that review; charges on a card that was stolen before it reached you usually don't.
What is the practical difference between lost_card and stolen_card?
On the decline itself, none: same dead credentials, same non-disclosure instruction, same pointlessness of retrying. The difference is in what the report implies about the account and its past charges, which is why this page spends its time looking backwards.
Related codes
Updated 2026-09-01