Welcome to The Playbook!
3 Articles To Start Building Payments Software
Every company operating online has a software system built to handle their money.
But only a tiny few run without problems.
Engineers who get hired to maintain these systems are a dime a dozen. They come in, do what they’re told, spend some time learning the ropes, and eventually abandon, leaving a wake of false assumptions, technical debts, and operating nightmares in their wake.
You don’t want to be one of these generalists. You want to do a good job.
But the task of building payment systems is daunting:
Money is on the line
You must act quickly
Mistakes are hard to fix in retrospect
So, if you’re asking yourself “how can I stay on top of the payment systems I’m responsible for?”
Then you’ve come to the right place.
Here are 3 articles on the basics of building ledgers
The must read for every engineer who wants to get good at building ledger technology quickly:
The API of digital cash, what makes digital cigarettes look exactly like bank notes, consists of the following intuitions: Atomicity, Conservation, Fungibility and Storability (and the hidden one, Non-reproducibility).
Ledgers are simply a way to translate physical cash into digital money. To the extent that they embody the properties of money, that translation becomes seamless.
Most ledgers can only server one of two use cases. The most powerful can serve the two.
Double-entry accounting has existed for thousands of years. And yet, turning physical ledgers into digital ones requires a deeper understanding of what constitutes a source of truth, and the limitations imposed by the CAP theorem.
I used to work for a startup that, on every transaction, simply lost track of a couple of cents. As if they fell from our pockets every time we pulled out our wallets.
At this startup, a stock trading platform, the engineering team had followed the mantra of “make it work, make it right, make it fast”; we refused to build a double-entry accounting system.
We could’ve taken the time to build it right. We could’ve done things better. But we didn’t.
Stories like this don’t get aired very often because they’re embarrassing. But I believe it happens all the time.
Not losing track of money is the bare minimum. And yet, every engineer in the industry has a story of a time when they screwed that up big time. That shouldn’t be happening anymore.
And if you want to dive deeper into the topic, check out how Modern Treasury invented event locking, why caching the past is a rare event, and an approach to building multi-currency ledgers.
Here are 3 articles on building payment systems
These systems are responsible for accepting and submitting payments from and to external entities. Building them is tricky, not because they are conceptually difficult, but because they look easy on the surface. These articles will help you navigate the hidden obstacles and the accidental sources of technical debt:
You’ll find a lot of content out there on how to use Stripe’s API.
However, if you want to build payment systems, there isn’t much content out there. Stripe, obviously, isn’t going to help you build one. And so, there’s little about why Stripe’s API was built that way.
The truth is that Stripe's redesign is less simple, but serves a more valuable purpose. Even if it isn’t the simplest route.
Because the simplest route is a mistake.
Stripe’s API is the best way to programmatically develop and interact with a Payment Service Provider out there. 10 years ago, it was as simple as 7 lines of code to get your payments up to speed with them. But they’ve abandoned that, and for good reason: it was wrong.
There’s pretty much one way to produce high quality software. Use it, and fix all the bugs you can find in it. In time, the easy bugs are gone.
Unlike the human body, old software is so healthy. If that’s the only way to produce high quality software, the only illnesses you’re going to find are the exotic ones.
Payment systems are an extreme version of this
Uber tests its payments system in production. On the summer of 2024, I argued that you should too, and it took Hacker News by storm.
A payment is a promise made by an authorized party about a transfer.
Payment methods look diverse, but that’s because you have the wrong framework to approach them. A good taxonomy on all payment methods, existing and none, can make or break the architecture of your payments system.
And if you want to dive deeper into the topic, check out how Airbnb makes idempotency and avoids double charges, the most important book you should read to become a great payments engineer, and what the Saga pattern has to do with money software.
Gain access to the complete archive
Paid subscribers make The Payments Engineer Playbook possible—they’re the reason I can do research, write articles, and share them with everybody. If you’re a paid subscriber: thank you.
Every subscription counts, and each one pushes The Playbook further.
If you can’t afford it, that’s okay. A substantial portion of the archive is free, and will continue to be so. If you’re looking for another way to help out, share your favourite article with a colleague! Most people find me through word of mouth.
If for any reason you need access to something that’s paywalled, just email me. I’ll be happy to help you.
Need help?
For all questions about the Substack platform, please visit Substack Support.