Stolen Card
Category: Lost/Stolen (Pickup) Retryable: no
Variability
Meaning varies by network
Take the card brand and processor into account before treating this as diagnostic.
Retryable
no
Namespace: Legacy/conventional ISO 8583 field-39 code as implemented by card networks and processors — not the current ISO 8583:2023 Annex D table.
What this code typically means
The card has been reported stolen. As with 41, Stripe exposes a dedicated stolen_card decline code with explicit guidance not to reveal the reason to the customer, while Adyen's published refusal-reason list carries no distinct stolen-card entry — again folded into broader blocked/fraud buckets.
What to do about it
Merchant action
Hard decline — do not retry under any circumstance. Flag the account for fraud/risk review; a stolen-card attempt against your business can indicate broader card-testing activity worth investigating beyond this single transaction.
Customer-facing guidance
Don't disclose the specific reason. Present as a generic decline and direct the customer to their issuer, per Stripe's own guidance for this code.
What's happening on the issuer's side
Card has been deactivated following a theft report; some issuers additionally flag the merchant/BIN combination for monitoring.
Cross-processor equivalents
stripe: stolen_card
commonly treated as equivalent
Cross-processor mappings are commonly treated as equivalent, not identical — every processor's own documentation notes lossy or partial mapping between raw network codes and its own vocabulary.
Sources
- Stripe — Card decline codes — fetched 2026-08-20
- Worldpay ISO 8583 Reference Guide V2.58 — Debit/Credit Response Code Mappings — fetched 2026-08-20
- ISO 8583:2023 Annex D — Action codes (current standard, 4-digit) — fetched 2026-08-20
Concept + retry philosophy
Decline Codes: why they're opaque and how to retry them