Transaction Failed: Common Causes, Decline Types and How to Fix Them

A transaction fails when a payment attempt is not completed because the issuer or acquirer declines it, a technical error interrupts processing, or a risk rule blocks it. A payment can also fail during authentication if 3D Secure or Strong Customer Authentication is required but not completed successfully.

For merchants, failed transactions can mean lost sales, additional costs from repeated attempts, and customers who abandon the purchase or do not return. This guide explains the main reasons for transaction failure, the difference between soft and hard declines, common decline codes, which failures can be recovered through cascading, failover or retries, and how payment teams can reduce them.

What Is Transaction Failure?

The term failed transaction indicates a payment on a merchant’s website or application that was not processed successfully. The percentage of transaction failure over a specific timeframe serves as an indicator of potential issues that merchants should address.

However, not every failed transaction is a decline. Payment teams should distinguish between three outcomes:

• Failed transaction: any payment attempt that did not complete successfully.
• Declined transaction: the issuer or acquirer returned a refusal with a response code, even when the reason is temporary, such as an issuer that is briefly unavailable.
• Transaction error: no authorization response came back at all, because the request timed out, the connection failed, the provider was down, or the request was rejected before it reached the issuer.

This distinction matters because it determines whether a retry makes sense and what, if anything, should change before the next attempt.

Why Do Transactions Fail?

A card payment can be stopped at several points in the payment flow. The issuer or acquirer can decline authorization, the card network or payment provider can become unavailable, fraud rules at the gateway or payment orchestration layer can block the request, or the 3DS authentication step can fail.

The label “transaction failed” has two primary grounds behind it: soft declines and hard declines. Technical errors are a separate third category: no authorization response comes back, so there is no decline to interpret.

Hard decline occurs when the customer’s issuing bank rejects the payment due to non-negotiable reasons such as card expiration, invalid card number, or a reported stolen card. This type of transaction problem is definitive and permanent, meaning the transaction is unsuccessful under any conditions.

A soft decline, by contrast, is temporary. Typical reasons include insufficient funds, a generic issuer refusal, authentication required, spending or velocity limits, or an issuer that is temporarily unavailable. Once the underlying issue changes, or when the payment is sent through another eligible acquirer, the transaction may become approvable.

Failed Transaction: Main Reasons

Failed transactions most commonly originate from issuer decisions, fraud and risk controls, provider availability, technical problems, authentication, or provider-specific restrictions. Identifying which category caused the failure determines whether the payment is recoverable and what the payment team should do next.

According to Accuity, a LexisNexis Risk Solutions company, failed payments cost the global economy $118.5 billion in fees, labor and lost business in 2020.

Payments Declined by Card Issuers

If the card issuer declines the transaction, there is little, if anything, the merchant can do to proceed with the transaction under the same conditions. There are several reasons why an issuing bank may refuse a payment. They include:

1. Insufficient funds: lack of funds in the customer’s account to cover the purchase.
2. Incorrect payment information: incorrect details, such as account numbers, card numbers, or wallet addresses.
3. Expired payment method: the customer’s payment method has become invalid.
4. Transaction limits: the customer’s payment limit was exceeded.
5. Account closure: the bank account or payment account linked to a digital payment system is closed or inactive.

For card payments, the issuer returns a response code that helps the payment team understand why authorization was refused and whether another attempt is appropriate. The most common codes are explained below.

Potentially Fraudulent Activity and False Declines

With the rise of online fraud, banks and payment processors take extensive fraud prevention measures to identify suspicious activity beforehand. However, anti-fraud methods can be a two-edged sword, occasionally resulting in legitimate transactions being declined.

A false decline occurs when a genuine payment is refused because an issuer risk model or the merchant’s own fraud rules classify it as suspicious. Common triggers include a new customer, an unusually high transaction amount, a cross-border card, velocity rules, or inconsistencies between payment, device, and billing data.

Payment Processor Downtime

Like any technology, payment processors’ systems can experience downtime, resulting in transaction failure. It becomes a serious issue for merchants with a limited number of processors, as their downtime results in the company’s inability to receive payments for an unspecified period, leading to financial losses and customer dissatisfaction.

A single-provider setup also leaves the merchant without a fallback route. With a second provider connected, failover can move the payment elsewhere, as described in the recovery section below.

Technical Issues

