Card Decline-Code Lookup
Look up any of the 16 card decline codes worth operators knowing — meaning, whether it's worth retrying, and what to do next. Each one is cross-checked against Stripe, Adyen, and a real processor's ISO 8583 implementation.
These are not current ISO 8583 codes — the live ISO 8583:2023 standard uses 4-digit action codes. The 2-digit codes below are a legacy convention that networks and processors still run on. See Decline Codes for why that distinction matters.
Lost/Stolen (Pickup)
Pick Up Card
The issuer is instructing the acceptor to retain the physical card, without specifying a fraud or loss reason. In today's overwhelmingly card-not-present and EMV environment this instruction is rarely actionable — a merchant can't physically retain a card in an online or tap transaction — so 04 mainly functions as a signal that the account is closed, blocked, or otherwise permanently unusable. Stripe folds it into the same pickup_card decline string as the explicitly fraud-flagged 07, which is itself evidence that the fine-grained distinction doesn't survive translation into most merchant-facing tooling.
Do Not Honor
Do Not Honor
The single most common — and least informative — decline code in card payments. Issuers use 05 as a deliberate catch-all: a risk-model score, a daily spend pattern, an internal fraud rule, or simply a preference not to authorize, all get returned as 05 rather than a more specific code — partly so a fraudster probing a stolen card number can't learn which specific defense stopped them. Adyen's own refusal-reason system effectively concedes the same point: its catch-all bucket, code 27 ('Declined Non Generic'), exists precisely because responses like a generic Do Not Honor 'cannot be reliably mapped' to anything more specific.
Suspected Fraud
Pick Up Card — Special Conditions
The fraud-flagged sibling of 04. Worldpay's own credit/debit response tables list 04 as plain 'Pick Up Card' and 07 as 'Pick Up Card, Special Conditions,' with 07 conventionally understood across networks as the fraud-suspected variant. Most processing stacks, including Stripe's, don't expose this distinction to the merchant — both collapse into a single generic pickup_card decline — so operationally you often can't tell 04 and 07 apart without raw network-code access.
Invalid Account/Card Data
Invalid Card Number
The card number fails a format or check-digit (Luhn) test, or doesn't correspond to any account the issuer recognizes — a data-entry or integration problem, not an issuer risk decision. This is one of the more consistently defined codes across processors: Stripe's incorrect_number/invalid_number, Adyen's 'Invalid Card Number,' and Worldpay's 'Invalid Account Number' all describe the same underlying failure.
Authentication Required (3DS/SCA)
Strong Customer Authentication Required
A soft decline specific to PSD2's Strong Customer Authentication mandate in the EEA (adopted in similar form by some other regulators): the issuer is declining an unauthenticated attempt not because the transaction itself is bad, but because it must be re-presented with 3-D Secure 2 authentication before it can be approved. This is a regional code, not a universal one — but Stripe's authentication_required decline code and Adyen's refusal reason 38 ('Authentication required' — 'The issuer declined the authentication exemption request and requires authentication') both describe the identical mechanism, giving this code unusually strong, exact corroboration for a code in this set despite its narrow geographic scope.
Lost/Stolen (Pickup)
Lost Card
The card has been reported lost by the cardholder. Stripe exposes this as a distinct lost_card decline code, but Adyen's public refusal-reason list doesn't break lost and stolen out separately — both fold into its blocked/restricted buckets — a concrete example of how even a seemingly unambiguous code isn't handled with the same granularity everywhere.
Lost/Stolen (Pickup)
Stolen Card
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.
Insufficient Funds
Insufficient Funds
The account balance or available credit is below the transaction amount at authorization time. This is among the most consistently defined codes in the entire set — every source checked (PaymentBrief's own glossary pages, Stripe's insufficient_funds, Adyen's 'Not enough balance,' and Worldpay's response tables) describes the same condition with no meaningful variation.
Expired Card
Expired Card
The card's expiration date has passed, or the expiry the merchant submitted doesn't match the issuer's record. Consistently defined across every source — Stripe even surfaces this in its own documentation as a worked example, showing a raw network_decline_code of "54" mapping directly to its expired_card decline string.
Restricted/Blocked Card
Transaction Not Permitted to Cardholder
The card exists and has funds, but the issuer or a cardholder-configured control blocks this specific transaction type — commonly a card not enabled for card-not-present/e-commerce use, a merchant-category restriction, or a self-service spending control the cardholder set in their banking app. Adyen's published refusal-reason list has no exact equivalent; its closest entry, 'Not supported,' describes a related but distinct condition (the issuer doesn't support the transaction type at all, rather than permitting it selectively).
Velocity/Limit Exceeded
Exceeds Withdrawal Amount Limit
The transaction amount, alone or combined with other activity in the period, exceeds a limit configured on the card — daily spend cap, per-transaction cap, or a cardholder-set control. Stripe's withdrawal_count_limit_exceeded decline code covers the same underlying concept, though what counts toward the limit (single transaction vs. cumulative) is issuer- and card-program-specific and not standardized.
Restricted/Blocked Card
Restricted Card
The card is blocked from some or all transactions — a country/geography restriction, a corporate-card merchant-category restriction, or an issuer-side block whose exact trigger is rarely disclosed to the merchant. This is one of the few codes where a processor's own documentation makes the underlying-code relationship explicit in writing: Adyen's refusal reason 25 ('Restricted Card') is described as mapping 'decline codes like 62: Restricted Card' — a direct, citable cross-reference rather than an inferred one.
Velocity/Limit Exceeded
Exceeds Withdrawal Frequency Limit
The number of transactions attempted in a period — not the amount — has exceeded a velocity limit. In the EEA this code carries an extra layer of ambiguity: some issuers return 65 to mean Strong Customer Authentication is required rather than a genuine frequency cap, so the same code can point to two operationally very different fixes depending on issuer and region.
Restricted/Blocked Card
Allowable PIN Tries Exceeded
The cardholder has entered an incorrect PIN more times than the issuer allows, and PIN-based authorization is now blocked pending reset. This is a consistently defined, low-ambiguity code — Stripe's pin_try_exceeded, Adyen's 'Pin tries exceeded,' and Worldpay's response tables all describe the identical mechanism.
Issuer Unavailable/Technical Error
Issuer or Switch Inoperative
The issuer's system, or a switch/network node in the authorization path, couldn't be reached to authorize the transaction — an infrastructure failure rather than a decision about the cardholder or transaction. This is one of the more consistently defined codes: Stripe's issuer_not_available, Adyen's 'Issuer Unavailable' ('It is not possible to contact the shopper's bank to authorize the transaction'), and Worldpay's 'Issuer Inoperative' all describe the same connectivity failure.
Issuer Unavailable/Technical Error
System Malfunction
A generic technical/processing failure somewhere in the authorization chain — not attributable to the cardholder, the transaction, or a specific risk decision. This is one of the weaker-corroborated codes in this set: it appears consistently in PaymentBrief's own glossary pages and aligns conceptually with Stripe's processing_error, but neither Adyen's published refusal-reason list nor a clean read of Worldpay's response tables independently confirms the exact scope of what triggers 96 versus a neighboring technical code — a concrete illustration of the standard's variability claim, not just a caveat.
Want the retry strategy, not just one code?
This tool targets "look up this code right now." For soft-vs-hard decline strategy and recovery timing, read the glossary explainer. For the full authorization-rate playbook — network tokenization, BIN routing, and decline-code-specific retry curves — read the article.
These are legacy/conventional 2-digit codes as implemented by card networks and processors — not the current ISO 8583:2023 Annex D standard, which uses 4-digit action codes. Meaning varies by network and issuer; verify against your PSP or acquirer before treating any single code as diagnostic.