Credit Card Decline Codes: A Merchant's Guide to Reading Them as Risk Signals

Credit Card Decline Codes: A Merchant’s Guide to Reading Them as Risk Signals

A credit card decline code helps you check why a payment attempt stopped and which provider guidance applies next. Confirm the source layer and any raw network or advice code before deciding whether to correct data, complete authentication, retry, or review an order. A decline code alone does not predict a later dispute.

Where your decline code actually came from

Before you act on a code, establish who generated it. Three layers can stop a transaction, and they produce different codes with different remedies.

Layer 1 — Your gateway’s own risk rules. Stripe returns merchant_blacklist when a payment matches a value on your block list. A Stripe-blocked payment is not authorized by the issuer. The duplicate_transaction code means an identical amount and card were submitted very recently; check for an existing payment before another attempt. Check the outcome and available raw network data instead of inferring the source layer from that string alone.

Layer 2 — Your acquirer or processor. A gateway or processor can reject invalid submitted data before an authorization is sent. Stripe authentication_required means authentication is needed and can follow an issuer soft decline; off-session cases may require the customer to return. It does not identify a single source layer. Stripe mobile_device_authentication_required calls for the customer to tap their mobile device again.

Layer 3 — The issuer. An issuer can decline an authorization and send a network response through the payment chain. A normalized Stripe string alone does not establish that the issuer declined the attempt; Stripe can also block payments.

The practical consequence: fix submitted data or integration errors when the provider identifies them. For an issuer decline, follow the available network/advice codes and provider guidance. A normalized Stripe string alone does not establish which layer stopped the attempt.

What "card issuer declined" means and how to respond

When a checkout or payment log shows "card issuer declined," the cardholder’s issuing bank—not your payment gateway or acquirer—refused the authorization request. Under Visa Core Rules (Section 7.3.6.3, Table 7-2, Edition April 2026), a card issuer declined response falls into one of four operational categories: Category 1 hard declines (such as Visa 04/07 pick up card, 14 invalid account number, 41 lost card, 43 stolen card, 46 closed account, 57 transaction not permitted, and R0/R1/R3 stop-payment or revocation orders, which must never be retried), Category 2 temporary issuer declines (such as Visa 51 insufficient funds, 61/65 velocity limits, 62 restricted card, or 59/83 fraud and security blocks), Category 3 data-quality declines (such as Visa 54 expired card, 82/N7 CVV failure, or 6P verification failed, which require revalidating cardholder data first), and Category 4 generic declines (Visa 05 Do not honor, where the issuer does not disclose the underlying reason).

To handle a card issuer declined event without triggering network retry penalties, inspect the raw network_decline_code and any advice code alongside the normalized gateway string. If the response is in Category 1, stop automated retries immediately and ask the customer for a different payment method; if it is in Category 3, prompt the customer to correct the expiration date, CVV, or billing address before reattempting; if it is in Category 2 or Category 4 (such as Visa 51 or 05), follow processor retry guidance (Stripe recommends no more than eight retries; Visa’s rule ceiling is 20 attempts in 30 calendar days) or ask the cardholder to confirm the transaction with their issuing bank. When unresolved issuer declines coincide with customer billing complaints, coordinate your retry rules with your chargeback process and prevention workflow.

One structural detail matters here. Stripe’s decline_code is a normalization layer. It maps responses from Visa, Mastercard, Amex, Discover, and others into one set of readable strings. Stripe documents the cost of this directly:

“The meaning of a code differs based on the card network. For this reason, take the card’s brand into consideration when interpreting the code.”

Two different network codes with different retry rules can arrive as the same Stripe string. Compare the definitions below, then check the actual network_decline_code and any advice code for the transaction rather than inferring them from the Stripe string.

