The Ultimate Directory of Credit Card Decline Codes for Merchants

How Does a Transaction Get Declined?

When a customer swipes, dips, or keys in card data, here’s what happens:

1. POS/Gateway validates basics: card number format, expiration, CVV structure.
2. Processor/gateway sends an authorization request through the network (Visa, Mastercard, etc.).
3. Payment network routes the request to the issuing bank.
4. Issuing bank checks: balance/limit, fraud history, card status, geographic restrictions.
5. Response comes back through the network to your terminal with a result code (00 = approved, anything else = declined).

Decline can happen at any stage. Examples:

• Terminal level: invalid card number format.
• Processor level: MCC mismatch or operation type error.
• Network level: routing failure.
• Issuer level: insufficient funds, fraud suspicion, blocked card.

From the field: “When you see code 51 (insufficient funds) from the issuer, that’s a hard decline—retrying won’t help. But code 19 (re-enter transaction) from the processor? That’s soft. Retry in a few seconds and it often clears.” — payment integrators’ playbook.

Full Directory of Decline Codes: Quick Reference

Use Ctrl+F to search by code.

Sources: Visa Core Rules and Product Service Rules (October 2024); Mastercard Chargeback Guide Merchant Edition (2025); ISO 8583 standards.

Most Common Codes: Deep Dive

Code 05: Do Not Honor — The Most Frequent Decline

Likely reasons:

• Fraud suspicion (unusual amount, location, transaction type).
• Internal bank flags (new card, high-risk ML model score).
• Country/category restrictions for this cardholder.
• Blocked card or operation limits.

Cardholder action: Contact issuing bank, confirm the transaction. Often the bank lifts a temporary limit or greenlights a retry.

Merchant action:

• Don’t auto-retry multiple times (risks chargebacks).
• Ask customer to call bank.
• Offer alternate payment (different card, wallet).
• If one retry after 24 hours still returns 05, switch methods.

“Code 05 is a red flag. If you see it systematically for certain operation types, it might be your MCC config or geo-blocking. Check settings with your processor.”
— From payment integrators’ experience

Code 51: Insufficient Funds — Not Enough Money

Code 51 is clear: not enough money on the card or account.

• For debit card: current/savings account balance below transaction amount.
• For credit card: used credit + transaction amount exceeds limit.

This is soft in the sense that the reason is obvious and the customer can fix it (top up account). But retrying won’t help until they do.

Cardholder action:

• Check balance in bank app.
• Top up account/increase credit limit.
• Use different card with sufficient funds.
• Split payment if possible.

Code 12: Invalid Transaction — Config or Data Error

Code 12 often signals merchant-side error, though it can look like a customer mistake.

Likely reasons:

• Wrong operation type (e.g., refund attempt without original capture).
• Terminal/gateway doesn’t support the mode (chip, contactless, online).
• Currency mismatch with terminal-allowed currency.
• MCC (Merchant Category Code) doesn’t support the operation.
• Merchant access rights restricted.

Cardholder action: Wait a few minutes and try again. If still 12, use different payment method or contact merchant.

Merchant action:

1. Check POS config:
   • What operation type is set (sale, auth+capture, refund)?
   • What currency is configured?
   • What MCC is on your merchant account?
2. Check gateway/processor:
   • Does the gateway support this card type (Visa/Mastercard/Amex)?
   • Is it running in card-present/card-not-present mode?
3. Retry operation with corrected parameters.

Security Errors: CVV, SEC Violation, and Code 82

Security codes signal protocol breaches or checks that protect against fraud.

CVV/CVC2 — Security Code

CVV (Card Verification Value) or CVC2 (Card Verification Code 2) is a three- or four-digit code on the back of the card (or front for Amex). It’s the card’s “password,” generated by the issuing bank via encryption of the card number and expiration date.

Why it matters:

• Confirms the customer physically holds the card (for card-not-present transactions).
• Issuing bank verifies the code matches its record.
• Merchant must NEVER store CVV post-authorization (PCI DSS requirement).

AVS (Address Verification Service)

AVS checks if the billing address matches the address registered with the issuing bank. Available in the US, Canada, and UK.

AVS results:

• Y (Yes): address and ZIP match — low risk.
• N (No): address doesn’t match — medium risk.
• U (Unavailable): bank doesn’t support AVS — usually foreign cards.
• G/S: international/no address — for overseas cards.

3D Secure (3DS)

3D Secure is two-factor authentication where the issuing bank requests an OTP or password from the customer in a separate window.

If 3DS fails, the transaction may return code 63 (Security Violation).

Code 63: Security Violation

Merchant action:

• Ensure you collect CVV and pass it in the authorization request.
• Enable AVS for card-not-present transactions.
• Apply 3D Secure for risky operations (high amounts, new customers, foreign cards).
• Verify your app/form correctly transmits security data.

Stats: Per payment network data, proper 3D Secure implementation reduces fraud declines but can increase friction for customers. Balance matters.

Serious Restrictions: Transaction Not Permitted and Pick Up Card Codes

Code 58: Transaction Not Permitted to Cardholder

This code means the operation is not allowed for this cardholder. The bank explicitly forbids this transaction for this card.

Likely reasons:

• Card type doesn’t support online payments (e.g., payroll card with restrictions).
• Merchant category (MCC) is blocked for the card.
• Country/geo-zone blocked.
• Card blocked for certain operation types.

Action:

• Merchant: offer customer different payment method or different card.
• Customer: contact bank to clarify restrictions.

This is a hard decline; retrying won’t help.

Codes 04, 07, 41, 43, SF: Pick Up Card

These codes signal serious threat: card is likely lost or stolen.

Merchant procedure when receiving Pick Up Card:

