Why Are Customer Payments Being Declined

V3 Why Are Customer Payments Being Declined? Causes, Diagnosis and Solutions for Merchants A customer selects a product, enters their payment details and clicks Pay. Instead of receiving an order confirmation, they see a generic error message or are told that their payment was unsuccessful. For the customer, it is a frustrating interruption. For the merchant, it may appear as a single word in a payment dashboard: Declined. That label rarely tells the full story. A payment can fail because the customer’s bank rejected it, the merchant’s fraud controls blocked it, authentication was not completed, the transaction data was incorrect or a technical problem prevented the request from reaching the issuer. These are different problems with different solutions. A merchant cannot fix an issuer decline by redesigning the checkout. Better payment routing will not help if the customer entered an invalid card number. Retrying a transaction will not solve an authentication flow that does not return the customer to the checkout correctly. Before merchants can reduce payment declines, they need to understand where the transaction failed and what caused the failure. What Is a Payment Decline? A payment decline occurs when a payment request is rejected before the transaction can be completed.

For card payments, the term most commonly refers to an authorization request that reaches the customer’s card issuer but is not approved. However, merchant dashboards sometimes use “declined” more broadly to describe several types of unsuccessful transactions. These may include: * Issuer declines * Merchant fraud-rule rejections * PSP or acquirer rejections * 3D Secure authentication failures * Invalid payment information * Technical processing errors * Customer abandonment during payment * Unsupported cards or transaction types This distinction is important because not every unsuccessful payment reached the issuing bank. A merchant that combines all of these outcomes into a single decline rate may be measuring several unrelated problems at once. How the Card Authorization Process Works A typical online card payment passes through several parties: 1. The customer submits their card and transaction information. 2. The merchant sends the payment request to its gateway, payment service provider or acquirer. 3. Merchant-side and provider-side validation and risk checks may be performed. 4. The authorization request is transmitted through the relevant card network. 5. The card issuer evaluates the request. 6. The issuer approves or declines the transaction. 7. The response returns through the payment chain to the merchant. 8. If approved, the merchant can complete the order and later submit the transaction for clearing and settlement.

For most standard card purchases, the issuing bank makes the final authorization decision. The card network transmits the request and applies network rules, while the acquirer or payment provider connects the merchant to that system. A payment may also require cardholder authentication before authorization can be completed. EMV 3-D Secure allows transaction, device and payment information to be exchanged with the issuer so that the issuer can authenticate the customer. Lower-risk transactions may proceed without a customer challenge, while higher-risk transactions may require a passcode, banking-app approval, biometric check or another authentication step. (EMVCo) Not Every Failed Payment Is an Issuer Decline Merchants should separate payment failures into at least five categories. 1. Issuer declines The payment request reaches the customer’s bank, but the bank does not approve it. Possible reasons include: * Insufficient funds * Available credit limit exceeded * Expired card * Lost or stolen card * Restricted account * Suspected fraud * Unsupported transaction type * Authentication required * International or online payment restrictions * Temporary issuer unavailability The merchant usually receives an authorization response code, but the code may not disclose the issuer’s exact reasoning. 2. Merchant or fraud-system rejections The merchant’s own risk controls may stop a payment before it reaches the issuer. Examples include: * Velocity limits * Device-risk rules * IP-address restrictions

* Country restrictions * Blocked customer accounts * Excessive failed attempts * Mismatched customer information * High-risk transaction patterns These controls help reduce fraud, but overly broad rules can also reject legitimate customers. 3. PSP or acquirer rejections A payment provider or acquiring partner may reject a request because: * Required information is missing * The merchant is not enabled for the transaction type * The card type is unsupported * The transaction currency is unsupported * The selected route is unavailable * The request violates a provider or acquiring rule * The merchant configuration is incomplete * The payment message is incorrectly formatted The issuer may never see these transactions. 4. Authentication failures A customer may fail to complete a 3D Secure or strong customer authentication process. This can happen when: * The customer closes the authentication window * The customer does not recognize the banking prompt * A one-time passcode is not received * The passcode is entered incorrectly * The banking application does not open * The authentication session expires * The browser blocks a redirect or pop-up * The customer cannot return to the merchant checkout * The merchant does not correctly process the authentication result

EMVCo describes 3D Secure as an information exchange between the merchant and issuer that supports cardholder authentication. It also allows issuers to approve lower-risk transactions through a frictionless flow or require additional authentication for transactions judged to need more scrutiny. (EMVCo) 5. Technical failures Some transactions fail before any authorization decision is made. Examples include: * Network timeouts * Provider outages * API errors * Invalid credentials * Expired sessions * Duplicate-payment controls * Incorrect integration logic * Malformed authorization requests * Communication failures between payment systems These should be reported separately from issuer declines. What Are the Most Common Reasons Payments Are Declined? Although the exact mix varies by merchant, market and payment method, several causes appear frequently. Insufficient funds or available credit The customer may not have enough money in the account or sufficient available credit at that moment. This condition may be temporary. For recurring payments, a later retry may succeed after the customer receives funds or makes a payment toward their balance. However, retries should follow the applicable network rules and the specific response received. Some decline responses permit later resubmission, while others indicate that the same payment details should not be tried again.

Visa, for example, classifies authorization responses according to whether the issuer is unlikely ever to approve the payment, cannot approve it at that time or requires corrected transaction data. Its rules limit or prohibit retries for certain response categories. (Visa) Incorrect payment details A payment may be rejected because the customer entered: * The wrong card number * An incorrect expiration date * An incorrect security code * An incomplete billing address * A cardholder name that does not match expected records The customer should be given an opportunity to review the information without being told that the bank declined a transaction that may never have been properly submitted. Expired or replaced cards Stored card credentials may become outdated when: * A card expires * The issuer replaces the card * The card is reported lost or stolen * The account number changes * A customer receives a new card after suspected fraud This is particularly important for subscription businesses and merchants that store payment credentials for future transactions. Supported account-updater services and network-token arrangements can help keep credentials current, but merchants must still follow stored-credential and recurring-payment requirements. Issuer fraud controls Issuers evaluate transactions using their own fraud and risk systems. Their decision may consider factors such as: * Transaction value * Merchant identity * Merchant category * Customer location * Device information * Recent account activity

