In most software, a bug degrades an experience. In fintech, a bug moves money that should not have moved, and the consequences are a customer complaint, a regulatory event and a reconciliation exercise that consumes a week. The engineering has to be built around that asymmetry.
The ledger is the product
Storing a balance as a number you increment is the mistake everything else follows from. A double-entry ledger of immutable entries, with the balance derived, means every figure has a history and any disagreement is resolvable by inspection. Correcting an error becomes a compensating entry rather than an untraceable update.
Never store a balance you can edit. Store the entries and derive it.
Idempotency everywhere money moves
Networks time out, users double-tap and queues redeliver. Every money-moving endpoint takes an idempotency key, stores the response against it and returns that response on retry. This one pattern prevents the most expensive class of defect in the sector, and it is cheap to implement at the start and painful to retrofit.
Reconcile daily, automatically
Your ledger and the provider's settlement file will diverge — timing differences, failed callbacks, partial refunds. The question is whether you discover that daily by automation or monthly by a customer complaint. Automated reconciliation with an exceptions queue is core infrastructure, not back-office tooling.
Webhooks are unreliable by nature
Payment callbacks arrive late, twice, out of order, or not at all. Treat them as hints rather than truth: verify signatures, handle duplicates through idempotency, and run a polling reconciliation for anything not confirmed within a window. Systems that trust webhooks as the sole source of truth fail in ways that are hard to detect.
Keep card data out of scope
Provider tokenisation means raw card details never touch your systems, which reduces PCI scope from an organisational programme to a much narrower question. This is an architectural decision made once at the beginning, and reversing it later is extremely expensive.
Design reporting from the ledger
Regulatory reports assembled by hand before a deadline are error-prone and unrepeatable. Generating them from the ledger means the report is reproducible, traceable to entries and consistent between periods — and it turns a recurring week of work into a query.