Also worth knowing before you tune timeouts: Visa rules require that “an Acquirer or a Merchant must not timeout a POS Transaction in less than 15 seconds” (Visa Core Rules, ID# 0030580, Edition Apr 2026; not applicable in the Europe Region). If your integration abandons authorizations at 10 seconds and logs them as declines, some of what you are calling a decline is your own timeout.

Stripe decline_code and the card network code underneath it

The table below compares Stripe strings with Visa definitions where their descriptions align, and leaves codes unmapped where they do not. This definition-level comparison does not establish the actual network code or retry permission for an individual transaction.

Stripe decline_code and Visa response definitions, with Visa retry rules

Source text rechecked October 19, 2026. Organized per public Stripe and Visa documentation; the code an issuer actually returns depends on that issuer’s implementation.

Codes appearing in Stripe’s list without a definition-level Visa match — approve_with_id, card_not_supported, currency_not_supported, invalid_amount, new_account_information_available, no_action_taken, not_permitted, offline_pin_required, service_not_allowed, security_violation, incorrect_number, invalid_cvc, mobile_device_authentication_required — are left unmapped deliberately. Stripe builds these strings from several card networks at once, and guessing at the code underneath one of them would defeat the purpose of the table. Where you need certainty, log network_decline_code and read the raw value.

Three rows change what you do, so they are worth stating outright.

Visa code 54 is classified as a data quality problem. Visa places code 54 (Expired card or expiration date missing) in Category 3, labelled “Data quality – Revalidate payment information.” The rule text treats it as a signal to revalidate the payment credential, not proof that the card is dead. Stripe separately describes expired_card as an expired card and advises another card; do not treat the Stripe string as proof of Visa code 54.

insufficient_funds does not always mean the account is empty. Visa’s April 2026 rules, Section 4.24.2.2, give a narrower rule for Visa Infinite Corporate cards in the LAC Region. Response code 51 is limited to a transaction taking the balance more than 20% above the approved credit line, or an issuer-responded ATM withdrawal exceeding activity parameters. This is a product- and region-specific example, not a rule for all cards. Code 51 is not an account-balance readout.

do_not_honor and generic_decline need context. Visa’s Category 4 is “Generic response codes,” which issuers are instructed to limit “to transactions where no other value applies.” Stripe generic_decline can describe an unknown reason or a Stripe Radar or Adaptive Acceptance block. Check the available outcome, raw network response and advice rather than treating every generic_decline as Visa 05.

Source text rechecked against public Stripe and Visa documentation on October 19, 2026. The code an issuer actually returns depends on that issuer’s implementation.

Soft vs hard declines: what you may retry, what you must not

The soft/hard distinction is usually presented as a rule of thumb. For Visa transactions it is an actual published rule with an actual number attached.

Visa Table 7-2 sorts decline response codes into four categories. Category 1 is the hard-decline set. The rule is unambiguous:

“After receiving a Category 1 Decline Response code, a Merchant must never resubmit an Authorization Request or Account Verification for the same Payment Credential.”

Category 1 covers: 04 and 07 (pick up card), 12 (invalid transaction), 14 (invalid account number), 15 (no such issuer), 41 (lost card, pick up), 43 (stolen card, pick up), 46 (closed account), 57 (transaction not permitted to cardholder), and R0/R1/R3 (stop payment and revocation of authorization orders). Issuers are also required to keep sending the same code consistently once they have sent a Category 1 response — so a retry will not produce a different answer.

Categories 2, 3, and 4 permit reattempts, with a stated ceiling:

“Reattempt permitted (up to 20 attempts in 30 days)”

That ceiling is not a target. Stripe’s guidance for the same situation is materially tighter:

“Card networks limit the number of times you can reattempt a single charge. Stripe recommends a maximum of eight retries for charges that permit retries. Card issuers might see creating additional retries as potential fraud, which can result in increased declines for legitimate charges.”

Read those two together: 20 per 30 calendar days is the rule ceiling, 8 is the processor’s practical recommendation, and the gap between them is space where your retry logic can generate fraud signals against your own legitimate charges. Build to the recommendation, not the ceiling.

One code to note if your ruleset was written before this summer: Visa added 83 (Fraud/Security) to Category 2 effective 25 July 2026. If your retry logic enumerates Category 2 codes explicitly, 83 may be missing from it.

Source for the categories and the retry ceiling: Visa Core Rules and Visa Product and Service Rules, Section 7.3.6.3 “Use of Authorization Response Codes,” Table 7-2, ID# 0030640, Edition April 2026. We describe what the published rule says; we do not interpret it on the card network’s behalf.

Decline codes and operational review

Some codes describe lost or stolen cards, stop-payment instructions, or suspected fraud. These meanings inform review and retry handling; they do not establish who attempted a payment or predict a later dispute.

Lost, stolen, and pick-up responses. lost_card (Visa 41), stolen_card (Visa 43), and pickup_card (Visa 04 and 07, where 07 is the fraud-account variant) describe lost, stolen, or pick-up responses. A response does not by itself establish who entered the card details. Review related orders and session evidence before fulfillment where your risk policy calls for it, and preserve the applicable Category 1 retry prohibition.

Stop-payment and revocation instructions. Visa R0, R1, and R3 describe stop-payment or revocation instructions. Do not resubmit when the applicable Category 1 rule prohibits it. These meanings do not establish whether a dispute will follow or how the cardholder first raised the issue. Confirm the actual network response rather than inferring it from a Stripe string.

fraudulent. Stripe uses this code when Stripe suspects fraud. Separately, Visa 59 (Suspected fraud) is issuer-side and 83 (Fraud/Security) is network-side. Those Visa definitions do not prove that either raw code underlies a particular Stripe fraudulent response.

A surge in do_not_honor. Individually, Visa 05 does not disclose a specific decline reason. As a rate change against a stable baseline, it tells you something has shifted — issuer-side risk scoring on your merchant category, a new traffic source with different card quality, or a testing pattern probing your checkout. The signal is in the derivative, not the code.

The practical reading: review a single response in its transaction context and a cluster against a comparable baseline. Check the relevant code meaning, available provider data and review policy before any new attempt or fulfillment; a decline alone does not prove that a later dispute will occur.

For how a dispute proceeds once one is filed, and what evidence windows apply, see https://www.haipay.net/guides/chargeback-process.

What to log so patterns stay visible

You cannot see patterns in fields you did not store. Minimum per declined authorization:

· decline_code — Stripe’s normalized string.

· network_decline_code — the raw code from the card network, where your processor exposes it. This is the field that survives Stripe’s normalization layer. Without it, expired_card and a Category 3 revalidation request are indistinguishable in your logs.

· Timestamp with timezone — retry-window rules are counted in days, and “20 attempts in 30 days” is unauditable against naive local timestamps.

· Card BIN — the issuing bank and card product. Use available issuer identifiers, including a BIN where appropriate, to compare affected issuer segments.

· Retry count and retry parentage — which attempt this was, and which original charge it descends from.

· ARN, once an authorization succeeds and settles — the identifier that lets you tie a later dispute back to this transaction record. See https://www.haipay.net/guides/acquirer-reference-number.

· The layer that declined — gateway, acquirer, or issuer, per the attribution logic above. Store it as a field rather than re-deriving it later.

Store these per attempt, not per order. Collapsing three attempts into one row destroys exactly the retry pattern you would want to audit.

A 24-hour triage runbook: from code to action

Two paths, because a single decline and a rate change are different problems.

Path A — One transaction, one code

1. Identify the layer. Use the provider response and available raw network/advice data to identify the source. Do not infer the layer from a normalized Stripe string alone.

2. Look up the confirmed Visa response category only when the underlying Visa code is available. Category 1 ends the path: do not retry this payment credential, and do not queue it for a nightly retry job either. Categories 2, 3, and 4 continue under the applicable rules and provider guidance. Do not derive a category from the Stripe string alone.

3. For Category 3, revalidate before retrying. These are data-quality codes. Identify the specific returned code and follow the provider’s revalidation instructions before a permitted retry. Request corrected customer-entered information only where those instructions call for it.

4. For Category 2, follow the specific code and provider guidance. Visa describes these as conditions where the issuer cannot approve at that time. Check the actual reason and available advice; waiting alone does not resolve every Category 2 condition.

5. For Category 4, decide on evidence you have, not the code. Visa 05 does not disclose a specific decline reason. Review available provider outcome data, verification results and customer context rather than inferring a cause from 05 alone.

6. Review the code’s operational meaning. Where the response or your review policy requires it, hold fulfillment and review the session. Keep that review decision separate from whether the applicable provider and network rules permit another attempt.

Path B — A batch, a rate change, or a surge

1. Establish the baseline first. A decline rate is meaningless without last week’s number for the same traffic mix.

2. Segment before diagnosing. Split by BIN, issuer country, card product, traffic source, and product SKU. A surge concentrated in one BIN range warrants issuer-specific investigation. For a surge across issuers, investigate checkout changes and traffic mix alongside provider or network incidents; the distribution alone does not establish a cause.

3. Correlate against your own deploy log. Authentication and validation codes moving together after a release are a reason to inspect the integration. Compare provider incidents and traffic mix before attributing the change to that release.

4. Separate the code groups before reviewing a surge. Lost, stolen, pick-up and stop-payment responses have different meanings and retry restrictions from insufficient-funds or limit responses. Review them separately; the code mix alone does not prove third-party use or predict later disputes.

5. Pause automated retries for the affected segment while you diagnose. A retry job running against a surge multiplies the attempt count against the same issuers at exactly the moment they are already declining you.

What not to do

Do not run blind retry loops. The rule ceiling is 20 attempts in 30 calendar days; Stripe recommends a maximum of eight; and Stripe explicitly warns that additional retries “might” be read as potential fraud, “which can result in increased declines for legitimate charges.” A loop that retries to the ceiling is not maximizing recovery — it is generating a signal against itself. Retries also must never touch Category 1 codes at all.

Do not force 3-D Secure across all traffic as a decline fix. Successful 3DS authentication may qualify an eligible fraud dispute for liability shift, but does not guarantee it. A frictionless flow can require no additional customer input; a challenge asks the customer to authenticate. Use 3DS where the applicable flow requires it, and separately resolve data-quality or issuer-limit declines. For implementation checks, see 3D Secure merchant setup and testing.

Do not block a whole BIN because a few transactions declined. A BIN can help segment issuer and card-product patterns. A broad block may exclude legitimate customers as well as the affected attempts. Segment first, and if a BIN genuinely warrants action, scope it to the specific product or amount range that showed the pattern.

Do not treat expired_card as authoritative for subscription cancellation. When the actual Visa response is 54, its Category 3 rule calls for revalidation. Prompt for updated details before you cancel.

To improve approval rates and manage retry, authentication, and dispute workflows systematically, see our payment acceptance guide, 3D Secure guide, and chargeback process guide, or explore HaiPay card acquiring, HaiPay Checkout, and talk to our payments team.

Sources

Stripe: Decline code meanings and next steps; Card declines and network/advice codes; Raw codes by payment network.

Visa: Visa Core Rules and Visa Product and Service Rules, April 2026 — Section 7.3.6.3, Table 7-2, ID# 0030640, for the cited response categories and retry limits; Section 7.3.4.2, ID# 0030580, for the POS timeout rule and Europe exception. Apply the relevant network, region and transaction conditions.