What a corner shop taught me about payment failures

When a card payment fails, the industry calls it a "decline" and assigns it a code. 05: Do not honor. 51: Insufficient funds. 91: Issuer unavailable. The codes are tidy. The experience is not.

I think about payment failures differently than most people in this industry, because the first payment system I ever operated was a cash drawer in my family's grocery store. In that system, a payment failure looked like this: a neighbor at the counter, dinner ingredients already in her bag, discovering she was twenty rupees short. And the system's failure-handling logic was my father saying, "Next time."

That interaction has a property that almost no digital payment system has: it fails gracefully in the direction of the relationship. The transaction technically failed. The customer relationship got stronger.

What digital payments forgot

Digital payments inverted this. A failed online transaction is abrupt, unexplained, and frequently blamed on the customer by default. "Payment failed. Please try again." Try what again? With what changed? The customer doesn't know whether their card is broken, the merchant is broken, or the internet is broken. So they do the rational thing: they leave.

The numbers behind this are bigger than most people outside payments realize. In markets like India, payment success rates that would be considered an outage in the US are a normal Tuesday. A merchant doing everything right can lose a meaningful fraction of willing customers, people actively trying to give them money, at the last step.

For a large company, that's a conversion optimization problem. For a small merchant, it's rent.

Failures are information

The second thing the shop taught me: a failure is information about the system, not the person. When a customer's monthly tab got too long, my father didn't have a "decline". He had a conversation, and usually he learned something. A late salary. A sick parent. The signal got incorporated into how the system worked.

Good payment infrastructure treats declines the same way. A 91 from one issuer at 2am isn't a customer problem; it's a routing problem. Send the retry through a different processor. A spike in 05s from one bank is a relationship problem between institutions, invisible to the customer who just sees her dinner order fail. The job of an orchestration layer is to absorb these failures the way a good shopkeeper absorbs them: quietly, gracefully, without making the customer carry the system's problems.

The test I still use

When I evaluate a payments product, including the ones I've worked on, I ask one question: when this fails, who absorbs the failure?

If the answer is "the customer, with a vague error message," it's a bad system wearing good uptime numbers. If the answer is "the system retries, reroutes, and tells the human something true," it's getting close to what a corner shop in India figured out decades ago with a notebook and some patience.

We have not, as an industry, caught up to my father. But some days I think we're getting closer.