One payment, followed all the way through: the event that starts it, the double entry that records it, the reconciliation that proves it, and the decision it eventually earns. Scroll to move through it. Everything below is written out in words on the fintech engineering page — this is the same architecture, watched instead of read.
A payment arrives as an event — a fact that happened, recorded once and never edited. That event becomes a double entry: two sides that must sum to zero, which is what makes a ledger checkable rather than merely stored. The entry is then reconciled against the bank and the gateway, because a ledger that agrees only with itself proves nothing. What survives reconciliation feeds a projection — the read model a dashboard or an API actually queries — and only then does a decision get made on numbers that have been verified rather than assumed.
Every step exists because the obvious shortcut fails in production. Storing a balance as a column loses the history that explains it. Editing a row in place destroys the audit trail an auditor will ask for. Reconciling nightly instead of continuously means a discrepancy is discovered days after the cause. The walkthrough is the argument for the long way round: each stage is the cheapest place to catch a class of error that becomes expensive further down.
The same reasoning, applied to real engagements, is written up in the ledger rebuild and the zero-downtime migration. If you would rather talk than read, describe the problem in your own words.