Double-Entry Ledger Lab (Interactive)
Post balanced integer-cent journal entries and replay an idempotent request safely. Book charges as immutable debit/credit entries in integer cents, with idempotency keys making retried posts safe.
Stripe-style Payments: Integer Cents, Double-Entry, Idempotent Retries
Submit the same charge three times and watch whether the immutable ledger books it once or thrice.
› Nothing submitted yet — Idempotency-Key "charge-order-123" is unused.
Every charge posts two credits out of one clearing debit: merchant payout + platform fee. Retrying with the same key replays the cached response.
The golden rule: balances are never mutated — UPDATE accounts SET balance = balance - ? is how money vanishes under concurrency and debugging. Double-entry bookkeeping makes every transaction a pair of immutable rows whose debits and credits must sum to zero, so a nightly reconciliation job just diffs the ledger against the bank's settlement file instead of trusting an accumulator. Currency stays integer cents: $0.1 + $0.2 ≠ $0.3 in IEEE-754 floats, and a payment system cannot round money into existence.
How It Works Under the Hood
Money systems never store a mutable balance; they store an append-only journal of double entries where every debit has a matching credit, and the balance is a derived sum. Amounts are integer cents, never floats, so a $10.00 charge with a 2.9% fee becomes a clean debit to clearing and credits to merchant and fee, and the tiles must always reconcile to zero. Reconciliation compares ledger totals to the bank feed, and duplicates surface instantly. A retried charge must not post twice, so the Idempotency-Key dedups the post: replaying the same key returns the booked result without new entries.
Core Architectural Principles
- Every post writes balanced integer-cent entries: debit clearing, credit merchant plus credit fee floored from bps.
- The ledger invariant is sum(debits) equals sum(credits) — a mismatch is a bug, not rounding.
- Replaying an Idempotency-Key returns the booked result; without it the charge posts twice.
Lead with append-only double entry and derived balances, which give auditability and no lost updates under concurrency. Insist on integer minor units such as cents over floats and floor-based fee math. Then cover idempotency keys for safe retries and reconciliation against the bank or processor feed as the truth-check. Mention posting-date ledger partitions and reversal entries instead of deletes.
Append-only double entry is auditable and race-safe but makes balances a derived aggregate that needs materialization for fast reads.