Technical errors are different from declines. They occur when a provider is reachable but the request does not complete correctly because of issues such as timeouts, slow responses, malformed requests, rejected API calls, or connectivity problems.

Generic customer-facing messages such as “transaction failed, try again later” may hide either a technical error or a temporary issuer refusal. Payment teams therefore need the underlying gateway, acquirer, processor, and issuer response rather than relying only on the message shown at checkout.

Authentication (3DS and SCA) Failures

Authentication introduces another point at which a card-not-present transaction can fail. In the EEA and the UK, strong customer authentication rules let the issuer soft-decline an unauthenticated card-not-present payment and ask for 3D Secure instead of approving it.

Failures can occur because the customer abandons a 3DS challenge, authentication data is missing, authentication itself fails, or the 3DS infrastructure is temporarily unavailable. When the authorization response indicates that additional authentication is required, resending the same request unchanged is unlikely to help. The payment should normally be resubmitted with the required authentication data or, where applicable, a valid exemption.

If the payment then moves to another acquirer, an acquirer-independent 3DS layer (External MPI) lets the same authentication data be reused where that acquirer accepts external 3DS data, so the customer is not asked to complete a second challenge.

Internal Payment Providers’ Restrictions

Each bank and payment provider has its own internal limitations. Restrictions can apply to certain types of transactions, their amount, the list of blocked countries, and other criteria. If such limitations are not taken into account beforehand, perfectly valid transactions will be declined.

Restrictions can also apply to merchant categories, currencies, transaction types, individual acquirers, or specific MIDs. A payment rejected through one eligible route may therefore be accepted through another.

Common Decline Codes and What They Mean

Card authorization responses normally include a decline or response code. The message structure used across the industry is based on standards such as ISO 8583:2023, which defines a common interface for exchanging financial-transaction-card messages between acquirers and issuers.

However, the exact wording and treatment of a response can vary between networks, acquirers, and processors. A generic response such as 05 — Do not honor may not reveal the underlying reason, so payment teams should combine the response code with network, acquirer, and merchant-advice data before deciding what to do next.

Network rules take precedence over any generic code table. The retry rules below reflect how Visa and Mastercard treat these responses.

How to Recover Failed Transactions

Recovery depends on the reason the payment failed. Many soft declines can be recovered in the same checkout through cascading, others need a well-timed retry, and hard declines normally require new or updated payment credentials. Technical errors, where no authorization response came back, are handled by failover once the transaction status is confirmed.

Some declines can be recovered. Some should stay declined. The value is in having the infrastructure to make that decision intentionally.

Cascading Within One Payment Attempt

Cascading adds resilience by allowing a failed or declined payment to move through another route when the routing rules allow it.

Here’s how it works: if a bank or payment provider declines a transaction, the system doesn’t halt or give up. Instead, the system automatically redirects the transaction to another provider integrated into the system to achieve a successful result within one payment attempt.

For the customer, the switch can happen without restarting the whole payment flow. Cascading can transform an eligible declined transaction into a successful one without being noticed by the end user. The backup route can sometimes cost more, so cascading should be selective rather than applied indiscriminately.

Akurateco’s guide explains which declines can be recovered through cascading and which should stay declined.

Failover When a Provider Times Out or Goes Down

Failover handles failures that are not declines at all. The request times out, the connection drops, or the acquirer’s system is down, so no authorization response comes back. Failover then moves the payment to another provider or MID because of that technical problem, not because the issuer refused it.

Providers often slow down before they fail outright. According to case studies collected by LatencyCost, Amazon found in 2006 that every 100 ms of added latency cost 1% of sales, and Walmart found in 2012 that each one-second improvement in page load time raised conversions by up to 2%, so response time is worth watching as closely as outright errors.

Two practices make failover safe:

1. Confirm the status first. A timeout does not necessarily mean that authorization failed. If the status cannot be confirmed, reverse the attempt before the payment goes elsewhere, so the customer is not charged twice.
2. Keep card credentials portable. A vault that protects credentials is useful. A vault connected to routing and orchestration lets the stored card move to the backup route instead of staying locked to one provider.

Afterwards, the payment team should be able to see which provider failed, where the payment went next, and how it ended.

Retrying Soft Declines: When to Retry and When to Stop

Retries are useful only when they address a recoverable condition. Repeatedly sending the same authorization does not make every decline more likely to succeed. Payment teams should follow five rules:

1. Retry only recoverable failures. Soft declines and technical errors may justify another attempt. Hard declines, lost or stolen cards, and suspected fraud should not be retried automatically.
2. Follow network retry limits. The Visa Core Rules, 18 April 2026 edition state that Category 1 declines must never be resubmitted for the same payment credential, while other categories allow up to 20 reattempts within 30 days, with a fee for each reattempt beyond that. Mastercard’s Transaction Processing Rules likewise prohibit repeat card-not-present attempts after hard declines, and its Merchant Advice Codes indicate whether a retry is allowed.
3. Change something before retrying. Depending on the reason, that may mean using another eligible acquirer, adding required authentication data, correcting transaction data, or changing the timing of the next attempt.
4. Match timing to the failure. If the issuer is temporarily unavailable, a retry after a short delay may be appropriate. If a recurring payment fails because of insufficient funds, a later point in the billing cycle may make more sense.
5. Confirm transaction status after a timeout. As with failover, check the result before sending another request to avoid duplicate authorization attempts.

For the full playbook, including stop points and the metrics to track, see how to build a recovery policy for each decline reason.

Recovering Recurring and Card-on-File Payments

Expired or reissued cards can generate failures on stored credentials. Network tokenization can help because network tokens may remain current when the underlying card details change. Account updater services can similarly refresh eligible card credentials without requiring the customer to manually enter new details.

Stored-credential and merchant-initiated transactions should also be flagged correctly, as explained in Akurateco’s guide to customer- and merchant-initiated transactions.

When credentials cannot be refreshed automatically, the customer should receive a direct way to update them or switch to another payment method.

Dunning is the billing-side sequence of payment retries and customer reminders used after recurring payments fail. It complements payment recovery but is separate from authorization and payment orchestration logic.

Preventing Transaction Failures

Merchants do not have to wait until payments fail before acting. Payment teams can reduce preventable failures by building redundancy into payment infrastructure, routing transactions appropriately, tuning fraud controls, and monitoring where failure rates begin to change.

Multiple Payment Integrations

When a merchant has limited integration with banks and payment providers, any downtime or issues on the provider’s side can hinder its ability to accept payments.

Multiple integrations give payment teams alternatives when one provider becomes unavailable or cannot process a particular transaction. This reduces dependency on a single provider and creates the infrastructure needed for controlled failover.

Payment Routing

Routing allows payment teams to determine where a transaction should be sent before authorization based on transaction characteristics and provider-specific restrictions.

Furthermore, intelligent routing allows you to add whitelists of trusted clients to the system to route transactions from them to specified Merchant Identification Numbers (MIDs), preventing genuine customers from experiencing transaction failure.

Different software providers support different parameters, so the available criteria and rule logic vary between platforms. See how routing rules are set up across payment providers for a deeper explanation.

Payment Fraud Prevention

Advanced fraud prevention systems monitor transactions and apply rules designed to stop suspicious activity before authorization or capture. The challenge is maintaining effective fraud controls without blocking too many legitimate payments.

Payment teams can reduce false declines by reviewing fraud rules by customer or transaction segment rather than applying the same thresholds globally, whitelisting known-good customers where appropriate, and providing complete billing and authentication data.

Read more about reducing payment risk with fraud prevention controls.

Payment Monitoring and Failure-Rate Tracking

Payment monitoring helps teams detect changes in transaction performance in real time.

A basic transaction failure rate can be calculated as:

Failed transaction attempts ÷ total transaction attempts × 100

The overall percentage is only a starting point. Failure rates should be segmented by decline category, acquirer or MID, card BIN or issuer country, payment method, and relevant market characteristics. Alerts can then identify sudden changes, such as a provider beginning to time out or issuer declines rising in a particular region.

A payment monitoring system helps payment teams detect these changes as they happen. For the broader set of authorization, conversion, cost, and processing KPIs, see Akurateco’s guide to improving payment performance.

Built-In Analytics

Monitoring answers the immediate question of what is changing right now. Analytics helps payment teams understand longer-term performance across providers and payment flows.

Consolidated data can show which acquirer, market, issuer segment, or payment method loses more transactions over time and whether configuration changes produce measurable improvements. Akurateco’s guide to using payment analytics to improve transaction outcomes covers these use cases in more detail.