* Previous spending patterns * Whether the purchase is online or in person * Whether the transaction is domestic or cross-border * Authentication results * The quality and consistency of the authorization data The Federal Reserve has noted that remote card payments represent a disproportionate share of fraudulent card activity compared with their share of overall transactions. This helps explain why issuers apply substantial risk controls to card-not-present purchases. (Federal Reserve) Card or account restrictions The customer’s card may not be enabled for: * Online purchases * International transactions * Recurring billing * High-value purchases * A particular merchant category * A particular country * A particular currency * Cash-like transactions In these cases, the customer may need to contact the issuer or use another payment method. Authentication is required An issuer may require the customer to complete authentication before approving the transaction. This should not always be treated as a final decline. It may be an instruction to initiate 3D Secure, authenticate the customer and resubmit the authorization with the authentication result. When that sequence is not handled correctly, a recoverable payment can become a failed checkout. Temporary issuer or network conditions A payment may also be rejected because the issuer is temporarily unavailable or unable to respond.

In these cases, a carefully timed retry may be appropriate. An immediate series of repeated attempts, however, can create duplicate authorizations, additional fees, poor customer experiences and network-compliance problems. Why Do Banks Decline Legitimate Transactions? Issuing banks must make authorization decisions within seconds. They may have extensive information about the cardholder’s account, but they have limited visibility into what the customer is doing on the merchant’s website. The issuer cannot directly observe the customer’s intent. It must make a decision from the transaction and authentication data it receives. A legitimate transaction may appear unusual because it is: * The customer’s first purchase from the merchant * Much larger than their normal purchases * Made from a new device * Made from a new location * Submitted while the customer is traveling * Processed in a foreign country * Charged in a foreign currency * Associated with an unfamiliar merchant descriptor * Inconsistent with recent account behavior * Missing information the issuer normally receives When a legitimate customer is rejected because the payment is incorrectly assessed as risky, the outcome is commonly described as a false decline. False declines are difficult for merchants to identify at the individual-transaction level because the issuer’s internal decision model is not visible. Merchants can, however, detect patterns by comparing payment performance across: * Issuing banks * BIN ranges * Countries

* Currencies * Card types * Devices * Transaction values * Authentication outcomes * Acquiring routes * New and returning customers Why Are International Card Payments Declined More Often? Cross-border payments can introduce additional complexity into the authorization decision. A transaction may involve: * A customer in one country * A merchant entity in another country * An acquirer in a third country * A foreign transaction currency * Currency conversion * International card controls * Different authentication requirements * Less familiar merchant information * Additional fraud scrutiny This does not mean that every international transaction will be declined or that every domestic transaction will be approved. It means that cross-border transactions may contain additional risk signals or less familiar data. The European Central Bank and European Banking Authority have found substantial differences in fraud exposure between domestic and cross-border card payments. Their 2025 joint report found that card-payment fraud was considerably higher when the payment recipient was outside the European Economic Area, where European strong-authentication requirements did not necessarily apply. (European Central Bank) Because fraud exposure and authorization approval are not the same metric, merchants should not interpret this as proof that every cross-border route will underperform. It does demonstrate why issuers may apply different risk treatment to international transactions.

Can Local Acquiring Reduce Payment Declines? Local acquiring can improve authorization performance in selected markets, but it is not an automatic guarantee. With local acquiring, a merchant processes eligible payments through an acquiring setup in or closely connected to the customer’s market. Depending on the market, this may provide: * Domestic transaction treatment * Local-currency processing * Better compatibility with domestic cards * More familiar merchant information * Market-specific authorization expertise * Support for local authentication practices * Reduced cross-border complexity * Improved access to local payment methods The effect depends on factors including: * Issuer * Card network * Card type * Merchant category * Customer country * Acquirer performance * Transaction data * Fraud profile * Authentication configuration * Merchant legal entity * Local regulations Merchants should measure local and cross-border routes on a comparable basis rather than assume that one will always perform better. What Do Payment Decline Codes Mean? When an issuer rejects an authorization request, it normally returns a response code. Some codes identify a relatively clear problem, such as: * Invalid account number * Expired card * Insufficient funds * Restricted card * Incorrect security code * Transaction not permitted Other responses are deliberately broad.

A generic decline or “do not honor” message may indicate several possible conditions, including suspected fraud, an account restriction or an issuer decision not to disclose more detail. Banks may limit the information returned because providing a precise reason could expose fraud controls or sensitive account information. Merchants should treat decline codes as operational signals rather than complete explanations. The merchant should ideally know: * Which party generated the rejection * Whether the issuer received the request * Whether the response is temporary or permanent * Whether a retry is permitted * Whether authentication is required * Whether the customer must provide new information * Whether a different payment method should be offered * Whether the failure was technical rather than financial What Is the Difference Between a Hard Decline and a Soft Decline? The terms hard decline and soft decline help merchants determine whether a payment may be recoverable. Hard decline A hard decline indicates that retrying the same card information is unlikely to succeed. Examples can include: * Invalid account number * Closed account * Lost or stolen card * Permanently restricted card * Unsupported transaction * Card no longer valid * Issuer instruction not to retry The customer should normally be asked to use another payment method or contact the issuer. Soft decline A soft decline may be temporary or recoverable. Examples can include: * Insufficient funds * Temporary issuer unavailability

