Card decline codes

The issuer's catch-all refusal: the bank chose not to approve and chose not to say why. Common causes are internal risk rules, account status, or velocity logic, but even the processor cannot see the reason.

Retry: The cardholder's bank is the only party that knows more. One informed retry after the customer talks to their bank is reasonable; repeated blind retries are not.

Tell the customer: "Your bank declined this payment without providing a reason. This usually clears up if you contact your bank, or you can use a different card."

Hard or soft: Soft (Visa category 4; Braintree classifies its 2000 equivalent as soft).

The code developers google most, and the archetypal vague decline. It counts against Visa's 15-reattempts-in-30-days cap, so hammering it burns your authorization-rate reputation and can draw excessive-retry fees. Schedule one or two well-spaced retries at most.

The network description is 'insufficient funds / over credit limit': the account behind the card cannot cover the amount right now. That includes maxed-out credit cards, not just empty debit accounts.

Retry: The textbook recoverable decline (Visa category 2): balances change. For the current session, offer another payment method.

Tell the customer: "Your card was declined due to insufficient funds. You can use a different payment method, or try again after adding funds."

Hard or soft: Soft (Visa category 2; Braintree 2001: soft).

The prime smart-retry candidate for subscriptions: schedule a few well-spaced retries aligned to likely funding events (start of month, paydays). Still capped by the 15-in-30 network rule, so retry on a schedule, not daily.

The issuer declined without a usable reason, or the payment never reached the issuer because the processor's fraud layer blocked it first.

Retry: With no reason given, an identical retry usually repeats the outcome. The customer's bank knows more; a different payment method works now.

Tell the customer: "Your card was declined by your bank. No specific reason was shared with us. You can contact your bank for details, or try a different payment method."

Hard or soft: Indeterminate; treat as hard for automated retry purposes.

Two gotchas. It is overloaded: it can be a processor-side fraud block that never touched the issuer, in which case 'contact your bank' is literally wrong. And it is deliberately shared: processors instruct merchants to present lost_card, stolen_card, and fraudulent to buyers exactly like generic_decline, so this is the message serious codes hide behind.

A soft decline meaning 'authenticate the cardholder, then I'll consider it.' The issuer mandates strong customer authentication (3D Secure) before approving.

Retry: Run 3D Secure and resubmit; for off-session payments, bring the customer back on-session to complete the challenge.

Tell the customer: "Your bank requires additional verification for this payment. Please complete the verification step to continue."

Hard or soft: Soft, explicitly: Adyen documents this refusal as a soft decline.

Driven by PSD2/SCA issuers in the EEA and UK. Hosted payment elements handle the challenge-and-retry automatically; you mostly see this raw on API integrations and merchant-initiated charges. Cross-scheme trap: Mastercard reuses numeric 65 for this, the same number that classically means 'withdrawal count limit exceeded'.

The security code the customer typed does not match the card (Visa N7: 'decline for CVV2 failure').

Retry: Retry only with corrected input; an identical retry is pointless.

Tell the customer: "The security code (CVC) you entered doesn't match your card. Please check the 3-digit code on the back (4 digits on the front for Amex) and try again."

Hard or soft: Data-quality decline. Sources split on the label: Braintree marks its CVV decline hard, Visa files N7 under category 3 (fix the details, then retry). Both agree identical retries fail.

Repeated CVC failures on one card are a card-testing signature: rate-limit attempts. At volume, category 3 declines also feed Visa's data-quality fee, so do not let bots grind CVC guesses through your checkout.

The card's expiry date has passed. The stored card will never work again as saved.

Retry: The customer likely holds a reissued card with a new expiry; collect the new details or another card.

Tell the customer: "This card has expired. If you've received a replacement card, please enter its new details, or use a different payment method."

Hard or soft: Hard (Braintree 2004: hard); Visa files 54 under category 3 because updated details can succeed.

The code card account-updater services exist for: expired cards are usually reissued, and Mastercard signals it with merchant advice code 01, 'new account information available'. Distinguish from a mistyped expiry date, which processors report as an invalid-expiry error instead.

Network 14, 'invalid account number (no such number)': the card number does not correspond to any real account.

Retry: Visa's rules are explicit: 'Merchants must not reattempt any transaction using the same account number following a decline for Response Code 14.' A corrected number is a new attempt and fine.

Tell the customer: "The card number you entered isn't valid. Please re-check the digits and try again."

Hard or soft: Hard for the number as entered (Braintree 2005: hard). Uniquely, Visa places code 14 in both category 1 and category 3.

