Decline code

Stolen Card

Stripe declined this payment because the card on file has been reported stolen. The issuing bank has permanently blocked the card, and no charge against it will succeed, regardless of how many times it is retried. Stripe's official definition states plainly that the payment was declined because the card is reported stolen. Unlike a lost card, which usually points to a customer's own mishap, a stolen card carries a real possibility that the card number itself was compromised or that the subscription was set up using someone else's payment details in the first place. Both explanations are possible, and telling them apart matters before you do anything else.

Back to decline codes
stolen_cardNever retried
Draft content: this page's explanatory copy is Pass 3 template writing pending a dedicated content pass. The classification badge above and the recovery behavior described below are live, not draft: both come directly from the recovery engine.

Why it happens

Two very different situations produce this code on a recurring charge. In the first, a legitimate long-time customer's card was stolen (wallet theft, a data breach, a skimmer) and the bank shut it down, the same way a lost card would be shut down, just with a theft report instead of a loss report. In the second, the subscription itself was created using a stolen card, and the decline is the first sign that the account was never legitimate to begin with. These two situations call for opposite responses, so the account context needs to be checked before reaching out to anyone.

How to fix it

No. The card is permanently blocked by the issuing bank. Retrying does nothing except waste a dunning attempt, and repeated charge attempts against a card flagged as stolen can draw negative attention from card networks toward the merchant account making the attempts. Stop all retries immediately, since the card is blocked and repeated attempts increase the risk of network penalties against your Stripe account. Before sending any recovery email, check the account for fraud signals: was it created recently, did the subscription start shortly before the decline, is the usage pattern unusual, were other cards on the account also declined. If those signals are present, flag the account for manual review before reaching out, rather than emailing the address on file, since that address may not belong to the legitimate cardholder at all. If the account looks established and ordinary, a low-key request to update the payment method is reasonable, framed the same way you would for a lost card.

How Foxhound recovers it

Fraud and security declines are never retried, silently or otherwise. Foxhound sends a gentle, clearly worded email sequence across 30 days that names the situation plainly and points the customer to their card issuer, rather than repeating the same charge against a flag the issuer already raised.

Questions

  • No. The card is blocked by the bank regardless of the reason behind the theft report, so retrying will not succeed and can create additional risk for your merchant account.

  • Not without checking the account first. If the subscription was created recently or shows other fraud signals, the email address on file may not belong to the real cardholder.

  • Recent account creation, a subscription that started shortly before the decline, unusual usage patterns, and other cards on the account that were also declined.

  • Both result in a permanently blocked card, but a stolen-card report carries a higher chance the card details were compromised or the account itself is fraudulent, so more caution is warranted before contacting anyone.

  • No. It falls in Foxhound's fraud bucket, which suppresses the automatic retry and dunning sequence in favor of flagging the case for careful handling.

See what this looks like on your account

The free audit shows what Stripe already recovered and what is still dying, no signup required.

Run your free audit