The scariest bug in payments isn't a crash. It's paying someone twice and never knowing.
A payment state machine that can't double-spend
The scariest bug in payments isn't a system crash. It's paying someone twice and never noticing until the month-end numbers don't line up.
I built an account-to-account payments engine specifically to make that impossible.
Two design choices do the heavy lifting.
First, every payment is a state machine rather than a boolean. A transfer moves through created, presented, pending, settled, reconciled, with explicit failure and indeterminate states. There is no "we sent it, probably fine." A network timeout lands in an indeterminate state that gets resolved deliberately, so it never gets silently retried into a duplicate.
Second, every movement of money is a balanced double-entry ledger record in integer minor units. Debits equal credits or the transaction doesn't exist. The books can't drift, because drift would mean an unbalanced entry the system refuses to write.
This is the mindset payments demand. Assume the network lies, assume messages arrive twice, and make the wrong outcome impossible to represent rather than merely unlikely.
If you're building anything that moves value, whether that's wallets, marketplaces, or agent-driven payments, this is the layer that keeps you out of a reconciliation nightmare.
Want the full state diagram? Ask and I'll share it.