* Authentication required * Temporary account restriction * Suspected fraud that the customer can resolve * A response that permits a later retry A soft decline does not mean merchants should repeatedly resubmit the transaction. The appropriate action depends on the response code, payment context and applicable card-network rules. Visa’s published resubmission framework distinguishes between responses that should never be retried, responses that may be retried under limits and responses that require corrected data. (Visa) Why Do 3D Secure Payments Fail? 3D Secure adds an authentication step to help the issuer verify that the person making the payment is the legitimate cardholder. A 3D Secure payment can fail because: * The issuer requires a challenge * The customer does not complete the challenge * The customer enters the wrong passcode * The customer does not receive the passcode * The issuer’s mobile application does not open * The customer cannot switch between applications * The authentication page loads slowly * The authentication session expires * The browser blocks required functionality * The customer does not return to the merchant * The merchant does not correctly process the result * The issuer or authentication service is unavailable

EMV 3DS supports both frictionless and challenged authentication. In a frictionless flow, the issuer evaluates the available data without requiring the customer to take an additional step. For higher-risk transactions, the issuer can request a challenge. (EMVCo) Strong authentication can reduce fraud, but poor implementation can introduce unnecessary friction. The ECB and EBA concluded that strong customer authentication remained effective against the fraud types it was designed to address, particularly for card payments. (European Central Bank) The merchant’s goal should not be to eliminate authentication. It should be to apply authentication correctly and make the experience as clear and reliable as possible. How Merchants Should Diagnose Payment Declines An overall decline rate is useful for monitoring, but it is not enough to diagnose the problem. Merchants should segment unsuccessful transactions by where and why they failed. Segment by failure stage Separate: * Checkout validation errors * Merchant fraud rejections * PSP or acquirer rejections * Authentication failures * Issuer declines * Technical errors * Customer abandonment This tells the merchant whether the payment reached the issuer. Segment by issuer Compare authorization rates by: * Issuing bank * BIN range * Card country * Debit versus credit * Commercial versus consumer card * Domestic versus international card A problem concentrated among a few issuers may require a different response from a broad, market-wide decline problem.

Segment by geography Analyze: * Customer country * Card-issuing country * Merchant entity country * Acquirer country * Transaction currency * Domestic and cross-border routes This can reveal markets where the acquiring or payment-method setup needs improvement. Segment by payment method Compare unsuccessful payments across: * Credit cards * Debit cards * Digital wallets * Bank transfers * Real-time payment systems * Local card schemes * Cash-based payment methods * Buy now, pay later services A card decline may be recoverable when a relevant alternative is available. Segment by authentication result Track: * Authentication attempted * Frictionless authentication * Challenge requested * Challenge completed * Challenge failed * Challenge abandoned * Authorization after successful authentication * Authorization after exemption * Technical authentication errors This can distinguish issuer-risk decisions from customer-experience problems. Segment by processor and acquiring route When multiple processing routes are available, compare performance while controlling for: * Country * Issuer * Card type * Transaction value * Currency * Merchant entity * Authentication status * New or returning customer * Time period * Fraud-risk segment Without comparable transaction groups, routing-performance comparisons can be misleading. Segment by customer type Compare: * New customers * Returning customers * Subscribers * One-time buyers * High-value customers * Customers using stored credentials * Customers purchasing from a new device

This can reveal whether issuer uncertainty or merchant-side fraud rules are affecting particular customer groups. What Metrics Should Merchants Track? Merchants should monitor more than one decline-rate percentage. Useful payment-performance metrics include: * Authorization approval rate * Issuer decline rate * Merchant rejection rate * Provider rejection rate * Technical failure rate * Payment conversion rate * Authentication success rate * 3D Secure challenge rate * Challenge completion rate * Customer abandonment during payment * Retry recovery rate * Approval rate by country * Approval rate by issuer * Approval rate by payment method * Approval rate by processor or acquirer * Approval rate for new and returning customers * Fraud rate * Chargeback rate * Refund rate * Cost per successful payment These metrics should be evaluated together. For example: * Loosening fraud controls may increase approvals but also increase fraud. * Requiring more authentication may reduce fraud but increase abandonment. * Routing to a higher-approval provider may also increase processing costs. * Increasing retries may recover revenue but create unnecessary fees or network violations. * Adding payment methods may improve conversion but increase operational complexity. Payment optimization requires balancing revenue, risk, customer experience, compliance and cost. How Can Merchants Reduce Payment Declines? Once the source of the problem is understood, merchants can apply the appropriate improvement.

Improve transaction-data quality Issuers make better decisions when authorization requests contain accurate and consistent information. Depending on the payment type, merchants should review: * Cardholder information * Billing information * Merchant descriptors * Merchant category configuration * Stored-credential indicators * Recurring-payment indicators * Merchant-initiated transaction indicators * Authentication results * Device and transaction information * Currency and amount formatting * Network-token information * Previous-transaction references More information is not automatically better. The information must be accurate, relevant and formatted correctly. Configure 3D Secure correctly The payment flow should be able to: * Recognize when authentication is required * Initiate the correct authentication process * Support both frictionless and challenged flows * Display the challenge clearly * Handle banking-app authentication * Return the customer to checkout * Record the authentication result * Resubmit authorization correctly * Handle expired or failed sessions * Support recurring and off-session scenarios appropriately EMVCo publishes specifications and user-experience guidance intended to support secure and consistent 3D Secure implementations. (EMVCo) Use local acquiring strategically Merchants should test whether local acquiring improves approval rates in priority markets. The comparison should account for: * Customer country * Issuer * Card type * Transaction currency * Authentication status

* Merchant entity * Fraud levels * Processing cost Local acquiring is most valuable when it produces a measurable improvement in completed payments, not simply because it is available. Add locally relevant payment methods In many countries, customers may prefer a domestic wallet, bank-transfer method, real-time payment system or local card scheme over an international card. Offering relevant alternatives can: * Give declined customers another path to payment * Serve customers without internationally enabled cards * Reduce dependence on one payment rail * Increase checkout familiarity * Support market-specific buying behavior * Reduce the impact of card-issuer decisions The correct payment-method mix should be based on the merchant’s customers rather than a generic global list. Route transactions using performance data Merchants with multiple acquiring connections may be able to select routes based on: * Issuer country * Card type * Currency * Merchant entity * Transaction value * Historical approval performance * Provider availability * Processing cost * Regulatory requirements * Fraud exposure Routing decisions should use recent, comparable data. Historical approval rates alone do not guarantee that a particular route will be best for every transaction. Build a compliant retry strategy Retries are especially important for subscriptions and recurring payments. A good retry strategy considers: * The original decline response * Whether the decline is recoverable * Whether authentication is required

