A Sketch of a Payment Systems Protocol
Paradigms succeed when you can strip them for parts. Protocols allow precisely that.
Something has gone terribly wrong.
Payments technology should be solved already. Instead, many intermediaries are placed between your customers and you, slowing down and increasing the costs of each and every transaction.
The fundamental disruption of the Internet is the commoditization of suppliers. Twitter disrupted how we consume information with “followers”, but now TikTok has disabused us of the notion that even that is required. However, the world is still waiting for a widespread, global payment systems protocol.
We’ve settled down for card payments. They’re expensive to integrate, and expensive to use. Just like airline executives knew that SABRE was possible in 1954, we have known for decades how to build a payment systems protocol.
It isn’t a matter of "can we do it?". It’s a matter of "what do we want it to be?".
Welcome to Money In Transit, the newsletter bridging the gap between payments strategy and execution. I’m Alvaro Duran.
Recently, we’ve looked at
The foundations of an open source payment orchestration library
Why payments must be built in-house, and how to do it effectively
They’re all free to read.
Want to be notified when there’s a new post? Hit that subscribe button below.
Payments are the core of capitalism.
Value can only be exchanged at scale with a mechanism that can mediate between two parties that don’t trust each other. But building the technology needed is believed to take longer, to be more expensive and to underperform compared to off-the-shelf software products.
The joke is, in order to figure out whether an existing product will satisfy our needs, we have to drill down each and every need to a point. That’s what you have to do if you are going to build that piece of software from scratch!
Indeed, “from scratch” is something that engineers no longer do. Virtually all development consists of gluing standard building blocks in familiar patterns. Engineering software is mostly repackaging.
Merchants are missing out on an entire dimension of opportunity.
Learned Helplessness
The line between payment intermediaries and merchants is getting blurrier.
There is an unjustified hype in vendors that rely on the attitude that technology is best left to the technologists. BaaS is already collapsing, and I predict that payment orchestration will see a wave of consolidation soon enough.
For small merchants, these vendors are fine. But online, the bulk of e-commerce happens through the enterprise merchants. Those operating at a scale where intermediaries are a nuisance, and with the technical expertise to build their own tools.
Can’t you see? Orchestration is just a technical layer. The burden of reconciliation is still on the merchants, who have to rely on spreadsheets and overworked employees to have a clear picture of their payments. Why would they rely on systems built outside their control any longer?
What enterprise merchants really need is expertise in engineering systems specifically built for payments.
Your Interchange Is My Opportunity
None of this would matter if customers still paid only with credit cards.
But they are doing so less and less often. Online bank transfers and digital wallets such as PayPal and ApplePay represent the alternative to card-based payments. Cards are still king, but a growing chunk of any merchant’s customer base refuses to use them.
Because of that, a crucial selling point for payment orchestrators is agnosticism. Orchestrators not only provide the ability to open new pipes to new payment providers. They also open up the possibility to route payments to the most appropriate provider.
But from an engineering point of view, that is just another service in a microservice architecture. Properly built, in-house payment technology outperforms third party vendors. Orchestrators can only solve for the general case, because volume is how they earn their money.
This leads to a single conclusion: it’s time to build.
Payments’ Narrow Waist
We were [funding] a bunch of open source developers to work on the Bitcoin protocol, because it directly benefited everything Square was doing in terms of money movement.
I wanted to do something similar with Twitter, because it was the only way to get out of a lot of the issues we were seeing around the decisions we had to make [...]. The only way to do it was to remove the protocol layer from Twitter and make it something we didn't control.
So what if we created a team that was independent to us, that built a protocol that Twitter could use, and then build on top of?
— Jack Dorsey, former CEO of Twitter, The End of Social Media: An Interview With Jack Dorsey
During the next couple of weeks, I’ll be sketching out a protocol for payment systems communication.
A protocol, not an API, helps others build. It defines the interfaces, just like Lego bricks interlock seamlessly, and lets others come up with brilliant ideas.
I’m inspired by the Internet’s narrow waist. A single protocol that allows all sorts of networking at the bottom, and all sorts of messaging at the top. A single protocol that made the Internet be on par with the Industrial Revolution, the full impact of which stretched over centuries.
The payments industry needs such a protocol. I think we’re missing out on many innovative products. But the industry is busy trying to outcompete each other.
No one would act. I decided I would.