Why did this transaction fail? Common decline reasons

4 min read

Quick answer #

Most failed transactions on Pay@ Gateway are declined by the customer’s bank, not by Pay@. The four most common reasons are: insufficient funds, the customer’s bank declining for fraud-prevention reasons, 3D Secure authentication failing, and the card being expired or incorrect details entered. The decline reason is shown in your dashboard for every failed transaction, and the customer’s bank is always the right place to escalate if they believe the decline was wrong.

Where to find the decline reason #

Every failed transaction in your Pay@ Gateway dashboard shows a decline code and a human-readable reason. Click into the transaction to see:

The decline code (a standard ISO 8583 code)
The plain-English reason
Whether the decline came from Pay@, the customer’s bank, or the card network
The recommended action for the customer

If a customer tells you their payment failed, the first step is always to look up that specific transaction in the dashboard and read the decline reason. Don’t guess from the symptom — the actual reason is logged.

The eight most common decline reasons, ranked #

1. Insufficient funds (code 51) #

The customer doesn’t have enough money in their account, or has hit their daily spending limit. By far the most common reason. The customer needs to either move money into the account, use a different card, or wait for their daily limit to reset (usually overnight).

2. Do not honour (code 05) #

The customer’s bank declined the transaction without giving a specific reason. This is usually a fraud-prevention block — the bank’s risk system flagged the transaction as suspicious. The customer needs to contact their bank, confirm the transaction is legitimate, and ask them to allow it. Retrying without doing this almost always fails again.

3. 3D Secure authentication failed (codes vary by network) #

The customer didn’t complete the 3D Secure step. Either they entered the wrong OTP, the OTP expired, they closed the authentication window, or their bank’s 3D Secure system is temporarily unavailable. Ask the customer to try again and watch for the OTP message from their bank.

4. Invalid card number / expired card (codes 14, 54) #

The card number was entered incorrectly, or the card has expired. The customer should check the card details — particularly the expiry date — and try again. Most card payment forms catch obviously wrong numbers (Luhn check failures) before they even reach Pay@.

5. Card not permitted for online transactions (code 57) #

Some cards — particularly newer prepaid cards or accounts with online purchases disabled — can’t be used online. The customer needs to enable online transactions in their banking app, or use a different card.

6. Suspected fraud (code 59) #

The customer’s bank flagged the transaction as likely fraudulent. The customer must contact their bank to clear the flag. Common triggers: large transactions outside normal spending patterns, transactions from a new IP/device, or transactions in a category the card is rarely used for.

7. Restricted card / card stolen (codes 62, 41, 43) #

The card has been reported lost or stolen, or is restricted from this type of transaction. The customer needs to contact their bank — there’s nothing you can do as the merchant.

8. Issuer or network unavailable (code 91) #

The customer’s bank or the card network is temporarily unable to authorise. This is rare but does happen during banking system maintenance. The recommended action is to wait a few minutes and try again.

What to tell the customer #

For most declines, the only honest answer to “why did my payment fail?” is some version of: “Your bank declined the transaction. We don’t know exactly why because they didn’t tell us, but they will if you call them. The number on the back of your card is the fastest path.”

This sounds curt but it’s accurate, and it sends the customer to the only party who can actually resolve the issue.

When to escalate to Pay@ #

Most declines are bank-side issues. But contact Pay@ support if:

The dashboard shows a Pay@-side error (rare, usually a gateway issue)
You see a sudden cluster of declines from previously successful customers (could indicate a configuration issue on your side, or a Pay@-side issue we should know about)
A customer believes their bank approved the transaction but Pay@ marked it as declined (we can trace the specific authorisation in the bank logs)