* Applicable network rules * Customer billing patterns * Likely timing of available funds * Number of attempts * Time between attempts * When to request a new payment method * When to stop retrying Merchants should not retry permanent declines or repeatedly resubmit unchanged payment data when the response requires a correction. Improve the customer’s recovery experience The message shown after a failed payment should help the customer take the next appropriate action. Depending on the failure, the merchant can ask the customer to: * Check the card details * Complete authentication * Try again later * Contact the issuing bank * Use another card * Select a different payment method * Update an expired card * Return to the banking application * Confirm that online or international payments are enabled A generic “payment failed” message gives the customer no reason to believe that another attempt will succeed.

Local payment-method coverage

This coverage gives customers alternatives when an international card is unavailable, unsupported or declined. Local acquiring in selected markets

Transaction routing and performance monitoring

This can help merchants identify: * Markets with unusually high decline rates * Issuers that underperform on particular routes * Payment methods customers use successfully * Authentication flows causing abandonment * Technical failures being counted as declines * Opportunities to offer a different payment path Fraud controls and transaction review Fraud management must prevent abuse without blocking an unnecessary number of legitimate customers.

Reporting and transaction visibility Merchants need transaction-level information to distinguish issuer declines, authentication problems, risk rejections and technical failures.

Payment Declines Are a Set of Problems, Not One Metric Merchants cannot control every issuer decision. They can control: * How unsuccessful payments are classified * The quality of transaction data * How authentication is implemented * Which acquiring routes are used * Which payment methods are offered * How fraud rules are configured * How retries are managed * What customers see after a failure * How performance is measured The most useful question is not simply: Why was the payment declined? It is: Where did the payment fail, what signal caused the outcome and what action should be taken next? Once a merchant can answer those questions consistently, payment declines stop being an unexplained cost of doing business. They become a collection of measurable problems that can be investigated, prioritized and reduced. Frequently Asked Questions About Payment Declines Why is my customer’s card being declined? A card may be declined because of insufficient funds, an expired card, incorrect payment details, an issuer fraud alert, account restrictions, an authentication requirement or a temporary issuer problem. The merchant should first determine whether the request reached the issuing bank. A merchant-side rejection, technical error or authentication failure may appear similar to an issuer decline but requires a different response. Who decides whether a card payment is approved? For most standard card purchases, the customer’s issuing bank makes the final authorization decision.

The merchant, fraud provider, payment processor or acquirer may also reject the transaction before it reaches the issuer. The card network transmits authorization messages and applies network rules. What does “do not honor” mean? “Do not honor” is a general issuer response indicating that the bank did not approve the transaction. It does not always disclose the exact reason. The customer may need to contact the issuer or use another payment method. Merchants should avoid repeatedly retrying the same transaction unless the response and applicable rules permit it. What is the difference between a payment decline and a payment failure? A payment decline normally means that a party in the payment chain rejected the transaction. A payment failure is a broader term that can also include technical errors, authentication failures, invalid information and customer abandonment. Not every failed payment reached the issuer. What is a soft decline? A soft decline is a potentially temporary or recoverable rejection. Examples may include insufficient funds, temporary issuer unavailability or authentication required. The correct recovery action may be a later retry, completion of authentication or a request for another payment method. What is a hard decline? A hard decline indicates that retrying the same payment details is unlikely to succeed.

Examples can include an invalid account, closed account, lost or stolen card or an issuer instruction not to retry. The customer should generally use another payment method or contact the bank. Should merchants retry declined payments? Only some declined payments should be retried. Merchants should consider the authorization response, card-network rules, whether data must be corrected and whether authentication is required. Permanent declines should not be retried with unchanged card information. Can a declined card be charged again later? Possibly. A later attempt may succeed when the original decline was temporary, such as insufficient funds or temporary issuer unavailability. It is unlikely to succeed when the card is invalid, closed, stolen or permanently restricted. Recurring merchants should use a structured retry schedule rather than retrying every decline in the same way. Why are online card payments declined? Online payments can receive more fraud scrutiny because the card and customer are not physically present at the merchant. Issuer decisions may consider device information, customer location, transaction history, authentication data and whether the purchase is unusual for the cardholder. Why are international payments declined?

International payments may be declined because the card does not support foreign transactions, the issuer considers the transaction unusual, the merchant or acquirer is in another country, the currency is unfamiliar or the transaction triggers additional fraud controls. The customer may need to enable international payments, contact the bank or use a local payment method. Does local acquiring improve authorization rates? Local acquiring can improve approval rates in some markets, but the result depends on the issuer, acquirer, card type, transaction data, merchant setup and local payment environment. Merchants should compare local and cross-border routes using equivalent transaction groups. Why does 3D Secure authentication fail? 3D Secure can fail because the customer abandons the challenge, does not receive a passcode, enters the wrong information, cannot open the banking application, encounters a timeout or cannot return to checkout. It can also fail because of integration or issuer-system problems. Does 3D Secure reduce payment declines? Correctly implemented 3D Secure can give issuers greater confidence in the customer’s identity and may help some transactions receive approval. However, authentication cannot solve every decline. It will not fix insufficient funds, an invalid card or a restricted account. Poorly implemented authentication may also increase checkout abandonment. Can merchants see the exact reason a bank declined a payment? Not always.

