Case study: Payment system & ledger

Why must a payment system store monetary amounts as integer minor units (e.g. `1999` cents + `'USD'`) rather than IEEE-754 `float` or `double`?

A payment service has 200 database connections. If each charge opens a DB transaction, holds a row lock while calling an external card network (500 ms), and then commits, what is the maximum throughput?

A buggy merchant integration sends `POST /v1/payments` for 1,000 cents with `Idempotency-Key: abc`, and 5 seconds later sends a different order for 9,500 cents reusing `Idempotency-Key: abc`. What should the payment API do?

When a customer refunds a $25.00 purchase, how is the refund recorded in the ledger?

Why is writing to `ledgerdb` and then calling `queue.publish()` as two separate network calls without an outbox unsafe?

A developer implements idempotency with `SELECT * FROM idemp WHERE key = :k`, and if 0 rows return, runs the charge and `INSERT`s the key at the end. Why does this still double-charge under concurrent retries?

In the `lost-acks` scenario, the ledger DB has already committed the debit/credit pair when the response packet to `gw1` is dropped. What happens when `gw1`'s retry reaches `pay`?

Even with idempotency keys and ACID transactions, why does every production payment system run a daily reconciliation job against external PSP settlement files?