Ouch! What To Do When A Payment Fails

Categorizing errors, and learning to live with the disappointing Do Not Honor

In payments, default error responses do a lot of harm.

Picture this: you’ve just introduced highly confidential information (the number on your credit card) into a Web form in a site of a company you’ve never purchased from before. There goes the spinner; you wait. And something goes wrong. But it doesn’t say what.

Isn’t that a bit scary?

Have you done something wrong? “No”, you think to yourself, “the numbers are correct”.

Have they charged you without processing the order? You check your banking app. Nothing. But then you realize that your banking app is crap, and they may not show you anything for a whole day.

Should you try again?

I know I wouldn’t.

Payments aren’t something you retry, because you don’t want to pay twice as much, or get twice the stuff you ordered.

If something goes wrong, the customer wants to know why, so that they can rest assured that nothing fraudulent has happened, and trying the payment again will work.

In payments, the experience of the bad is as important as the experience of the good.

And the crazy part is that, often, you don’t know why a payment failed, and it is your job to put the customer at ease with a valid explanation.

This is The Payments Engineer Playbook. Today, we’re looking at payment error codes. The ideal is to be clear at scale, so that you provide information that’s easy to maintain from a software perspective, but detailed enough to give customers a reasonable explanation, and a path forward.

We’ve never touched error codes before in this newsletter, and for that reason we’re going to cover the basics: how to categorize error codes, and what to do about them.

Let’s dive in.