The issuer returns an authorization response code, but some codes are intentionally broad. The exact internal fraud or account decision may not be disclosed to the merchant. Merchants usually need to combine decline codes with transaction patterns, issuer data, authentication results and processing-route information. How can merchants reduce false declines? Merchants can work to reduce false declines by: * Sending accurate transaction data * Configuring authentication correctly * Reviewing overly broad fraud rules * Comparing performance by issuer and market * Using suitable acquiring routes * Applying compliant retry logic * Offering locally relevant payment methods * Giving customers clear recovery options No single change will eliminate all false declines. What should merchants show customers after a decline? The message should reflect the action the customer can take without exposing sensitive issuer information. Useful instructions may include: * Check your payment details * Complete the authentication request * Contact your bank * Try again later * Use another card * Select another payment method The message should not blame the customer or claim to know the issuer’s exact reasoning when that information is unavailable. What is a good card approval rate? There is no universal approval-rate benchmark that applies to every merchant. Approval rates vary by: * Country * Industry * Customer type * Transaction value * Card mix * Recurring versus one-time billing * Domestic versus international processing

* Fraud exposure * Authentication requirements * Acquiring setup Merchants should establish benchmarks by market and transaction segment rather than rely on one global percentage. How do alternative payment methods reduce lost sales? Alternative payment methods give customers another way to pay when a card is unavailable, unsupported or declined. Depending on the country, this may include a local wallet, bank transfer, real-time payment method, domestic card scheme or cash-based payment option. The alternative should be relevant to the customer’s market and purchasing behavior. What data should merchants review when payment declines increase? Merchants should review: * Failure stage * Decline response * Issuer * BIN * Card country * Customer country * Payment method * Acquiring route * Currency * Authentication result * Fraud-rule outcome * Device * Transaction value * Technical error logs * New versus returning customers A sudden increase concentrated in one provider, issuer, market or software release is more actionable than a single aggregate decline-rate change.

Suggested SEO title: Why Are Customer Payments Being Declined? Causes and Solutions Suggested meta description: Learn why customer payments are declined, how card authorization failures occur, what decline codes mean and how merchants can improve payment approval rates.

Above is the rebuilt version. It removes competitor citations, distinguishes declines from other payment failures, adds merchant-focused diagnostic guidance, and includes an FAQ designed around relevant search queries.

V2 I corrected several important issues in the original: not every failed payment is technically a decline; card networks usually transmit authorization messages rather than independently approving ordinary purchases; local acquiring can improve performance but does not automatically make a transaction “lower risk”; and chargeback win rates are not directly relevant to authorization declines. Why Are Customer Payments Being Declined? A customer chooses a product, enters their payment details and selects Pay. Instead of receiving confirmation, they see a generic error message, a request to try again or no clear explanation at all. To the merchant, the transaction may appear in a dashboard simply as declined. But that label can conceal several very different outcomes. The payment may have been rejected by the customer’s bank. It may have been blocked by the merchant’s fraud controls. Authentication may not have been completed. The request may even have failed before it reached the issuer. These distinctions matter because each problem requires a different response. A merchant cannot solve an issuer decline by redesigning the checkout, just as changing acquirers will not help a customer who abandoned a 3D Secure challenge. The first step toward recovering more revenue is identifying where—and why—the payment failed. Not Every Failed Payment Is a Decline

Merchants often use the word “decline” to describe any unsuccessful payment. Technically, however, several different events can prevent a transaction from being completed. Issuer decline The customer’s card-issuing bank receives the authorization request but decides not to approve it. Possible reasons include: * Insufficient funds or available credit * An expired, restricted or blocked card * A suspected fraud risk * A transaction type that the card does not support * A bank restriction on online, recurring or international purchases * A requirement for additional customer authentication For most card transactions, the issuer makes the final authorization decision. Merchant, acquirer or PSP rejection A merchant’s fraud system, payment service provider or acquiring partner may block a transaction before it is submitted to the issuer. This can happen when: * A fraud rule is triggered * Required transaction information is missing * The payment request is incorrectly formatted * The merchant or payment type is not supported * The selected processing route is unavailable * The provider applies its own risk restrictions These transactions may appear alongside issuer declines in merchant reporting, even though the issuing bank never evaluated them. Authentication failure A transaction may require 3D Secure or another form of customer authentication. The payment can fail when: * The customer does not complete the challenge * The customer enters an incorrect one-time code

* The banking application or authentication page does not load * The authentication session expires * The merchant does not correctly handle an issuer request for authentication An authentication failure is not always the same as a conventional authorization decline. In some cases, the issuer is asking the merchant to authenticate the customer before resubmitting the payment. (Stripe Docs) Technical failure Some payments fail without receiving an authorization decision at all. Examples include: * Network timeouts * Provider outages * Invalid API requests * Expired credentials * Integration errors * Duplicate transaction controls * Communication failures between payment systems A useful merchant reporting system should separate these events from genuine issuer declines. How a Card Authorization Normally Works In a typical online card transaction: 1. The customer submits their card and payment information. 2. The merchant sends the request to its payment gateway, PSP or acquirer. 3. Merchant-side and provider-side checks may be performed. 4. The request travels through the relevant card network. 5. The issuing bank evaluates the transaction. 6. The issuer returns an approval or decline response. 7. The response travels back to the merchant. The card network establishes operating rules and carries authorization messages between participants. However, for a standard card purchase, it is generally the issuer—not the card network—that decides whether the customer’s account should be authorized.

This is why merchants need to know whether a transaction: * Never reached the issuer * Reached the issuer and was declined * Required authentication * Failed because of a technical problem * Was abandoned by the customer Treating all five outcomes as one decline rate makes meaningful optimization difficult. The Most Common Reasons Issuers Decline Payments Insufficient funds or credit The customer may not have enough available balance or credit at the time of purchase. For recurring merchants, this can be temporary. The customer may receive funds later, pay down the account or have credit restored. A carefully timed retry may therefore succeed. Retries should not be indiscriminate. Card-network rules distinguish between decline categories and may restrict when and how merchants resubmit declined transactions. Visa, for example, groups authorization responses into categories that indicate whether a transaction should not be retried, may be retried later or needs corrected data. (Visa) Incorrect or outdated card information Payments can be rejected because of: * An incorrect card number * An invalid expiration date * An incorrect security code * An outdated card stored for recurring billing * A card that has been replaced, lost or reported stolen Merchants with recurring payments should use supported stored-credential practices and, where available, account-updater or network-token services to reduce failures caused by outdated credentials. Issuer fraud controls

