Most wallet bugs are not wallet bugs. They start with a balance column that gets updated in place, and they end in a support chat where the balance and the history disagree and nobody can prove which one is right.
I build it the other way round. Entries are append only. Every operation writes at least a debit and a credit and they sum to zero. Balance is a function of the journal, not a number you hope stays correct. A rollback is a compensating entry, so the original stays where it is and the account can still be explained a year later.
What you get:
A ledger schema covering the operations your product actually performs, in SQL, with the migration path from what you have now.
Idempotency keys with scope and TTL decided before anything is written, because that is a contract question and not an implementation detail.
A defined inverse for every money operation that can be reversed.
Tests about ordering rather than handlers. The useful ones are the cases where a rollback arrives before the operation it reverses, or twice.
A snapshot layer if your reads need one, with the invalidation written down.
Background: I ran this in production for three years on a platform doing 3,000 requests per second at peak, multi currency, fiat and crypto. Settlement has not produced a financial discrepancy in that time.
Send me the schema you have, or just a description of what money can do in your product, and I will tell you before you pay whether this is a repair or a rebuild.
