Why Are Customer Payments Being Declined?
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 ap
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:
The customer submits their card and transaction information.
The merchant sends the payment request to its gateway, payment service provider or acquirer.
Merchant-side and provider-side validation and risk checks may be performed.
The authorization request is transmitted through the relevant card network.
The card issuer evaluates the request.
The issuer approves or declines the transaction.
The response returns through the payment chain to the merchant.
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.
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.
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.
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.
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)
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:
The customer submits their card and payment information.
The merchant sends the request to its payment gateway, PSP or acquirer.
Merchant-side and provider-side checks may be performed.
The request travels through the relevant card network.
The issuing bank evaluates the transaction.
The issuer returns an approval or decline response.
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:
By geography — are decline rates concentrated in specific countries or regions?
By card type and issuer — are certain BINs or issuing banks declining at a higher rate?
By payment method — are card declines materially different from local payment method declines?
By authentication step — how many declines happen before vs. during 3D Secure?
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.
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
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
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