Issuers score transactions using information such as: * Transaction amount * Merchant identity and category * Customer location * Device and behavioral signals * Purchasing history * Whether the payment is domestic or cross-border * Whether authentication was completed * The consistency and completeness of authorization data A legitimate payment can be declined when the issuer does not have enough confidence that the cardholder initiated it. These are commonly described as false declines. Mastercard notes that legitimate transactions may be rejected because of fragmented data, inconsistent authorization signals and limited visibility across the payment ecosystem. (Mastercard) Transaction restrictions The customer’s bank or card may restrict certain types of purchases, including: * International payments * Online payments * Recurring transactions * High-value purchases * Particular merchant categories * Transactions in certain countries * Cash-like or other restricted transaction types In many of these cases, only the customer or issuer can remove the restriction. The merchant should provide a clear message encouraging the customer to contact their bank or choose another payment method. Authentication is required An issuer may decline an initial authorization because authentication is required. This is often a recoverable event rather than a final rejection.

The merchant or PSP should recognize the response, initiate the correct 3D Secure flow and resubmit the transaction after successful authentication. Failing to handle this sequence correctly can turn a potentially recoverable payment into a lost sale. (Stripe Docs) Why Legitimate Customers Are Sometimes Declined Issuers must make authorization decisions in seconds. They usually have more information about the cardholder than the merchant, but less information about the customer’s intent on the merchant’s website. That creates uncertainty. A legitimate payment may look unusual because it is: * The customer’s first purchase from the merchant * Larger than their normal purchases * Made from a new device or location * Submitted while the customer is traveling * Processed in a foreign country or currency * Associated with an unfamiliar merchant name * Missing information the issuer normally expects A decline does not necessarily mean the customer lacks funds or that the transaction is fraudulent. It may mean that the issuer did not receive enough reliable information to approve the transaction confidently. Merchants cannot see an issuer’s internal fraud model. They can, however, identify patterns by examining authorization performance across issuers, BIN ranges, countries, devices, payment methods, transaction types and acquiring routes. Why Cross-Border Payments Can Be More Difficult International card payments often involve more variables than domestic transactions. These can include:

* A merchant and cardholder in different countries * Currency conversion * Foreign transaction controls * Less familiar merchant information * Different authentication requirements * Additional intermediaries * Regional differences in card usage * Greater fraud sensitivity for certain corridors For these reasons, merchants may see lower approval rates in some cross-border markets. However, it is too broad to assume that every locally acquired transaction will outperform every cross-border transaction. Performance depends on the issuer, acquirer, card network, transaction data, merchant category, fraud profile and market. Local acquiring can improve authorization performance in appropriate markets by: * Presenting the transaction through a familiar domestic acquiring setup * Supporting local currency processing * Reducing some cross-border complexity * Improving compatibility with local authorization practices * Providing access to more relevant local payment expertise The effect should be measured by market and issuer rather than assumed. Why Decline Codes Do Not Always Reveal the Exact Cause When an issuer declines a card payment, it returns an authorization response code. Some codes are relatively specific, while others provide only limited information. A generic response can represent several possible conditions. The merchant may receive an instruction such as: * Do not honor * Generic decline * Transaction not permitted * Contact issuer * Try again later

The exact reason may not be disclosed to the merchant, particularly when revealing it could create security or fraud risks. Payment providers may translate network responses into their own decline codes, but the underlying issuer response can still be broad. Merchants should therefore use decline codes as operational signals—not always as complete explanations. The most useful systems combine the code with other information, such as: * Whether the issuer received the transaction * Whether authentication was requested * Whether a retry is permitted * Which processor and route were used * The issuer and card country * Whether required transaction data was present * Whether the failure was technical, merchant-generated or issuer-generated Hard Declines and Soft Declines A practical way to organize issuer declines is to separate them into hard and soft declines. Hard declines A hard decline indicates a condition that is unlikely to be resolved by immediately retrying the same payment details. Examples may include: * Invalid account number * Closed account * Lost or stolen card * Permanently restricted card * Transaction type not permitted The appropriate response is usually to ask the customer to use another payment method or contact their issuer. Soft declines A soft decline may be temporary or recoverable. Examples may include: * Insufficient funds * Authentication required * Temporary issuer unavailability * Suspected fraud that the customer can resolve * A temporary processing restriction

* A response instructing the merchant to retry later The correct response depends on the specific code and card-network rules. A merchant should not repeatedly resubmit every declined transaction. Poor retry practices can increase costs, create a bad customer experience and violate network requirements. How Merchants Should Diagnose Declines An aggregate decline rate is a starting point, not a diagnosis. Merchants should segment unsuccessful payments across several dimensions. By failure stage Separate: * Merchant-side rejections * PSP or acquirer rejections * Authentication failures * Issuer declines * Technical errors * Customer abandonment This is the most important distinction. A payment that never reached the issuer should not be analyzed as an issuer authorization problem. By country and transaction corridor Compare: * Customer country * Card-issuing country * Merchant entity country * Acquirer country * Transaction currency * Domestic and cross-border routes This can reveal markets where the current processing setup is underperforming. By issuer and BIN Look for issuing banks or BIN ranges with unusually low approval rates. A concentrated problem may indicate: * Poor authorization data * An issuer-specific fraud concern * Routing underperformance * Authentication problems * Incorrect merchant configuration * A high-risk customer or transaction segment By decline code Track the share of declines associated with: * Insufficient funds * Generic issuer declines * Invalid credentials * Restricted transactions

