Ledgers

• For broadly scoped payments systems, ledgers (basically double entry book keeping) will often be source of truth in your system. 10/10 IMHO.
• It’s a really a good way to get into thinking of how accounting and accountants work.
• Good resources
  • https://www.moderntreasury.com/journal/accounting-for-developers-part-i
  • https://www.moderntreasury.com/journal/accounting-for-developers-part-ii
  • https://www.moderntreasury.com/journal/accounting-for-developers-part-iii
  • https://martin.kleppmann.com/2011/03/07/accounting-for-computer-scientists.html

Safety

• Be very paranoid when building payments systems

Locking

TODO

1. You have optimistic locking and pessimistic locking

Operational Review

TODO

Idempotency keys

TODO

Reconciliation

• Reconciliation at a high level to me is verifying data (at aggregate or txn level) against other systems or reality you interact with.
• Especially important when settlement is not instant and feedback loop is delayed.
• Good philosophy is start from being paranoid and not believing transaction data in your database blindly. Reconciliations gives you confidence to trust your data.
• Inherently involves operational muscle in org. Needs someone to be responsible and reconcile every week. Ideally that person automates some parts of the recon but does spot checks as well
• interesting reads
  • https://stripe.com/in/resources/more/accounting-reconciliation-101#types-of-accounting-reconciliation
  • https://stripe.com/in/resources/more/payment-reconciliation-101

Payment Rails (or networks)

TODO

• ACH
• UPI
• Cards
• https://tautology.town/2026/06/01/card-networks.html

Stablecoins

TODO

• x402, tempo

Indian Regs

TODO

• AD1, AD2
• PPI, TPAP
• TPAP extremely hard to get
• PPI people don’t know what the fuck to build with it.
• FEMA

Gift Cards

Misc

• interesting reads
  • https://newsletter.pragmaticengineer.com/p/designing-a-payment-system