Why a declined payment rarely tells you why

You open your dashboard, find a declined payment, and the reason says “Do not honor”. Or “Error 05”. Or a sentence in Portuguese. Or nothing at all.

If you work with one PSP, that is annoying. If you work with several, it becomes a real problem, because every provider describes failure in its own way.

Every PSP has its own vocabulary

One returns numeric codes. Another returns free text. A third returns the issuer’s raw message, in the language of the country where the bank sits. The same underlying cause, say an invalid phone number, can show up as three completely different strings.

Your team ends up learning these by heart, or worse, ignoring them.

Three different problems in one bucket

When we look at decline lists, almost everything falls into one of three groups:

1. Bank declines. Insufficient funds, issuer refusal, limit reached. The customer or their bank said no.
2. Data problems. A name in the wrong format, a postal code that is too short, a phone number the PSP cannot parse, a city that does not match the country. Nobody refused the payment. The request was bad.
3. Technical errors. The PSP was unavailable, a timeout, a configuration issue on the routing side. Nobody refused anything either.

Most dashboards show all three as “rejected”.

Why this matters

If a third of your declines are actually data or technical errors, your approval rate is telling you the wrong story. You might switch PSP when the real fix is a form field on your checkout. Or you blame your own integration when the bank simply said no.

It also changes who has to act. A bank decline means retry with another method or contact the customer. A data problem means fix your form. A technical error means ask your provider. Three different people, three different actions, one label.

What a useful decline looks like

Nothing exotic. Four things:

• One set of reasons across every PSP, so “invalid customer data” means the same thing whichever provider returned it.
• The raw PSP message kept next to it, so nothing is lost when you need to dig.
• A clear split between declined, failed and expired. A payment that nobody completed is not a refusal.
• A timeline per transaction: created, sent to the PSP, PSP response, final status.

A check you can run this week

Export your last few hundred declined transactions. Group them by reason, and sort each reason into the three buckets above. Do not worry about being perfect.

If the bank declines are a minority, you have found your quickest win, and it probably has nothing to do with which PSP you use.