Payment Systems Engineering
Four essays on building payment infrastructure that survives contact with production.4 parts, about 27 minutes in total.
Most payments writing explains how an API works. This series is about everything the API reference leaves out: the gap between the documented flow and what actually happens to money, the way authorization and settlement drift apart, the forty transactions that settled while your database said they failed, and the compliance meeting where nobody could say what "compliant" meant for the codebase.
It comes out of years of building and operating payment systems against Nigerian banks, aggregators and wallet providers, where the documentation gap is wide and the failure modes arrive early. The lessons travel. If you integrate with card networks, bank rails or any provider whose "success" response is really a promise, the same patterns apply.
Who this is for
Backend engineers who own a payment integration, or are about to. Senior engineers moving into fintech who want to know what is different about money. Staff engineers who need to explain settlement timing, chargeback economics or data residency to people who do not read code. Each part stands alone, but they are written to be read in order.
The four parts
- Part 1The Map Is Not the Territory: Payment Rails in ProductionAuthorization and settlement are separate systems with separate timelines. Learn the real-world complexities of payment rails that documentation won't tell you.10 Dec 2024 · 8 min read
- Part 2The Three Flows: A Mental Model for Debugging Payment SystemsThe Three Flows framework: funds, data, and reconciliation. Turn payment debugging from guesswork into forensic science.01 Jan 2025 · 7 min read
- Part 3Handling Payment Exceptions: Chargebacks, Reversals and DisputesPayment engineers spend 80% of their time on 5% of transactions. Learn how to architect exception handling, dispute flows, and ledger reconciliation.10 Feb 2025 · 6 min read
- Part 4The Fintech Staff Engineer: Translating Compliance into ArchitectureA framework for fintech staff engineers to translate vague compliance mandates into concrete technical requirements, architecture patterns, and SDLC processes.16 Mar 2025 · 6 min read
What you will take away
- Why authorization is a question and settlement is the answer, and what to do in the hours or days between.
- The Three Flows model (funds, data, reconciliation) and how to use it to debug a stuck payment or evaluate a new provider.
- How to model chargebacks, reversals and partial captures as state machines on an append-only ledger instead of as errors.
- A method for turning a regulation such as PCI DSS or an AML rule into specific technical controls and audit evidence.
Related reading
The series leans on ideas covered elsewhere on this site.Transaction management in .NET covers the database-side guarantees a ledger depends on, andQuorum is a maker-checker approval engine built for exactly the kind of high-value operations these essays describe. It's open source, withdocs and a live demo on its own site.