Do Not Honor Is A Symptom That Proves That Payments Are Path-Dependent

A winning strategy to go around DNHs and improve payments authorization

Dealing with your own bugs is not enough. Sometimes, you have to deal with other people’s bugs. And banks have lots of them.

But banks never acknowledge mistakes, no. What banks have traditionally done is to weaponize language, mangeling until it says something that conveys no information, no meaning whatsoever.

The best known example of that, in payments software, is the Do Not Honor error code.

Stripe calls it a mysterious roadblock. It’s a catch-all for Checkout.com, and something to be defeated by Primer.io.

The best way to think about DNHs is as a useless error code.

Unless you get more information from another provider, you should work under the assumption that no decision has been made on that payment request, and other provider may accept it.

The catch, of course, is that you need a redundant provider, a plan B, to successfully go around DNHs.

Integrating with one PSP only makes you a sucker for Do Not Honors.

This is The Payments Engineer Playbook. Almost from the get-go, the most common piece of feedback I get from readers is to “write about pesky payments errors”. If you’ve spent a minute watching payments go in real production systems, you would’ve probably noticed that Do Not Honor account for a big chunk of all payment declines. Sometimes, the biggest chunk.

Many veterans have spent years of their lives trying to crunch their numbers and make DNH errors go away. They’ve made progress, but haven’t really succeed. That’s because DNH are inherent in the design of card payments.

DNH are other people’s bugs.

In this series, we’re exploring a few techniques to make your payment system more reliable. The crucial insight is that reliability isn’t something you have full control over. There are other providers you are forced to deal with, and it is in their systems where your reliability is decided.

If they’re down, and you’re not careful, you’re going down with them.

This series expands on 4 concepts that I described in a mini talk I gave a few weeks ago, namely:

• Production Testing

• Redundancy (this article)

• Orchestration

• Fallbacks

In this article, I’ll explain why different providers can yield different results for the same card, and what to do about it.

Enough intro, let’s dive in.