The Narrow Waist of Payments Orchestration
A Revolution in Payments Technology May Start With Lego-like Primitives and Narrow Focus on a Commoditized Complement
Containers is the most successful industry protocol in history. Payment orchestration could be so much better if we had a similar protocol ourselves.
Ocean freight used to be slow, unreliable and expensive well into the 20th century. It wasn’t a technology problem: we already had diesel engines on ships and submarines since the 1910s.
It wasn’t for a lack of incentives, either. During World War II, the US military had explored how to make the most of the space in its vessels. Avoiding enemy submarines was a matter of having fewer of them, not wasting any space.
No. The reason was that loading cargo was an odyssey.
Dockworkers had to play a game of Tetris and handle packages of all shapes and forms. To transfer stuff onto a smaller rail car, for example, they had to open it and repackage it.
That is, until Malcom McLean came along, and designed the container.
Containers made everyone reach a surprising consensus. When using containers, you weren't agreeing on how your ship was built, or the shape of the cargo. You didn't expect ships to be interoperable by providing documentation to dockworkers.
With containers, you agreed on how the building blocks look on the outside. On the interface of the most basic components.
The result? Loading a ship used to cost $5.86 per ton; the standardized container cut that to 16 cents.
Why is that so? Because the container protocol is exactly why Lego bricks spur the imagination of kids. Containers, like Lego, fit neatly with almost no empty spaces. Machinery to handle containers can be built at scale, can be sold globally, and training on how to use them became simpler. Defects became more obvious and fixed faster.
Innovation wasn’t stifled under a strict standard. It flourished, both as incremental improvements and as episodic experiments on individual components.
Can something like the container change the payments orchestration industry forever?
Welcome to Money In Transit, the newsletter bridging the gap between payments strategy and execution. I’m Alvaro Duran.
Today’s post is the third installment on a series I’ve called A Sketch of a Payment Systems Protocol. You can read the first and the second installments for free.
Want to be notified when there’s a new post? Hit that subscribe button below.
Payment orchestration technology makes all payment methods look the same in the eyes of the merchant.
But payment methods are anything but. Even card payments look different cross-border, due to regulation. The purpose of payment orchestration technology is to hide those differences. The point is precisely to make the right assumptions on behalf of the user.
Like ocean freight in the pre-container era, payment orchestration feels nowadays like a game of Tetris. Engineers handle payment methods of all shapes and forms. And reconciliation, as a result, is slow, error-prone and expensive.
How many people handle fraud and transaction optimization semi-manually at merchants today? How integrating with a payment orchestration platform has changed that?
And why does it look as if they were handling plutonium?
It is not that payment orchestration is bad. The answer is that orchestration technology has stagnated.
Every payment orchestration platform hits an eventual crisis point. When integrating yet another payment method becomes a priority over improving the design.
That's because they build all their payments technology in-house
It is as if freight companies, being slow and expensive, decided that it made sense to buy more ships, getting more costs and delays as a result.
Bananas, if you ask me. The goal of payment orchestration technology is to design a system where all payment methods have the same interface.
Such a design is exactly what the shipping container did to ocean freight.
New payment methods would fit neatly with the overall system when integrated. Complex capabilities like smart routing could be built on top of stable infrastructure. Defects would be more obvious, and improved faster, since a shared protocol is used more often and by more companies. And training, testing and monitoring would be easier, faster, and cheaper.
That is the point of layering.
Prefer Composition over Inheritance
The point of layering is to make complex logic tractable. Software is built with functions and classes, and clusters of those are meant to stack like metaphorical layers.
Good software architecture nails down how these layers communicate with each other. That’s what engineers mean by “prefer composition over inheritance”.
With inheritance, communication is bidirectional. Lower, more basic layers can receive inputs from the layers above. In this manner, edge cases tend to dominate the logic of the basic layers. It is engineering hell, because it demands discipline.
To put it in perspective: it would be absurd to adjust the container size to the type of ship in which it’s placed. The rigidity of the container’s walls is precisely what allows for piling them up on deck. Plastic containers are useless.
With composition, communication is restricted. It can only flow from the lower layer to the one on top. It imposes a set of unbreakable rules that, if not properly designed, can become a burden.
But properly designed, those rules are liberating. Discipline is no longer needed. They are the steel that make up the container’s walls. Unbreakable, but stable and certain. Something we can rely on.
A Narrow Waist and a Technical Vision
Most payments experts oversell the actual complexity of the domain. And it can almost always be traced to bad software architecture.
Payments are complex in two ways. First, payment methods are diverse in their implementation. And second, users demand capabilities that need payment methods to be consistent.
That leaves room in the middle for a narrow waist. A transparent mechanism to conform the diversity of payment methods on the left into standard primitives that can be combined into the new, innovative, and complex payments products on the right.
Just like Lego bricks. Just like containers.
An open protocol that will change the payments orchestration industry forever.
A Technical Vision
I saved the most important feature of a software architecture based on layers for the end. Because it bleeds out into the realm of business.
Once you start arranging payment orchestration technology into layers, you notice something. That you can open source the lower levels, and keep the upper layer proprietary.
Why would you do that? Because building the primitives of payments yourself isn’t a differentiator for orchestration. What matters is what sits atop: data analytics, smart routing, and a track record of integrating with many providers.
Such an arrangement leads to an important business decision. You can ignore open source because you believe it would be giving away your secret sauce. But you can instead assess which layers of your codebase benefits more from being open source than being built in-house.
And then notice that, at the lower layers, everyone is building the same thing.
That is the abyss you’re staring at. The same abyss those who bet on the shipping container for the first time.
But containers is now the most successful industry protocol in history. Isn’t it time we have a similar protocol ourselves?