So my two favorite companies (Stripe and @twilio) published a case study together about everyone's favorite topic, credit card authorization rates.

https://stripe.com/newsroom/stories/twilio

I want to zoom in on what creates a tenth of that 10% uplift, because it's sort of wild.

Have you ever wondered what a credit card transaction looks like to the computers handling it, at the closest-to-the-bare-metal level of detail? Feel they're unlikely to be JSON given we've had them for 50+ years?

You're right. Meet our friend ISO 8583.

https://en.wikipedia.org/wiki/ISO_8583 

As a grossly simplified level of detail, the Internet is a network on which whose commerce gets reflected on other networks, which sometimes crisscross the Internet, shipping ISO 8583 messages between various parties.

Most relevantly from the perspective of declines, to issuers.

Who issues credit cards? Complicated topic, but you can round it to "your friendly local financial institution."

So every bank in the world which has "their own" credit cards, with whomever's logo on it, had to write software to deal with ISO 8583 messages.

Now banks being banks, many of them do not have teams of developers, so they instead had this written for them by e.g. business process outsourcing firms.

And again, much of this is the most legacy of legacy software, still creaking around and mostly working decades later.

Let's talk about mostly working:

Consider the global economy as a system. Imagine the towering pile of software at a particular bank in middle America. Imagine the tiny bit of that software that parses UK zip codes.

Imagine that includes:

ukZipCode.equals(customer.zipCode)

"Is that statement a bug?" is an interesting philosophical question.

If you've used Java, you know that, assuming those are strings, you're going to get a case-sensitive lexical comparison between the zip code on file and the zip code provided in the ISO 8583 message.

And then you might ponder: "But wait a second. Case-sensitive versus non-case-sensitive comparisons don't really matter for US zip codes, which look like 90210. But they plausibly matter for UK zip codes, which look like SW1 (Buckingham Palace)."

"So plausibly, if a user on a mobile device types out sw1 but fails to engage caps lock because mobile typing is hard, and the website accepts the user output and just forwards it to the credit card networks because *shrug* seems reasonable, you'll deny the transaction."

Seems silly, right?

But how would you fix this bug? You'd have to blackbox an individual bank in middle America, somehow send them enough transactions to identify the UK-homed-customer code path, identify it was case sensitive, and then call them to tell them... what exactly?

"Hiya this is not-your-customer and we have a bug report to make. Someone, who probably doesn't work for you and if they did has long since retired, might have written a bit of Java code a few decades ago. That code is subtly bugged, well debatably, and inconveniences users."

Option the second: Adaptive Acceptance.

Stripe processes *a lot* of credit card transactions and sees a lot of declines. Credit card declines are often transient, so firms in the industry will do strategies like instant retry, retry with a backoff, etc.

We have an extra trick.

Since we understand ISO 8583 messages and various ways in which they can be perturbed in ways which don't change the semantic content of the message but do change how computer code might operate it, like for example trying upCase, downCase, and raNdoMcaSe on the zip code.

And we have a machine learning model which holds back a very small percentage of retries (i.e. a lot of retries, in absolute numbers), makes semantically neutral edits to them, and notes which semantically neutral edits are more effective at getting the transaction approved.

Over time, that model will learn in specificity, for a particular bank in middle America vis their UK-homed customers who have typed in lower cased zip codes, that the bank strongly prefers upper casing zip codes. So we just do that for them, for transactions across our network.

This isn't the same as fixing every bug or implementation infelicity in the world, of which there are many, but it is immensely scalable and gets better relatively passively as our business grows and as we have more data exercising edge cases.

And so the current state of the model is, if one introspects it, The Internet's Understanding Of Edge Cases In The Global Economy.

You'd have a really tough time putting that together, as a firm who just wants to charge users. So you can just buy it from us, w/ other services.

This is just one of the things we do to win basis points here and percentage points there for our users. The Twilio case study linked above also mentions e.g. understanding the physical implementation of Japanese credit card networks a lot better than you probably ever want to.

And the aggregate impact of these is pretty material, particularly for our enterprise users. You could hire dozens of engineers and put them on a Payments team, while denying all of their requests to do more meaningful work, and try to learn these nuances yourself.

Or try us.

If you want more technical detail about this, two of my colleagues did a talk on it: