Seven Lines of Code
The Money Stack — Episode 6 of 10
Before 2010, accepting a credit card on your website took roughly three months.
You applied for a merchant account. You waited for underwriting. You provided financial statements, sometimes a personal guarantee. You were assigned a payment gateway, which shipped you a PDF integration guide, an XML schema, a test environment that behaved nothing like production, and a support contact who answered on Tuesdays. Somewhere in month two you would discover an undocumented field that broke everything in a way the documentation could not explain.
Then two brothers from a small town in Tipperary launched a product whose project name told you exactly what they believed the problem was: /dev/payments.
The pitch was seven lines of code. Paste them in. Take money.
They had not invented a new payment rail. Underneath it was the same card network from Episode 3, the same acquirers, the same ISO 8583 messages, the same batch settlement. What Stripe did was take forty years of institutional complexity and make it entirely their problem instead of yours. Every ugly part — the underwriting, the compliance, the PCI scope, the network quirks, the retry logic — hidden behind a clean object model that a developer could understand in one afternoon.
That turned out to be worth more than the rail.
Abstraction as the Product
The instinct when encountering Stripe for the first time is to ask: what is the technical innovation? The answer is that the innovation is not primarily technical. It is architectural, in the product sense rather than the software sense.
Stripe made a deliberate choice to absorb complexity rather than expose it. Every other payment gateway of the era required the merchant to understand the four-party model, to handle different response codes from different card networks, to manage their own PCI compliance scope, to build their own retry logic for failed requests. Stripe decided that all of this was Stripe's job, not the developer's.
The resulting interface is an honest object model for a dishonest problem. Creating a payment is a function call. Refunding it is another function call. A payment either succeeds or it does not, and the reasons it might not are enumerated in a consistent format rather than communicated through undocumented numeric codes that differ by card network.
What makes this interesting from an engineering perspective is not what the API does but what it hides. Every Stripe API call is a thin interface over a system that is, in reality, asynchronous, fallible, and deeply inconsistent across its underlying components. The interface pretends otherwise. That pretence is the product.
Three Design Decisions Worth Studying
Several of Stripe's design choices have become industry standard precisely because they address genuine hard problems in payment systems.
The first is idempotency keys. Payments are asynchronous, networks are unreliable, and the consequences of creating a payment twice are significantly worse than the consequences of creating a payment zero times. If a request times out, did it succeed? The honest answer is that you cannot know without querying. Idempotency keys allow a client to retry a request safely: the server records the key, and any subsequent request with the same key returns the result of the first execution rather than executing again. This idea is not new. Field :20: in the MT103 message from Episode 2 is the sender's reference: the idempotency key of 1977. Stripe made it first-class and client-generated.
The second is webhooks. The synchronous request-and-response model of HTTP is a comfortable illusion when applied to payments. A charge can be authorised instantly but disputed three months later. A payout can succeed at the bank level but fail at the beneficiary level days afterwards. None of these events fit into a response to a request that happened at a different time. Webhooks acknowledge this: payments are an event stream, not a request-response interaction. Your server does not wait for an answer. It listens for events and reacts to them. Building payment systems correctly requires accepting that the synchronous model is a convenience fiction.
The third is tokenisation. When a customer enters card details on a Stripe-powered form, those details flow directly to Stripe's servers. The merchant never sees the card number. What the merchant receives is a token: an opaque reference that can be used to create charges but cannot be reverse-engineered to produce the underlying card number. This collapses the merchant's PCI compliance scope from an extensive audit to a much simpler self-assessment, because the merchant never touches sensitive card data at all. The idea did not originate with Stripe. The consequence of making it the default did.
Plaid and the Data Layer
While Stripe was abstracting the payment execution layer, a separate problem was left unresolved: how do you read what is in someone's bank account?
Banks held this data and had no obligation or incentive to share it. A fintech building a budgeting tool, a lending product, or a cash-flow analyser needed to connect to their users' bank accounts, and the banks had not built APIs for this purpose.
Plaid's original approach was screen-scraping: store the user's banking credentials, log into the bank's website as the user, and parse the resulting HTML. This worked, it was technically illegal in some jurisdictions, and it was an enormous security liability for users who handed over their passwords to a third party.
The industry moved, eventually, toward OAuth-based bank linking. The user is redirected to their bank's own authentication flow, grants specific permissions, and returns to the application with an access token that permits read access to specific data. The user's password never leaves the bank.
What drove this change was not the industry's goodwill. It was regulation.
When the Regulator Became the API Architect
The European Union's Second Payment Services Directive, known as PSD2, and the UK's Open Banking initiative did something unusual in the history of finance: they legally compelled banks to build APIs.
Banks above a certain size were required to expose secure interfaces allowing authorised third parties to read account data and initiate payments, with the user's consent. The theory was that increasing competition required reducing the information asymmetry between banks and fintech companies. Banks held customer data that fintech companies needed to build useful products. PSD2 mandated that this data be accessible on request.
The implementation was uneven. Banks that had no interest in enabling competition with their own products complied with the letter of the regulation and no more. APIs went live on deadline day and fell over on deadline day plus one. Documentation was minimal. Error messages were unhelpful. Some banks took years to reach a quality of implementation that was genuinely usable.
Despite all of this, the principle matters. A government decided that financial data infrastructure was too important to leave to the incumbent institutions' product roadmaps. The API became, in Europe, a regulatory requirement rather than a business decision. The experiment is ongoing and the verdict remains mixed, but the direction of travel is clear.
Paystack, Flutterwave, and the Harder Problem
Stripe's abstraction worked cleanly in markets where the underlying infrastructure was consistent enough to be hidden. The United States and Europe had one dominant card network, reasonably stable bank APIs, and a small number of acquiring banks with standardised integration requirements.
In Nigeria, and across sub-Saharan Africa more broadly, the problem is structurally different.
There are dozens of banks, each with its own integration requirements, its own API quality, and its own uptime characteristics. Some still use SOAP endpoints behind a VPN. Settlement rules differ by institution. Card acceptance is fragmented across multiple domestic and international networks. Cross-border transactions involve FX exposure, capital controls, and settlement timelines that vary by corridor.
Paystack and Flutterwave did what Stripe did, against this harder problem. They built a single integration point that normalised the chaos underneath: inconsistent bank APIs, unreliable upstream responses, and the perpetual challenge of the failed-but-debited transaction — the uniquely African payments bug where the debit succeeds and the credit does not, leaving funds suspended in the system and a customer on the phone.
When Stripe acquired Paystack in 2020 for an amount reported at approximately two hundred million dollars, the acquisition was a statement about the difficulty of the abstraction problem. Stripe, which had abstracted US and European payments, recognised that abstracting Nigerian payments was a different and harder task that Paystack had already largely solved.
Embedded Finance
The consequence of payments becoming an API is that every company becomes, in some respect, a financial company.
A logistics platform can pay drivers directly from trip revenue, in real time, without processing payroll. A marketplace can split a payment between a seller and a platform fee in a single transaction. A software product can offer a prepaid card, a savings account, or an insurance product without obtaining a banking licence, by sitting on top of a licensed institution's infrastructure through an API.
This is embedded finance: financial products built into non-financial applications through API-level integration with the licensed institutions underneath.
The question it raises is one the previous five episodes have been building toward. If financial infrastructure is a set of API calls, what do you do when you want infrastructure with no licensed institution underneath at all?
Episode 7: The Blockchain Bet — what Bitcoin actually solved, what it hasn't, and why stablecoins turned out to be the product that mattered. Coming 4th November, 2026.
The Money Stack is a ten-part series on the history and technology of how money moves. Written by David, a software engineer in Lagos, Nigeria.
Top comments (0)