How Akurateco Helps PSPs and Merchants Recover Failed Transactions

Akurateco is a white-label payment gateway provider offering advanced payment software with 700+ payment integrations. It provides the gateway and payment orchestration layer on top of acquirers and does not process transactions itself. Enterprise merchants use it to recover payments across their own providers, and PSPs use it to do the same for every merchant they serve, under their own brand.

This is what happens to a declined payment on the platform:

1. Smart routing sends the payment to the provider most likely to approve it, based on rules such as payment method, amount, currency or the card’s country.
2. If that provider declines the payment or does not respond, cascading moves it to the next eligible provider within the same payment attempt.
3. With External MPI, the cardholder authenticates once, and the same 3DS data is reused on the next acquirer where external 3DS data is accepted; otherwise, the customer re-enters only the 3DS password.
4. Once a provider approves the payment, checkout is complete, and the customer does not have to start again.
5. Reporting shows every attempt: which provider declined or timed out, where the payment went next, and how it ended.

Enterprise merchants set the rules that decide whether a declined payment is cascaded, retried later or stopped. For PSPs, the same flow answers the question merchants ask first: why transactions fail and what can be improved. Routing, cascading and reporting run for every merchant on the PSP’s platform.

The platform’s technologies for managing transaction failures include:

1. Highly customizable intelligent routing with a range of customizable parameters, including routing by payment method, transaction amount, currency, geolocation of billing address, white lists, and more.
2. Cascading for regular and 3DS MIDs, carried out within one payment attempt.
3. High-end fraud prevention technology, designed by professionals in digital payments.
4. 700+ integrated banks and payment providers available via a single integration to the platform.
5. Built-in analytics automatically consolidates payment data from diverse channels under one roof.
6. Payment monitoring system with expert support available on demand.

Conclusion

A failed transaction is not a single type of problem. Payment teams first need to determine whether the payment ended in a soft decline, a hard decline, or a technical error.

Recoverable failures can be handled through controlled cascading, failover, authentication, well-timed retries, or updated card credentials. Routing, monitoring, fraud-rule tuning, and multi-provider infrastructure can help prevent other failures before they affect a larger share of transactions.

The key is to respond to the actual failure reason instead of treating every unsuccessful payment the same way.

Want to see how these capabilities work within one payment orchestration platform? Request a demo with Akurateco.

Failed Transactions FAQ

What Does It Mean When a Transaction Is Unsuccessful?

An unsuccessful transaction means that the payment could not be completed for various reasons. This could be due to issues like insufficient funds, incorrect payment details, fraud detection triggers, expired cards, or technical problems with the payment gateway or processor. The transaction is declined or rejected, and the payment does not go through.

What Happens If a Transaction Fails?

When a transaction fails, the merchant needs to determine whether authorization was declined or processing failed technically. No funds are captured unless authorization or another payment step already succeeded. The response determines whether the next action should be a retry, cascade, authentication step, or another payment method. If an approved authorization is no longer needed, it should be voided where appropriate so the hold can be released.

How Do Merchants Fix a Failed Transaction?

Start with the issuer, acquirer, gateway, or processor response and classify the failure. Eligible soft declines can be retried or cascaded, authentication-required responses should be resubmitted with 3DS, and hard declines require updated credentials or another method. After technical errors such as timeouts, confirm the transaction status before failing over to another provider or sending another authorization request.

What Happens to a Payment When a Payment Provider Goes Down?

With a single provider, the payment fails and cannot be completed until that provider is back online. With several providers connected, failover moves the payment to a backup route once the platform confirms that the first attempt did not go through, so the customer can still finish checkout. Reporting then shows which provider failed and where the payment was approved.

What Is a False Decline?

A false decline occurs when a legitimate payment is rejected because an issuer risk model or the merchant’s fraud controls incorrectly classify it as suspicious. Possible triggers include unusual transaction amounts, cross-border activity, velocity rules, a new customer profile, or mismatched billing and transaction data. Monitoring rule performance by segment helps payment teams identify where legitimate payments are being blocked.

What Does “Do Not Honor” Mean?

“Do not honor” is a generic issuer decline response, commonly represented by code 05. It does not explain the precise reason for rejection. Before retrying, payment teams should check any additional network, acquirer, processor, or Merchant Advice Code data rather than resubmitting the same authorization unchanged.