A payment failure is any payment attempt that does not complete as intended, so the payee does not receive the funds or receives them only after a return or correction. It is a broad term covering refusals by the payer's bank, technical errors in the systems that carry the payment, rejections for bad data, and payments that are reversed after they appeared to succeed.
A payment decline is one kind of failure: an explicit refusal by the issuer or bank. Failures also include timeouts, outages, format rejections, compliance holds and returned payments. For merchants and billers, failure rates matter because they lose revenue directly and through customers who give up; for banks and payment systems, they are a measure of operational quality that supervisors watch under operational risk rules.
Payment failure in plain terms
Think of a phone call that does not connect. Sometimes the person you are calling refuses to pick up; sometimes the number is wrong; sometimes the network is down; and sometimes the call connects but drops a minute later. In every case you did not get to talk, but the reason, and what you should do next, is different.
Payments fail in the same assortment of ways. The bank might say no, the account number might be mistyped, a computer between the shop and the bank might be broken, or the money might bounce back days later. Knowing which of these happened tells you whether to try again, fix the details, or ask the customer to pay another way.
Types of payment failure
| Type | Typical cause | Usual response |
|---|---|---|
| Issuer decline | Insufficient funds, suspected fraud, expired or blocked card | Ask for another method, or retry later if a soft decline |
| Technical error | Timeout, processor outage, network error | Retry, or fail over to another route |
| Data error | Wrong account number, invalid IBAN, missing fields | Correct the data and resubmit |
| Authentication failure | Customer abandons or fails a 3-D Secure or SCA step | Prompt the customer to try again |
| Compliance hold | Sanctions or AML screening match | Review; release or reject |
| Return after acceptance | ACH return, direct debit refusal, closed account | Re-present where allowed, or collect another way |
Failures on card payments
Card failures are mostly visible at the moment of payment authorization, when the issuing bank returns a response code. Some are hard declines, such as a stolen card, and some are soft declines, such as a temporary limit. Others are not issuer decisions at all: a payment gateway may time out, leaving the merchant unsure whether the charge went through. In that case the safe pattern is to query the transaction status or resend with the same idempotency key rather than submit a new charge, which could bill the customer twice. In Europe, a share of online card failures arise from strong customer authentication steps that the customer does not complete.
For subscriptions, a large source of failure is card data that has gone out of date when cards expire or are reissued. Network account-updater services and network tokens, which issuers keep current, reduce these failures; see also card lifecycle management.
Failures on bank transfers and direct debits
On the ACH network, a debit can appear to succeed and then come back as a return with an R-code, for example R01 (insufficient funds), R02 (account closed) or R03 (no account or unable to locate). Most returns must be sent within two banking days, while returns for unauthorized consumer debits have a longer window. Nacha sets return-rate thresholds for originators, 0.5% for unauthorized returns, with levels of 3% for administrative returns and 15% overall, above which an originator faces review. Under the UK Bacs scheme, unpaid direct debits are reported back through ARUDD reports, and SEPA uses R-transactions such as rejects, returns and refunds.
Credit transfers fail mainly on data. Wrong beneficiary details can cause a rejection or, worse, a payment to the wrong person. Verification of Payee, mandatory for euro credit transfers in the EU under the Instant Payments Regulation since 9 October 2025, and the UK's Confirmation of Payee aim to catch mismatches before the payment is sent. Cross-border payments add further failure points at correspondent banks, such as missing purpose codes or sanctions screening holds.
Measuring and reducing failures
Businesses track the failure rate by method, country, issuer and reason, and separate involuntary failures (the customer wanted to pay) from voluntary ones (the customer changed their mind). Common remedies include:
- Clean data at entry. Validating card numbers, account numbers and addresses before submission.
- Resilient routing. Using smart payment routing to fail over when a processor has an outage.
- Disciplined retries. A payment retry strategy that retries soft failures at sensible times and never retries hard declines.
- Customer messaging. Clear prompts asking the customer to update details or choose another method, a practice subscription businesses call dunning.
- Monitoring. Alerts on sudden rises in failures, which can signal an outage, a fraud attack such as card testing, or a broken integration.
Failed payments must also be reflected accurately in the ledger and in payment reconciliation, because a payment that failed after the customer was shown a confirmation leaves the merchant with an unpaid order and the customer with a wrong expectation.