1. Don’t create conflict. Ask customer calmly, without accusations.
2. Retrieve card if customer agrees and it’s safe. If customer refuses or there’s a threat, don’t insist.
3. Call your processor/acquirer for instructions.
4. Document date, time, customer name, last card digits, actions taken.
5. Never accuse customer of theft or loss—it could be a system error.

Source: Visa Operating Guides; Mastercard Transaction Processing Rules (2025).

Soft Declines vs Hard Declines: Differences and Actions

Step-by-Step Merchant Actions on Decline

Checklist for Cashier / Operator

Gateway-Specific Error Codes

Stripe: Card Blocked — How to Interpret

Stripe returns errors in structured JSON with fields:

• error.type — category (card_error, invalid_request_error, api_error).
• error.code — error code (card_declined, expired_card, incorrect_cvc).
• error.decline_code — reason code from issuer (do_not_honor, insufficient_funds, etc.).
• error.message — description for customer.

Stripe mapping examples → standard codes:

Link to docs: Stripe API Reference (2025); Stripe Decline Codes (2025).

Adyen: refusalReason and refusalCode

Adyen returns:

• refusalReason — human-readable reason (e.g., “Not enough balance”).
• refusalCode — two-digit code from issuer (e.g., “51”).
• refusalCodeRaw — exact issuer code from ISO 8583.

Examples:

Link: Adyen API Documentation (2025); Adyen Refusal Codes.

Authorize.net: Response Code and Reason Code

Authorize.net uses:

• responseCode — overall status (1 = approved, 2 = declined, 3 = error, 4 = held).
• reasonCode — decline reason (two-digit code).

Examples:

Link: Authorize.Net API Reference (2025).

Grouping Codes by Root Causes

Category 1: Customer Data Entry Errors

These declines occur when the customer entered wrong data or the card is physically damaged.

Codes: 13, 14, 82, 97.

Merchant action:

• Immediately tell customer what’s wrong (number, amount, code).
• Offer to correct and retry.
• After 3 failed attempts → alternate method.

Category 2: Insufficient Funds and Limits

Customer can’t process payment due to lack of money or hitting limits.

Codes: 51, 61, 65.

Merchant action:

• Explain it’s a card/account limit, not merchant’s.
• Offer to top up account if possible.
• Save payment info for later retry (if customer wants).

Category 3: Security and Fraud

System detected suspicious activity or protocol breach.

Codes: 05, 04, 07, 41, 43, 63.

Merchant action:

• Never take actions that could create conflict.
• Politely explain.
• Offer alternate payment method.
• Document incident.

Category 4: Technical Failures

Network / bank temporarily unavailable or format error detected.

Codes: 19, 28, 12, 15.

Merchant action:

• Safe to auto-retry (2–3 attempts).
• Monitor network/processor status.
• If frequent → contact tech support.

Proactive Strategies to Reduce Declines

Every decline is lost revenue. Here’s what works in practice.

1. Mandatory Security: AVS, CVV, 3D Secure

AVS (Address Verification Service):

• Require ZIP code + address for card-not-present.
• Decline only if AVS = N (full mismatch). Codes U, G, S are acceptable (foreign cards).

CVV:

• Always collect and pass in authorization.
• Never store post-authorization.
• Require re-entry on mismatch (don’t save from browser cache).

3D Secure 2.0:

• Enable for risky scenarios: high amounts (>$500), new customers, foreign cards.

2. Network Tokenization and Account Updater

Network Tokenization:

• For recurring/subscription payments use Network Token instead of storing card number.
• Token auto-updates when card is reissued.
• Result: improved subscription metrics.

Account Updater:

• Service that receives card updates from issuer.
• Auto-updates expired cards (code 54).
• Available from most processors (Stripe, Adyen, Authorize.net).

3. Smart Routing and Multi-Processing

Dynamic Routing:

• Send same payment to different processors / acquirers simultaneously.
• Pick fastest successful result.
• Reduces hard declines (some acquirers may approve what others declined).

Multi-processor fallback:

• Primary processor declined? Switch to Secondary processor after 1–2 sec.
• Requires setup, but it works.

4. Payment Form UX Optimization

Masks and hints:

• Auto-format card number (spaces every 4 digits).
• Auto-detect issuer (Visa vs Mastercard) by BIN.
• CVV entry hint (back of card).

Real-time validation:

• Luhn check immediately on number entry.
• Expiration date check (don’t allow expired dates).

5. Decline Monitoring and Analysis

Collect data:

• Decline code, gateway, hours, days of week, amounts, countries.

Look for patterns:

• If 30% declines are code 05 from one processor, contact them.
• If spikes in codes 19, 28 at certain times, monitor network downtime.

Act:

• Switch routing on systematic declines.
• Update terminal configs.

Field tip: “I recommend monthly decline audits. Even in successful payment systems, 15–20% losses come from wrong config or lack of proper retry logic. Spend 2 hours on analytics—save $5–10K/month by lowering decline rate.”

Related Resources and Primary Sources

• Visa Developer Resources — official authorization response and decline handling specs (2025).
• Mastercard Developer Center — reason codes and response codes documentation (2025).
• Stripe Error Handling Documentation — complete Stripe codes reference and mappings (2025).
• Adyen API Documentation — refusal codes and handling best practices (2025).
• Authorize.Net API Reference — reason codes and integration (2025).
• PCI DSS Compliance Guide — payment processing security requirements.
• ISO 8583:2003 Standard — official standard.

Internal Navigation Across Payment Cluster

This article is the central hub for decline codes. Related materials:

• Complete guide to payment form optimization — reducing declines through UX.
• Network Tokenization and Account Updater: how they work — for recurring payments.
• 3D Secure 2.0: implementation and setup — technical guide.
• Chargebacks and dispute management — how to avoid returns.
• Multi-processor routing and failover — architecture for reliability.