* Suspected fraud * Authentication requirements * Temporary issuer problems Also distinguish between responses that permit a retry and those that should not be resubmitted. By payment method Compare cards with: * Bank transfers * Digital wallets * Real-time payment methods * Local debit systems * Cash-based methods * Buy now, pay later options A card authorization problem does not have to result in a lost customer when an appropriate alternative is available. By authentication outcome Measure: * Frictionless authentication success * Challenge rates * Challenge completion rates * Authentication failures * Customer abandonment during authentication * Authorization rates following successful authentication A high challenge rate is not automatically bad, but unnecessary or poorly implemented challenges can reduce completed payments. By processor, acquirer and route For merchants using more than one processing path, compare results on a like-for-like basis. Control for: * Country * Issuer * Card type * Transaction amount * Currency * Customer type * Authentication status * Merchant entity * Time period Without these controls, one route may appear to perform better simply because it receives easier transactions. What Can Improve Payment Approval Rates? There is no single fix for every decline. The best approach depends on the source of the problem. Improve authorization data Complete, accurate and consistent authorization messages can help issuers make better decisions.

Depending on the transaction, useful data may include: * Correct merchant and billing information * Accurate stored-credential indicators * Recurring or merchant-initiated transaction indicators * Authentication results * Appropriate merchant category information * Device, customer and transaction data supported by the provider * Consistent merchant descriptors * Network-token or account-updater information More data is not automatically better. The information must be accurate, relevant and formatted correctly. Configure authentication correctly Merchants should ensure that their payment flow can: * Recognize when authentication is required * Launch the appropriate 3D Secure experience * Handle frictionless and challenged flows * Return the customer to checkout correctly * Resubmit the authorization with the authentication result * Manage off-session and recurring payments appropriately The objective is not simply to minimize authentication. It is to apply it correctly while reducing avoidable customer friction. Use local acquiring where it improves performance Local acquiring may improve results in selected markets, particularly when it supports: * Domestic processing * Local currencies * Local card types * Relevant authentication requirements * Better issuer connectivity * Market-specific authorization practices Merchants should validate the improvement using transaction-level testing and reporting. Offer locally relevant payment methods

Customers may prefer a domestic wallet, bank-transfer system or local card scheme over an international credit card. Providing appropriate alternatives can: * Give customers another way to complete the purchase * Reduce dependence on a single payment rail * Improve familiarity and trust at checkout * Serve customers who do not have internationally enabled cards The right payment-method mix varies significantly by country, audience and transaction type. Route transactions intelligently Merchants with access to multiple acquiring paths may be able to route transactions according to factors such as: * Issuer country * Card type * Currency * Merchant entity * Transaction value * Historical performance * Provider availability * Regulatory requirements * Processing cost Routing should be based on reliable, current performance data. Simply sending a declined transaction to another processor is not always allowed or effective. Develop a compliant retry strategy Retries are particularly important for subscriptions and other recurring payments. A good retry strategy considers: * The original decline reason * Whether the decline is recoverable * Network retry rules * The customer’s billing cycle * The likely timing of available funds * Whether authentication is required * The number and spacing of attempts * When to request a new payment method Repeatedly attempting a permanently invalid card creates costs without improving recovery. Improve the customer experience after a decline

The message shown to the customer should help them recover without exposing sensitive issuer information. Depending on the response, the checkout can recommend that the customer: * Check their payment details * Complete authentication * Try again later * Contact their bank * Use another card * Select a local payment method * Update an expired payment credential “Payment failed” is rarely enough. The Metrics Merchants Should Track To understand whether decline optimization is working, merchants should monitor more than the approval rate alone. Important metrics include: * Authorization approval rate * Payment conversion rate * Issuer decline rate * Merchant or fraud-rejection rate * Technical failure rate * Authentication success rate * 3D Secure challenge rate * Challenge completion rate * Retry recovery rate * Approval rate by issuer and country * Approval rate by acquirer and route * Approval rate by payment method * Customer recovery after an initial failure * Fraud and chargeback rates after approval These metrics should be considered together. For example, loosening fraud controls may increase short-term approvals while also increasing fraud losses. Requiring more authentication may reduce fraud but increase abandonment. Optimizing payments means balancing conversion, risk, cost and customer experience—not maximizing one number in isolation.

Local and alternative payment-method coverage

This gives merchants alternatives when international cards are unavailable, unsupported or repeatedly declined. Transaction routing and payment optimization

Fraud screening with human review

Transaction-level reporting Merchants need enough visibility to distinguish issuer declines from authentication problems, provider rejections and technical failures.

Dispute support after authorization Disputes occur after a transaction has been authorized and are therefore a separate issue from declines. However, they remain part of the wider balance between acceptance and risk.

A Decline Rate Is Not an Unavoidable Cost Merchants cannot control every issuer decision. They can control how clearly unsuccessful payments are classified, how much information reaches the issuer, how authentication is handled, which processing routes are used and which payment alternatives are offered. The most important question is not simply: Why was the payment declined? It is: Where did the payment fail, what signal caused that outcome and what action is appropriate for that specific type of failure? Once merchants can answer those questions consistently, payment declines stop being a single unexplained dashboard number. They become a set of measurable problems that can be investigated, prioritized and reduced. This version is structured as a merchant-facing educational article and leaves natural opportunities for later links to decline codes, authentication, local acquiring, payment routing, retries and alternative payment methods.

v1 Why Are Customer Payments Being Declined? A customer adds an item to their cart, enters their card details, and hits pay. Nothing happens — or worse, they see a generic error and leave. From the merchant's side, this looks like a single line in a dashboard: declined. But that one word is hiding a chain of decisions made by several different parties, most of which the merchant never sees. Understanding where in that chain a payment actually failed is the first step to recovering revenue that's currently being written off as "customer error." A decline is not one thing Every declined payment has passed through, and been rejected by, one of several distinct checkpoints: * The issuing bank — the customer's own bank, deciding whether to authorize the charge * The card network — Visa, Mastercard, and others, enforcing rules on the transaction * The acquirer or PSP — the merchant's payment processor, applying its own risk logic * The authentication layer — 3D Secure or similar, verifying the customer is who they say they are A decline can originate at any of these points, and each one produces a different downstream problem. Lumping them together as "the payment failed" is why so many merchants end up guessing at fixes instead of targeting them. (For the full breakdown of what these rejections look like in practice, see Soft Declines vs. Hard Declines and Understanding Payment Decline Codes.) The most common reasons payments get declined

