Designing Payment Applications
Introducing The Databases of Money - Launching 1st Dec 2023
Welcome to Money in Transit, especially the many of you for whom this is the first actual installment to hit your inbox (welcome aboard!). MiT is a newsletter about the technology to move money around, from the insides of merchants that, despite not considering themselves fintech, can’t stop thinking about payments.
Today’s post is the preface to my upcoming book, The Databases of Money: Designing Payment Applications. You can read all about it in the announcement. I decided to share this piece for free to highlight the important questions that surround payment applications in a world where, according to Angela Strange, “every company is a fintech company”.
If you find this essay engaging, watch out in this newsletter for the official launch on the 1st of December.
Read on, share promiscuously.
One of the things I found most surprising when I started working in fintech was that the “move fast and break things” motto didn’t seem to resonate with these companies’ customers. The payments industry has been very simple for a very long time, focused on riding the wave that was drifting people all around the world from cash to credit cards, taking a slice of every transaction.
Now, things are way more complicated. There are new payment methods left and right, some of them made by state actors. Fintech companies, used to calmer waters, now have to navigate the industry’s whirlpool of challenges. To that end, some tried every trick in the Silicon Valley playbook, especially “moving fast”. They failed: CFOs don’t want things that break.
However obvious that sounds in retrospect, I’ve worked with engineers that treat payments the way they treat any other industry they’ve worked in. I once witnessed a manager at a fintech startup I worked for prioritize software development by following another classic mantra: “make it work, make it right, make it fast”. After going live with the first version, there was a nasty bug in the accounting system that required compensating users every time the numbers didn’t add up, which happened frequently. To that manager, that counted as “making it work”.
Needless to say, a complete rewrite soon followed.
The Rut of Payment Startups
Here’s what I realized: there is a disconnect between how decisions get made at fintech companies, and how engineers gel those decisions into software.
Agile and DevOps are partially responsible for this. Agile emphasizes self-organizing teams and downplays the role of everyone outside, even the CTO, as mere sponsors, who must trust the team to get the job done, or else being labeled as Waterfall promoters.
DevOps, by integrating the role of software development and IT operations into one, made engineers the owners of the applications they build. But if the line between Dev and Ops now cuts through the heart of every engineer, some of them are going to keep things the way they are for fear of breaking anything, and having to learn new approaches. Stagnation not only makes your job easier, it also increases your job security.
As a result, many fintech startups are stuck in a rut, a situation that’s good enough to keep the lights on technologically speaking, but very fragile to changes in the payments landscape.
The Explosive Cocktail
If the payments industry had been like social media, then that would have been fine. Twitter, for example, has seen during the 2010s and early 2020s the rise of Instagram stories, Tik Tok, Clubhouse and Youtube Shorts. It launched zero new products in response. But because social media is now a deadlocked industry, it didn’t have to.
Over those years, the Bitcoin paper, the Durbin amendment, and even COVID-19 have accelerated the shift towards cashless societies. People have become used to pay in ways that were unthinkable to them just a few years ago.
What if—humor me for a moment—payments are based on the proposition that the industry is so fluid, and at the same time requires such high levels of accuracy, that its technology demands different diagnostics than the rest of the software industry? What if what’s valuable in this space is not the outcome of moving fast and breaking things like gunfighters, but of moving slow and being precise like snipers?
Another observation I made was that there are some CEOs who can only speak in terms of Big Ideas when it comes to things they don’t understand. And the payments industry is very good at playing hard to get, because done right it can offer a competitive advantage. The result is that Big Idea CEOs are happy about having just veto power on technology decisions as long as payment applications don’t cause them any headaches.
Savvy CEOs don’t veto technology they don’t necessarily understand. Instead, they provide access to the multiple and overlapping contexts on which that technology operates. It’s also access that engineers most often don’t have. Who are the stakeholders? What can they do with that technology? How is the company positioned in the market? How does it make money? Who is the user they cater to?
For example, one critical aspect of software is its breathtaking pace of change. “Our children”, said Olaf Helmer-Hirschberg in 1967, “will have to adopt continual adaptation as a way of life”. New and purportedly better ways of building software are aggressively marketed to engineers all the time. It is in their creative nature to be interested in new problems, and in using new tools to solve them. But the New is also the Unknown, and payment applications that are both scalable and accurate are usually built from battle-tested building blocks arranged in familiar patterns.
Engineers choosing their own technology without any business context, combined with the perverse incentives that Agile and DevOps create, are two ingredients of the explosive cocktail that explains why 70% percent of fintech companies fail.
A Path Forward
Not all technology stack changes are necessarily bad. Even large financial institutions are leaving Java behind in favor of more modern programming languages like Python. Not because some visionary is blazing the trail, but because over the last six decades the capabilities of hardware have sustained a dramatic pace of improvement. This has diminished the importance of performance in software, in favor of systems that store and process ever growing amounts of data, and programming languages that prioritize ease of understanding and modification over raw performance are winning the upper hand.
Ultimately, the result of considering payment applications as a technological piece of the whole business that just works is the need for a cultural shift in the team that owns those applications. This shift involves thinking less in terms of craftsmanship, creativity and exploration, and more in terms of rigor, predictability and execution.
“Move fast and break things” is for startups whose technology is at the forefront of innovation and the key differentiator of their business. It is also for startups in industries prone to disruption, surprises and short company lifespans. In order to build payment applications that are superior to those of the competition, the complexity that must be addressed comes from the particulars of the payment industry.
This is perhaps the most counter intuitive point: the mystique of software design tends to be linked to engineering acumen. However, designing good payment applications is not about diagrams and patterns, but about proactively involving business experts.
Big payment platforms have struck gold by catering precisely to CTOs who don’t do that. Thinking is the hard part; do not outsource it.