Hard-won Insights as a Service: The value of Payments Orchestration
As the traditional tools for payment performance gets commoditized away, their complement gets scarcer, less replicable, and more valuable.
One of the worst things that can happen to a company selling online is changing their Merchant ID.
Sometimes they have to—in most cases, because changing banks almost always leads to a change in MID, a 15 character-long number that identifies your company with your bank. But while switching seems inconsequential, the global payments network is built on data. And its best practices around it.
Like using primary keys:
The advantage of using an ID is that because it has no meaning to humans, it never needs to change: the ID can remain the same, even if the information it identifies changes.
— Martin Kleppman, Designing Data-Intensive Applications
The process of removing an identifier used across a data system from any meaning except as a pointer to the source of truth is called normalization.
Don’t get me wrong; normalization is a good thing.
The problem isn’t that we’re using a number to identify companies. The problem is that, in the payments industry, there is no actual source of truth to point to, only historical data. The system as a whole can only converge to the risk evaluation the company used to have after enough volume has been processed.
And that takes an unnecessary amount of declined payments.
This chaotic feature of the credit card system is so well-known, it has a name: MID warming. The idea is that, when you switch your ID, it’s “cold”. And like a diesel engine in a cold winter night, it takes a few tries to get going.
This, to me, is a bit disheartening. On every one of the millions of credit card transactions happening every second, the decision ultimately depends on a combination of ancient and erratic technology fed with data void of most of its context.
A disconcerting number of spurious declines are caused by… gremlins, man.
— Patrick McKenzie, patio11, Improving how credit cards work under the covers
MID warmings, though, are not the only quirks in the payments universe. In fact, quirks are paradoxically the norm.
It takes a special kind of talent, a combination of data skills, payments expertise and a pinch of timing and serendipity to tackle these quirks down, one by one.
I’m Alvaro Duran, and this is The Payments Engineer Playbook, where we dive deep into the stack that makes the payments magic possible. And in this article, we’re covering the companies that provide Payments Hard-won Insights, as a Service.
They’re known as Payments Orchestration Platforms.
What I Talk About When I Talk About Performance
The rise of Payments Orchestration Platforms goes hand in hand with the rise of e-commerce.
Once humans figured out how to make buying things online possible, VC firms started pouring a lot of money on trying to make the process as easy as possible.
Ever since, consumer convenience has become the Holy Grail of payment providers. Like when Tim Cook introduced Apple Pay: he positioned it against taking your wallet out of your pocket.
The convenience for the customer has pushed a complexity that used to be theirs (storing the card, showing the ID, checking its validity, retrying the payment, …) onto the hands of the merchants.
But the last thing that merchants want to do is to become payments companies.
And who can blame them? They’re in the business of business. In a world where a customer has expressed their intent to buy, why on Earth is it so freaking hard to make the money change hands?
Gremlins, man.
It may be 3DS, and the extra step that builds buyer’s second thoughts. It may be the appearance of non-card payment methods, like ApplePay, Venmo or Klarna, and the unwillingness of some customers to pay with anything but.
It may be fees, too. I know it’s now virtually set in stone, but it blows my mind that businesses pay to get paid.
Payments should be as easy as possible for the customer, and as cheap as possible for the business.
That’s why performance is a loaded word in payments. It can mean many things:
More revenue: higher authorization rates, or lower cart abandonments.
Less variable costs: less fraudulent purchases, or less chargebacks.
Less fixed costs: easier to build the infrastructure, or cheaper to operate and maintain
Even the opportunity cost of not having to build the damn thing in the first place counts.
When John Lunn, CEO and Founder of Gr4vy, said “that every merchant has an orchestration platform; they just don’t call it that”, what he meant is that payments systems were born in the belly of the first online businesses.
From then on, two approaches developed to address this need. On the one hand, payment gateways, built in-house or by a third party, which provide a standard API to facilitate the integration with multiple acquirers under the same set of endpoints.
On the other hand you have Payment Service Providers, or PSPs. Like Stripe.
As soon as you start accepting payments, you realize how cumbersome it is; compliance, paperwork, accounting, taxes, and fees dominate the attention of small online businesses.
PSPs’ selling proposition is “peace of mind”. They take care of everything for you. But they give you little control if you want to venture out on your own.
Which brings us to Payment Orchestration.
Beyond Stripe
Payment Orchestration Platforms combine the benefits of gateways and PSPs in 4 key elements:
A single API that provides a consistent developer experience
The ability to connect with multiple PSPs, and even other payment methods
Transaction optimization in a case by case basis.
Smart routing based on static and dynamic configurations
Single API
Sounds easy, right? A consistent set of endpoints that facilitates the rest of the benefits that the Orchestration Platform provides.
But we’ve already seen that even Stripe didn’t get this right in the beginning.
A consistent developer experience in payments is hard to get right, and beyond the ability of most merchants.
Which is why gateways, and now orchestrators, are so valuable just because of this. Without orchestration, they end up managing separate, fragmented payment setups, leading to higher costs, reconciliation issues, and lots and lots of failures.
Failed payments give customers a bad feeling about your company. They often don’t try again. Ever.
With payment orchestration, payment attempts are handled consistently, reducing technical errors and giving you the ability to retry them, without the customer knowing, on another provider.
Multiple Connections
PSPs are points of failure.
Having nailed down the technical difficulties for you, Payment Orchestration give you three things.
One, the ability to split your traffic into different PSPs based on criteria of your choice (usually the customer card’s BIN).
Two, the ability to retry failed attempts on another provider, just in case. Shockingly to anyone outside the industry, this is one of the most valuable mechanisms to improve payment performance big a huge margin.
And three, the ability to A/B test your traffic in search for circumstances that make one PSP superior to another in terms of authorization rates, fees, or fraud risk.
Transaction Optimization
Companies have more control over the payment process than they think.
By that I mean that there are situations where small changes in the format of the payment request payload can heavily influence the likelihood of success.
Like CVVs on MIT.
CVVs are the 3 numbers on the back of your card that no one is supposed to store except you. They’re there to prove that you have the card whose details you’re keying in in your possession. A payment without CVV is a Card Not Present Payment, or CNP.
Which is exactly what a Merchant Initiated Transaction, or MIT, is. One where it’s the company, not the customer, using the stored card details, who requests the payment.
An MIT with CVV is impossible. But, for whatever reason, some issuers expect the CVV field to have data, even in an MIT payment.
Not all of them, but some.
Which ones? That’s where the orchestrator comes in. Most merchants don’t have the volume to produce the data that answers these kinds of questions, like which issuers demand CVV on MIT, or which ones allow for $0 Authorization to validate credit cards instead of having to make micropayments.
These micro interactions with the customer are very nuanced. They aren’t easy to get right at small scale.
But they’re possible if your orchestrator provides you with the hard-won insights you need.
Smart routing
A single API, connection with multiple providers, even transaction optimization, are things that gateways or PSPs can give you.
What makes Payment Orchestration different from them is the ability to dynamically route traffic to other PSPs.
Measurement, benchmarking and data analysis are, to this day, the most effective and, in the age of AI, the most underrated tools to make sense of the inexplicable.
What Payment Orchestration have, again, is enough volume to gain significant insights from the data. At smaller scales, all signal is often spurious.
RFP vs A/B
Risk management and development costs are being commoditized.
And while PSPs retain some of their value with regulation, Payment Orchestration Platforms are showing that the real value in payments is found not in lower fees, but in expertise.
Hard-won insights, however, resist comparison. They’re the result of statistics, experimentation, and analysis.
Anyone can build an AI router. But AI is trained on what everybody knows, and routing based on average knowledge gives you average results.
An AI router is the baseline benchmark.
Same with RFPs. An outside perspective isn’t going to give you the tools to evaluate which PSP is right for you. No standardized process of hand-shaking and pitch-presenting is going to give you the information you need.
What you need is measurement, benchmarking, and data analysis. Rather than starting a request for proposals, go find a few PSPs that let you A/B test them with an orchestrator.
That is the ultimate measure of trust. To check for yourself.
P.S.: You’ve got this far, now I have to ask you something.
This article is the first in a series on Payment Orchestration.
I believe these companies, and the role they have in the payments industry, is not well understood. Mistaken for Gateways, advertised as PSPs, merchants are missing on so much from them.
I wish payments engineers knew what they do better.
If you want me to continue with this series, because it’s helpful and valuable, go check the article on Linkedin, and leave a comment.
You don’t want me to continue? Leave a comment too!
This has been The Payments Engineer Playbook. See you next week.