Usually a checkout typo that client-side Luhn and BIN validation should have caught before it cost an authorization. If you see many of these, fix your form validation, not your retry logic.

Network 41, 'pickup card (lost card)': the cardholder reported this card lost, and the account is dead at the issuer.

Retry: Visa category 1, 'issuer will never approve': any reattempt is a network rules violation with fee exposure.

Tell the customer: "Your card was declined. Please contact your bank for more information, or use a different payment method."

Hard or soft: Hard (Visa category 1; Braintree 2012: hard).

Two absolute rules. Never retry. And never disclose the reason: processors instruct presenting this exactly like a generic decline, because the person at your checkout may be the thief and the lost status is between the issuer and the real cardholder. For subscriptions, prompt for a new payment method.

Network 43, 'pickup card (stolen card)': the cardholder reported the card stolen.

Retry: Visa category 1: the account is permanently closed to authorizations.

Tell the customer: "Your card was declined. Please contact your bank for more information, or use a different payment method."

Hard or soft: Hard (Visa category 1; Braintree 2013: hard).

Identical handling to lost_card: never retry, never disclose. A successful charge would likely come back as a fraud chargeback anyway. Treat a stolen-card decline as a fraud signal on the session and account, not just a failed payment.

The issuer wants the physical card taken out of circulation (a card-present-era instruction). Same family as lost/stolen, without the stated reason; 07 adds 'special conditions', historically fraud-related.

Retry: Visa category 1 for both 04 and 07: the issuer will never approve this card.

Tell the customer: "Your card was declined. Please contact your bank, or use a different payment method."

Hard or soft: Hard (Visa category 1).

Online there is no card to physically pick up, but the signal is identical: dead card, possible fraud context, zero retries. Do not surface the code name to buyers.

The processor's own fraud systems judged the payment fraudulent and declined it; the related network code 59 is the issuer saying 'suspected fraud'.

Retry: Retrying re-triggers the same screening and looks like fraud probing. If a trusted customer is falsely flagged, fix it in your fraud tooling, not by resubmitting.

Tell the customer: "Your card was declined. Please contact your bank for more information, or try a different payment method."

Hard or soft: Hard (Braintree 2014: hard).

Never tell the customer fraud was suspected: Stripe's instruction is to present it exactly like generic_decline. Telling a real fraudster your fraud system flagged them is free intelligence; telling a legitimate customer is alarming and unactionable.

The card hit an issuer-imposed spending or frequency limit (network 61: amount limits; 65: count limits). Common on debit cards with daily caps and on prepaid cards.

Retry: Velocity windows reset, often daily; an immediate identical retry inside the same window is guaranteed to fail.

Tell the customer: "Your card has reached a spending or transaction limit set by your bank. You can try again later, contact your bank to raise the limit, or use another payment method."

Hard or soft: Soft (Visa category 2; Braintree's limit analogs are soft).

Bursts of velocity declines across many different cards mean something else entirely: your checkout is being used for card testing. Watch the pattern, not just the individual decline.

Too many transactions on the card in the issuer's time window, regardless of amount (network 65: 'exceeds withdrawal count limit').

Retry: Count windows reset; Visa files this under category 2.

Tell the customer: "Your card has hit its transaction count limit for this period. Please try again later or use a different payment method."

Hard or soft: Soft (Visa category 2).

Major cross-scheme trap: on Mastercard in SCA-regulated markets, response 65 means 'authentication required', a soft decline fixed by running 3D Secure, not by waiting. Trust your processor's normalized code; if you parse raw 65s yourself, disambiguate by scheme and market or you will wait out declines a 3DS retry would have converted.

Visa's definition of 62: 'restricted card (card invalid in region or country)'. The card is barred from this kind of use, most often geographically.

Retry: The restriction is issuer policy on the card; only the cardholder can get it lifted.

Tell the customer: "Your card can't be used for this purchase, often due to regional or card-type restrictions set by your bank. Please contact your bank or use a different card."

Hard or soft: Soft-leaning: Visa moved 62 from category 1 to category 2 in April 2021, acknowledging restrictions can be temporary (travel flags, for example).

Common in cross-border e-commerce with domestic-only cards. Processor copy sometimes lumps this near lost/stolen; Visa's own definition is region and card-type restriction, which is the interpretation to trust. Keep buyer messaging generic either way.

The card or the merchant setup is not permitted to run this type of transaction: e-commerce disabled on the card, merchant-category restrictions, cross-border blocks. Network 57 blames the cardholder's permissions; 58 blames the acquirer or terminal configuration.

Retry: For 57, only the issuer can enable the transaction type. For 58, the fix is on your side: open a ticket with your processor; retrying without a config change is pointless.

Tell the customer: "Your card doesn't allow this type of transaction. Please contact your bank to enable it, or use a different card."

Hard or soft: Hard (Visa puts 57 in category 1; Braintree 2015: hard).

The 57 versus 58 split is operationally important: a run of 58s is a merchant-configuration problem, not a customer problem. Do not email customers about declines that your processor ticket queue should be fixing.

The payment amount is invalid or exceeds what is allowed (network 13: 'invalid amount', often an amount mismatch).

Retry: First verify the amount you sent: sign, currency minor units, zero or negative values. If it is genuinely correct, the customer needs to check their card's amount limits.

Tell the customer: "The payment amount couldn't be processed. Please try again; if it keeps failing, your bank may limit purchases of this amount."

Hard or soft: Data or configuration decline: identical retries fail; corrected amounts succeed.

Frequently a merchant-side bug, not a bank problem: minor-unit errors (charging 150000 cents instead of 1500), locale decimal parsing, or negative totals after discounts. Integer minor units everywhere is the structural fix; check your own math before blaming the issuer.

Something in the authorization chain failed mechanically; nobody actually judged the card (network 96: 'system malfunction').

Retry: Transient by definition; retry once now, then again later if needed.

Tell the customer: "There was a temporary problem processing your payment. Nothing is wrong with your card. Please try again in a moment."

Hard or soft: Soft (Visa category 2).

One of the few codes where an immediate retry is officially sanctioned. Reuse the same idempotency key so a slow-but-successful first attempt cannot double-charge. A spike of these across many cards is an outage somewhere: check status pages before debugging your integration.

The issuer's authorization system could not be reached, so no decision was made (network 91: 'issuer system inoperative').

Retry: This is issuer downtime, not a judgment on the card; short backoff then retry converts many of these.

Tell the customer: "We couldn't reach your bank to authorize this payment. Please try again in a few minutes."

Hard or soft: Soft (Visa category 2).

Clusters of 91s from one BIN mean one bank is having an outage. Do not send those customers off to 'fix their card'; just retry later.

Something garbled the authorization in transit; the issuer asks for the transaction to be submitted again (network 19: 're-enter transaction').

Retry: The network literally requests a retry, making this the most retry-safe decline that exists.

Tell the customer: "Your bank couldn't process the payment this time. Please try submitting it again."

Hard or soft: Soft (Visa category 2).

Still use idempotency keys, and stop after a couple of failures: persistent 19s indicate a deeper routing or data problem.

The issuer wants a conversation with the cardholder before approving; online, that collapses to 'declined, ask your bank'.

Retry: Banks often approve the very next attempt after the cardholder confirms the purchase by phone; retrying before that reproduces the decline.

Tell the customer: "Your bank needs to speak with you before approving this payment. Please call the number on the back of your card, then try again."

Hard or soft: Hard until the customer acts (Braintree 2044: hard).

A relic of voice-authorization workflows that survives as a soft fraud hold. This is one decline where telling the customer exactly what to do (call the bank, then retry) measurably recovers sales.

The card cannot settle in the presented currency.

Retry: The same card and currency will keep failing; a different card works now.

Tell the customer: "Your card doesn't support payments in this currency. Please use a different card, or contact your bank."

Hard or soft: Hard for this card and currency pair.

Seen with single-currency and domestic-only cards hitting a foreign-currency price. If you know the buyer's market, pricing in a currency their local cards support is the structural fix.

An identical transaction (same amount, same card) was submitted very recently; the issuer or processor suspects a duplicate.

Retry: Investigate first: the original attempt may have succeeded, and a blind retry risks double-charging.

Tell the customer: "This looks like a duplicate of a payment you just made. Please check whether the first payment went through before trying again."

Hard or soft: Soft (Braintree 2016: soft), but the correct response is reconciliation, not retry.

Usually a symptom of double-submitted checkouts: double-clicked pay buttons, client retries after a timeout, missing idempotency keys. Treat its appearance as a bug report against your checkout's idempotency handling.

The leading digits of the card number (the BIN) do not correspond to any issuing bank; the number is structurally wrong.

Retry: Only a corrected card number can succeed; the entered number references a bank that does not exist. Visa category 1 for the number as entered.

Tell the customer: "The card number you entered isn't valid. Please re-check the digits, especially the first few, and try again."

Hard or soft: Hard (Visa category 1; Braintree 2009: hard).

Almost always a typo in the first six to eight digits. Client-side BIN validation catches these before they cost an authorization.

The card was replaced or reissued and updated credentials exist. Mastercard's merchant advice code 01 is the explicit machine-readable version of this signal.

Retry: Retry with updated credentials, never the stored ones: get them from the customer or a card account-updater service.

Tell the customer: "Your card details appear to be out of date, often because your bank issued you a new card. Please update your payment details."

Hard or soft: Hard for the stored credentials; fully recoverable with updated ones.

The single strongest account-updater signal in recurring billing: the issuer is telling you replacement credentials exist. Wiring this into dunning (update, then retry, instead of blind retry) is the difference between recovering and churning these subscribers.

The cardholder instructed their bank to block a specific payment, typically a recurring one. Cancel-by-bank instead of cancel-by-merchant.

Retry: Visa category 1: the bank is enforcing the cardholder's explicit instruction, and reattempts violate network rules.

Tell the customer: "This payment was blocked at your request via your bank. If you'd like to continue the service, please update your payment method or contact us."

Hard or soft: Hard (Visa category 1).

Keep charging and you are converting declines into disputes: the cardholder already told their bank no. Halt billing on this instrument immediately and treat it as a cancellation or payment-update event, not a dunning event.

The cardholder withdrew their standing authorization for this merchant's recurring charges at the issuer.

Retry: Consent has been formally revoked; Visa category 1.

Tell the customer: "Your bank indicates you've withdrawn authorization for these payments. If that's not right, or you'd like to resume, please update your payment details with us."

Hard or soft: Hard (Visa category 1).

Stronger than a failed payment: it revokes the billing agreement itself. Mastercard's MAC 21 'stop recurring payment' is the equivalent signal, and retrying after either draws scheme fees. Suspend the subscription and reach out through your own channels.

The cardholder revoked all preauthorized and recurring payments on the card, across every merchant.

Retry: Visa category 1: nothing recurring will ever be approved on this card again.

Tell the customer: "Your bank has blocked all automatic payments on this card. To continue, please provide a different payment method."

Hard or soft: Hard (Visa category 1).

Often accompanies a compromised card or an account cleanup. There is no merchant-specific remedy: purge scheduled retries against the card immediately and request a new payment method.

The account behind the card is not usable: network 46 is 'closed account'; 78 is 'invalid or nonexistent account' in Mastercard usage.

Retry: A closed or nonexistent account cannot be fixed by retrying; the customer needs their bank or another card.

Tell the customer: "Your bank reports a problem with the account linked to this card. Please contact your bank, or use a different payment method."

Hard or soft: Hard (46 is Visa category 1).

Cross-scheme conflict worth knowing: Visa defines 78 as 'blocked, first use' (a new card not yet activated, category 2 and retryable after activation), while Mastercard usage means invalid account. The same number means different things per scheme; trust your processor's normalized code over raw 78s.

The card cannot make this kind of purchase: FSA/HSA cards outside health merchant categories, corporate cards with category locks, or debit products barred from cross-border e-commerce.

Retry: The block is between the card product and your merchant category; retrying does not change your MCC.

Tell the customer: "Your card doesn't support this type of purchase. Please contact your bank or try a different card."

Hard or soft: Hard for this card at this merchant.

If these cluster on a specific card type, the pattern is the actionable signal, not the individual decline.

Address verification failed on the postal code: it does not match the issuer's billing record.

Retry: Corrected input succeeds; identical input fails.

Tell the customer: "The billing ZIP/postal code doesn't match your card's records. Please enter the postal code your bank has on file."

Hard or soft: Data-quality decline.

Customers habitually enter their shipping ZIP instead of the card's billing ZIP; label the field explicitly. Repeated mismatches can escalate into fraud-rule blocks even when the card is fine.

A security condition at the issuer failed; details are not shared (network 63).

Retry: Security declines rarely self-heal; the issuer holds the details.

Tell the customer: "Your bank declined this payment for security reasons. Please contact your bank, or use a different payment method."

Hard or soft: Hard-leaning (Visa category 4 for reattempt accounting).

Despite the alarming name, keep buyer messaging calm and generic: the 'violation' is an issuer-side security check, not an accusation. Recurring 63s belong in the never-auto-retry bucket with the fraud-family codes.