The ledger is the product
In payments, the accounting model is the one decision application code cannot recover from. Get it wrong and every feature after it inherits the error.
Most payment products are described by their surfaces: an onboarding flow, a card, a dashboard. Those are the parts a customer sees and the parts a roadmap tends to enumerate. They are also the parts that can be rewritten in a quarter without anyone outside the team noticing.
The ledger cannot. It is the one component whose mistakes compound, because every later balance, statement, reconciliation and regulatory report derives from it. A wrong ledger is not a bug to fix; it is a history to restate.
Balances are derived, never stored
The most common early shortcut is a balance column that gets updated in place. It is fast and obvious, and it destroys the one property you will need later: the ability to explain how a balance came to be what it is.
An event sourced ledger inverts this. Entries are immutable and append only, and a balance is a fold over them. Recomputing it is cheap; explaining it is trivial; correcting it means posting a compensating entry rather than mutating the past. When a regulator or a customer asks why a number is what it is, the answer is a query rather than an investigation.
Idempotency is a design property
Every integration in a payments system eventually delivers the same message twice. The network times out after the remote side has already committed; a queue redelivers; an operator replays a batch.
Teams usually discover this in production and bolt on a deduplication table. That works until its window expires, or until two paths to the same effect exist and only one checks. Idempotency belongs in the domain model: a transfer has a key supplied by the client, posting it twice is defined to be the same operation as posting it once, and the guarantee holds no matter which path reached it.
Build reconciliation alongside the ledger
Reconciliation is often treated as an operations concern, delivered late and by a different team. The consequence is a system that can tell you what it believes, but not whether what it believes matches the scheme, the partner bank or the settlement file.
Building it alongside the ledger changes what you can promise. Discrepancies surface in minutes rather than at month end, the alert fires on a business invariant rather than a stack trace, and the dashboard a compliance officer opens is the same one an engineer debugs from.
What this costs
Modelling the money first is slower to a demo and faster to a certification. It brings forward the arguments about what a transaction means, which is uncomfortable in week two and cheap compared with having them in month fourteen with live balances.
The test is simple. Ask what happens when a partner replays yesterday's file. If the answer involves a manual step, the model is not finished.
Leave with the approach, the risks and what it would take
Ninety minutes with the engineers who would do the work, on one problem you name: a processor replacement, an onboarding flow, a ledger reconciliation.