Issuer-side reasons — these come from the customer's own bank and are the most frequent category: * Insufficient funds or credit limit reached * Card expired or details entered incorrectly * The issuer's fraud model flags the transaction as suspicious, even when it's legitimate * The customer's bank blocks international or online transactions by default Network and scheme-level reasons: * The transaction violates a card network rule (unusual amount, mismatched currency, invalid merchant category code) * Recurring billing without proper network tokenization Acquirer or PSP-side reasons: * The processor's own risk rules reject the transaction before it reaches the issuer * Routing sends the transaction through an acquirer with weak approval rates for that card type or region * Technical failures — timeouts, malformed requests, expired credentials Authentication-related reasons: * The customer abandons or fails a 3D Secure challenge * The customer never receives their one-time authentication code * Frictionless authentication isn't available for that issuer or region, forcing an unnecessary challenge flow Merchants often treat all of these as one undifferentiated "decline rate," when in reality each cause needs a different fix — better routing addresses PSP-side issues, but it does nothing for a customer whose bank never sent an authentication code. Why issuers decline legitimate customers

Not every decline reflects real risk. Issuing banks apply their own fraud scoring independent of the merchant's own controls, and that scoring is frequently over-cautious — particularly for: * Cross-border transactions, where the issuer has less context on the merchant * First-time purchases from a new customer * Transactions that don't match the cardholder's typical spending pattern This is a false decline: a good customer, a legitimate purchase, rejected anyway. Because the issuer's logic is opaque to the merchant, false declines are difficult to detect without comparing authorization rates across different acquiring paths and geographies. (See Why Issuers Decline Legitimate Customers and Authorization Rate vs. Payment Conversion Rate for how to isolate this from genuine fraud rejections.) Domestic transactions succeed more often than cross-border ones A card transaction processed by a bank in the customer's own country is generally seen as lower-risk by the issuer than the same transaction routed through a foreign acquirer. This is one of the most consistent patterns in payment data: the further a transaction travels from the customer's home market, the more likely it is to be declined — independent of whether the purchase itself is legitimate.

This is why merchants selling into 190+ markets can see wildly different approval rates by country even when the product, price point, and customer intent are identical. Local acquiring exists specifically to correct for this. (More detail in Why International Cards Are Declined More Often and Domestic vs. Cross-Border Acquiring.) Why decline codes rarely tell the full story Card networks and issuers return decline codes with each rejected transaction, but these codes are often deliberately vague — "do not honor" is the most common response across all networks, and it can mean anything from insufficient funds to a fraud flag to a full account freeze. Because banks are not required to disclose the exact reason, merchants are often left inferring the cause from patterns rather than reading it directly off the response. (See Why Vague Decline Codes Make Optimization Difficult.) How to start diagnosing your own decline rate Before assuming a decline problem is a fraud problem, or a technical problem, or a customer problem, it's worth segmenting the data: 1. By geography — are decline rates concentrated in specific countries or regions? 2. By card type and issuer — are certain BINs or issuing banks declining at a higher rate? 3. By payment method — are card declines materially different from local payment method declines? 4. By authentication step — how many declines happen before vs. during 3D Secure?

5. By acquirer or routing path — if multiple PSPs or acquiring paths are in use, does approval rate vary between them? A decline problem that looks uniform at the aggregate level is very rarely uniform once it's broken down this way. What actually moves the number Once the cause is isolated, the fix is usually one of a small number of levers: * Local acquiring in the customer's own market, which issuers treat as materially lower-risk than cross-border processing * Payment method diversity — offering the local methods customers already trust, rather than relying on international cards alone * Smarter routing across acquiring paths, so a transaction likely to fail with one processor is sent through another * Cleaner authentication configuration, reducing unnecessary 3D Secure challenges without losing required security coverage * Better transaction data quality, since incomplete or inconsistent data going to the issuer increases the odds of a defensive decline None of these are guesswork fixes — they're structural changes to how a transaction reaches the issuer in the first place.

* Local acquiring across 190+ markets, reducing the cross-border risk signal that drives a large share of issuer-side declines * 200+ local payment methods, so a decline on card doesn't have to mean a lost sale — customers can complete the purchase through a method their bank already trusts * Managed dispute resolution with a 78% chargeback win rate, so the transactions that do go to dispute after authorization are handled with a track record the merchant can actually verify * Consolidated visibility across acquiring paths, so merchants can see where in the chain a decline actually happened instead of treating it as a single undifferentiated number Understanding why a payment failed is what turns a decline rate from a cost of doing business into something a merchant can actively reduce.

Internal links to build once corresponding pages are live: Soft Declines vs. Hard Declines · Understanding Payment Decline Codes · Why International Cards Are Declined More Often · Why Issuers Decline Legitimate Customers · Authorization Rate vs. Payment Conversion Rate · Domestic vs. Cross-Border Acquiring · Why Vague Decline Codes Make Optimization Difficult. Figures used: 190+ markets, 200+ local payment methods, 78% chargeback win rate — all per current canonical figures. No unverified merchant-count or user-count claims used in this draft. Title Why Are Customer Payments Being Declined? Url /solve/customers-cant-pay/payment-declines/why-payments-are-declined/ Pillar Customers Can't Pay Cluster A — Payment declines Meta_description Card declines cost merchants revenue they never see in a chargeback report. Here's what's actually happening when a payment fails — and where to look first. Status draft — canonical figures verified against current site copy; no unverified claims used