15. Payment System (Stripe-like) Advanced + Financial Correctness

A. Realistic Interview Prompt

Every other problem in this document treats "eventually correct" as an acceptable, even desirable, default — a stale feed, a slightly-late notification, a seat map that catches up a second later are all harmless. This problem is the one place in the set where that default is simply wrong for the core of the system: money that appears to move but didn't, or moves twice when it should have moved once, isn't a UX rough edge, it's an incorrect fact the business is now on the hook for. The load-bearing decision this design is built around is: treat an append-only, double-entry ledger as the single source of truth for every dollar that moves — balances are always computed from it, never stored and mutated directly; require a client-supplied idempotency key on every mutating request at the API boundary, non-negotiably, because "retry" is the normal behavior of every real network client; sequence a payment's multiple steps (charge the card, write the ledger, notify the merchant) as an explicit saga with a defined compensating action for any step whose side effect already happened when a later step fails; and run asynchronous reconciliation jobs that independently compare the internal ledger against the payment processor's own records, on the assumption that "should never happen" and "cannot happen" are different claims, and this domain is exactly the one where you build the safety net for the gap between them anyway.

B. Difficulty

Advanced — almost none of the individual mechanisms here are exotic (an idempotency key, a ledger table, a background reconciliation job are each independently simple to describe), but the domain has essentially zero tolerance for the small approximations that make every other problem in this document tractable. A candidate who reflexively reaches for "eventually consistent, we'll converge" without first identifying exactly which piece of this system cannot be allowed to converge after the fact — because by then real money has already moved incorrectly — is the most common way this problem goes wrong at the senior level.

C. What This Problem Tests

• Recognizing idempotency (Prerequisites O, Patterns Playbook E) not as a nice-to-have but as the load-bearing, non-negotiable mechanism for this specific domain — and being able to say precisely why a domain like Chat System (P4) can tolerate the rare, harmless duplicate that a payment system structurally cannot
• Recognizing that "store a balance, update it" is the naive answer that a candidate without financial-systems exposure reaches for by default, and knowing the concrete reason a real system never does this — auditability and the ability to detect corruption after the fact, not just performance
• Distinguishing an ambiguous outcome (a network call timed out — did the side effect happen or not?) from a definite failure, and knowing that only one of those two situations is ever safe to blindly retry
• Recognizing when a multi-step process with real, already-happened side effects needs a formal saga with per-step compensation, rather than an ad hoc sequence of calls with a vague "roll it back somehow" gesture at the end
• Building a genuine second line of defense (reconciliation) on top of a first line of defense (idempotency, the saga) that is expected to already be correct — and explaining why a mature financial system still builds the second line anyway

D. Requirements

Functional

1. A merchant can charge a customer's stored payment method for a specified amount, in a specified currency
2. A merchant can refund a charge, in full or in part, and can issue multiple partial refunds against the same original charge as long as their total doesn't exceed it
3. A merchant (or the merchant's own system) can query the current status of any payment or refund at any time
4. The system notifies a merchant asynchronously (via webhook) whenever a payment's status changes, including changes driven by the payment processor itself after the fact (e.g. a dispute)
5. Every mutating request is safe to retry any number of times without repeating its real-world financial effect

Non-Functional

• No double effect, ever — the single hardest constraint in this document: a retried charge or refund request must never result in the money moving twice
• Auditable and reconstructable — any account's balance, and the full history of how it got there, must be independently derivable from durable records alone, without trusting any single cached number
• Strongly consistent at the ledger core — a transaction's financial entries either all commit together or none do; there is no acceptable "partially happened" state for a movement of money
• Resilient to partial failure mid-transaction — if a multi-step payment fails partway through, whatever already happened must be either completed or correctly unwound, never left in an ambiguous middle state
• Highly available on the read/query path — checking a payment's status should not be gated behind the same strict consistency the ledger write itself requires

Out of scope: actual card-network/PCI-compliant tokenization internals (assumed handled by a compliant vendor or sub-processor); fraud/risk scoring models; full multi-entity accounting/tax reporting; building the payment processor itself — this system is the layer that sits in front of and orchestrates a processor, mirroring Stripe's own position in front of the underlying card networks.

E. Clarifying Questions

F. Assumptions

• Confirmed: charge, refund (full and partial), status query, and async merchant notification, with zero tolerance for a duplicated financial side effect.
• Assumption: this system sits in front of an already-PCI-compliant, external card-network-connected payment processor (E's clarifying question 1) — card tokenization, the actual card-network rails, and PCI scope are the processor's problem, not this design's; this system's job is orchestrating charges, ledger correctness, and notification against that processor as a dependency with its own latency and its own failure modes.
• Assumption: multi-party splits (platform fee, marketplace payouts) are a real, in-scope requirement, not a hypothetical extension (E's clarifying question 2) — the ledger schema (K) is designed from the outset to let one transaction fan out across an arbitrary number of accounts, not just two.
• Assumption: a charge can be confirmed asynchronously — the merchant's checkout gets an immediate "processing" response and a webhook once the outcome is known, rather than the whole saga completing inline within one HTTP request (E's clarifying question 3) — this is what lets the saga's later steps (ledger write, notification) run reliably in the background rather than under the pressure of a single request's timeout budget.
• Assumption: multi-currency is in scope (E's clarifying question 4) — every ledger entry carries a currency and, for cross-currency transactions, an explicit conversion leg.
• Assumption: a realistic idempotency-key retry window is bounded to roughly 24 hours (E's clarifying question 5) — long enough to cover a client that legitimately retries hours later after being offline, short enough to keep the key store's size proportional to a single day's request volume.

G. Capacity Estimation

H. Core Entities

I. API Design

-- merchant-facing (all mutating calls require an Idempotency-Key header):
POST /payment_intents { amount, currency, customer_payment_method_id }
     Idempotency-Key: <client-generated>  -> { intent_id, status: "processing" }        (M, L)
GET  /payment_intents/{intent_id}          -> { status, amount, ledger_summary }         (L)
POST /payment_intents/{intent_id}/refunds { amount (optional, partial) }
     Idempotency-Key: <client-generated>  -> { refund_id, status: "processing" }        (S)
GET  /refunds/{refund_id}                  -> { status, amount }                          (S)
-- outbound, system-to-merchant:
POST {merchant.webhook_url} { event_id, type: "payment_intent.succeeded" | ".failed" | ".refunded", ... }   (R)
-- inbound, processor-to-system:
POST /internal/webhooks/processor { event_id, type, payment_reference, ... }             (O, R)
-- internal, cluster-facing:
(saga orchestrator) drives: authorize -> ledger write -> notify, with compensations       (P)
(reconciliation worker) periodic: diff ledger vs processor settlement report              (Q)

Why every mutating endpoint requires Idempotency-Key, not just recommends it: this is the one API-design decision this entire problem is built around (Prerequisites O, Patterns Playbook E) — a request without a key isn't a convenience trade-off the way an optional header might be elsewhere, it's a request the system has no way to protect against a client's own retry, and is rejected outright rather than processed unprotected.

Why GET /payment_intents/{id} and the refund/status endpoints are safe without an idempotency key: they're pure reads with no side effect to protect against duplication — idempotency keys guard mutations specifically, the same distinction Prerequisites O draws generally.

J. Basic / Naive High-Level Design (V1)

The simplest thing that satisfies the functional requirement in isolation: a single accounts table with a balance column per merchant; charging a customer calls the payment processor directly, and on success runs UPDATE accounts SET balance = balance + amount WHERE merchant_id = ?. No idempotency key is required anywhere in this flow.

V1 — a direct, synchronous charge-then-mutate-balance flow, with nothing protecting against a retried request.

Why this breaks, in the two ways that matter most: first, and most dangerously, a client whose charge request times out — the processor charged the card, but the response never made it back — has no safe way to retry: calling the same endpoint again with no idempotency key charges the customer a second time, and there is nothing in this design that can tell the difference between "this is a genuinely new charge" and "this is the same charge, retried." Second, even setting retries aside, mutating a balance column directly destroys the one thing a financial system is obligated to preserve: a reconstructable history. If that balance is ever wrong — a bug in the update logic, a partially-applied migration, a race no one noticed — there is no way to determine how it became wrong, or what the correct value should have been, because the individual facts that produced it were never recorded, only their net effect. Both flaws point at the same root cause: this design has nothing durable and immutable underneath the number it reports, and nothing distinguishing a repeated request from a new one.

K. Data Model & Store Choice

The double-entry ledger schema, the central structural decision this entire design is built around: every financial event is recorded as a LedgerTransaction grouping two or more LedgerEntry rows, each tagged debit or credit against a specific Account (H) — and the one invariant enforced on every single write is that a transaction's entries must sum to zero (every debit balanced by an equal credit, the literal accounting definition of "double-entry"). A simple merchant charge touches at least two accounts — debit processor_clearing (money now sitting with the processor, not yet settled), credit merchant_payable:{merchant_id} (what the platform now owes that merchant) — and a transaction with a platform fee or a marketplace split (F, E's clarifying question 2) simply adds more balanced legs to the same transaction, crediting platform_revenue and debiting the merchant's payable proportionally, with the invariant holding regardless of how many accounts a single transaction ultimately touches.

Why this lives in a relational database with real ACID transactions (Prerequisites B), not a document store or a loosely-consistent key-value store: writing a LedgerTransaction's several balanced entries must be all-or-nothing — if the process crashes after writing the debit but before the credit, the ledger is left in a state that structurally cannot exist under the double-entry invariant, and any account balance derived from it (N) is now silently wrong. Wrapping every entry belonging to one transaction_id in a single database transaction, committed atomically, is what makes "the ledger can never be observed in an unbalanced state" a guarantee enforced by the storage layer itself, not a discipline hoped for at the application layer.

Sharding the ledger: partitioned by merchant_id (the same natural-ownership-key reasoning as Patterns Playbook G) so one merchant's transaction volume doesn't contend with another's, with the platform-wide accounts (platform_revenue, processor_clearing) either replicated read-heavy or handled by a small set of dedicated high-throughput shards, since nearly every transaction touches one of them. A single transaction that spans a merchant-owned account and a platform-wide account still commits atomically because both live inside the reach of one database transaction on the shard that owns that specific write.

Why Account itself carries no balance field at all: this is the direct, deliberate fix for V1's core flaw (J) — an account is purely an identity that ledger entries reference; its balance is never a column anyone writes to, only a value computed from the entries that reference it (N).

L. End-to-End Flow — A Customer Pays a Merchant: Charge, Ledger, Notification, All Idempotently

Every step downstream of the idempotency check is itself idempotent or safely retryable — a retried request with the same key at any point simply returns the already-recorded outcome instead of re-running any step.

M. Deep Dive 1 — Idempotency at the API Boundary

Requirement this addresses: the no-double-effect NFR (D) — the single most consequential mechanism in this entire design, directly fixing V1's fatal flaw (J).

Why this is non-negotiable here specifically, more than anywhere else this document uses the same mechanism: Prerequisites O establishes the general case — a client can't tell "my request never arrived" apart from "it arrived, succeeded, and the response was lost" — and Patterns Playbook E catalogs three prior instances of the fix (Chat's client_msg_id, Ticketmaster's payment-confirmation key, Job Scheduler's execution key). What's different here is the cost of getting it wrong: a duplicated chat message is a harmless annoyance a user can delete; a duplicated job execution is often reversible; a duplicated charge is money that has to be manually identified, refunded, and apologized for, and it erodes the one thing a payment provider is fundamentally selling — trust that the number it reports is correct. This is why idempotency keys are mandatory and rejected-if-absent here (I), not merely supported.

Storage and the request-fingerprint check: an IdempotencyKeyRecord (H) is keyed by (merchant_id, key) — scoped per merchant, since two unrelated merchants independently choosing the same key string must not collide — and stores a hash of the full request body alongside the key. A repeat request with the same key and the same request fingerprint returns the original cached response with no side effect repeated; a repeat request with the same key but a different body (a client bug reusing a key for a genuinely different charge) is rejected outright with a clear conflict error, rather than either silently executing a second charge or silently returning the wrong cached result for a different request.

The concurrent, still-in-flight case — a second race, one level up from Pattern 1: if a second request with the same key arrives while the first is still being processed (a client that fires a fast, automatic retry before the first attempt has even finished, not after a timeout), simply checking "has this key been seen" isn't enough — both requests could observe "not yet seen" and both proceed. The fix is the same check-then-act discipline as Patterns Playbook B, applied to the idempotency record itself: a unique constraint on (merchant_id, key) combined with an atomic insert-if-absent means the second request's insert fails immediately, and it's told to wait for or poll the first request's outcome rather than being allowed to also attempt the charge.

TTL, and why it's bounded rather than permanent: keys expire after roughly 24 hours (G, F) — long enough to cover a client that legitimately retries after being offline for hours, short enough that the key store's size stays proportional to a single day's request volume rather than growing forever. This mirrors the same trade Ticketmaster's reservation-hold TTL makes (P8, Deep Dive N) for a different resource entirely — a bounded window that's generous for the real, legitimate case and cheap to eventually reclaim.

N. Deep Dive 2 — The Double-Entry Ledger as the Single Source of Truth

Requirement this addresses: the auditable/reconstructable NFR (D) — the second half of V1's core flaw (J), independent of and complementary to idempotency (M): idempotency prevents a bad write from happening twice; the ledger design is what makes every write that does happen permanently, independently verifiable.

Why a balance is a computed value, never a stored, mutated field: an account's balance at any point in time is SUM(credits) - SUM(debits) over every LedgerEntry referencing that account (K) — not a column anyone ever runs UPDATE ... SET balance = balance + x against. This is the direct, structural fix for V1's second flaw: because every entry that ever affected an account is preserved, permanently and unmodified, that account's balance at any past moment is independently reconstructable by literally anyone with read access to the ledger — an internal auditor, an external regulator, a support engineer investigating a customer's complaint — without needing to trust that some other piece of code correctly maintained a running total. A cached, precomputed balance is a legitimate performance optimization (a materialized summary table, refreshed by a background job) but it is never the source of truth — it's always re-derivable from, and checkable against, the entries themselves.

Why "just add an audit log next to the mutable balance" doesn't get you the same guarantee: a common instinct is to keep V1's balance column for fast reads, and bolt on a separate log of "what changed" for audit purposes. This is subtly, importantly different from the ledger being the source of truth: if the balance column and the log can ever drift — a bug that updates one but not the other, a crash between the two writes — there is no way to know, after the fact, which one is correct, because neither is defined as authoritative over the other. The double-entry ledger design doesn't have this problem because there is only one write path and only one source of truth; a "current balance" is a query against it, not a second, independently-maintained fact that could disagree with it.

Why the double-entry invariant itself (debits = credits, always) is what makes reconciliation (Q) possible at all: because every transaction is mechanically checkable for internal balance at write time, and the sum of every account's net position across the whole ledger is mathematically guaranteed to be zero, a reconciliation job has a precise, checkable property to test against — "does this match the processor's records" is a well-posed question specifically because the internal side of the comparison is a rigorously balanced structure, not an arbitrary mutable number that could be wrong in ways nobody can even characterize.

O. Deep Dive 3 — Handling Processor Timeout Ambiguity

Requirement this addresses: the no-double-effect NFR (D), for the specific case where the ambiguity originates outside this system's own boundary — the call to an external payment processor times out.

The exact ambiguity, stated precisely: the saga (P) calls the processor to authorize and capture a charge; the call times out before a response arrives. Three things could actually be true: the processor never received the request at all; the processor received it and is still processing; or the processor received it, successfully charged the card, and the response confirming that was simply lost on the way back. From this system's side, these three cases are indistinguishable by the timeout alone — and blindly retrying the charge call is only safe in the first case. Retrying in the third case charges the customer's card twice, entirely outside the reach of this system's own idempotency-key store (M), because the duplication would happen on the processor's or card network's side, not at this system's API boundary.

The fix — query status, don't guess: the same idempotency key generated at this system's API boundary (M) is also passed downstream to the processor on the original charge call, so the processor itself can deduplicate a retried call carrying the same key — most real processors support exactly this (AD). But relying on that alone still leaves this system without a definite answer to act on. The correct move on an ambiguous timeout is not to immediately retry the charge call — it's to query the processor's own transaction-status endpoint for that specific reference, and read back a definite answer (succeeded, failed, or still processing) before the saga decides what to do next. Only once that answer is known does the saga either proceed down the success path (ledger write, notification) or safely retry the original call, now knowing it genuinely never landed.

Why this is the single most consequential deep dive for preventing an actual double charge: idempotency keys (M) protect against a client-initiated retry at this system's own boundary; this mechanism protects against the different, equally real failure mode of this system's own outbound call to the processor being ambiguous. Both are necessary; neither alone is sufficient — a design with perfect API-boundary idempotency but a "just retry on timeout" policy toward the processor is still exposed to exactly the failure this deep dive exists to close.

P. Deep Dive 4 — The Saga Pattern for Multi-Step Transactions

Requirement this addresses: the resilient-to-partial-failure NFR (D) — a payment is never really one atomic step; it's authorize-with-processor, then write-the-ledger, then notify-the-merchant, and each of those can fail independently, after the ones before it already produced a real, external side effect.

Orchestration, chosen over choreography: in a choreographed design, each service reacts to events published by the one before it (the processor-adapter service publishes "charge succeeded," the ledger service listens and writes, then publishes its own "ledger written" event, and so on) — appealingly decoupled, but the direct cost is that no single place holds the full picture of one specific payment's progress; reconstructing "what exactly happened to this $47.20 charge, step by step" means piecing it together from a scattered event trail across services. In an orchestrated design, a central saga coordinator explicitly issues each step in sequence and explicitly persists which step a given PaymentIntent is currently on — the same durable-workflow-orchestration concept named for Ride-Sharing's multi-step match/accept sequence (P5-Q), reused here for a financial chain instead of a matching retry loop. For a domain where an auditor, a support engineer, or a regulator will eventually ask exactly that "what happened, step by step" question, having one durable, queryable record of a transaction's progress is worth the coupling cost choreography avoids.

Why step 3 deliberately needs no compensation, and why that distinction matters: steps 1 and 2 move real money or record a real financial fact — failing to compensate them leaves an incorrect state that persists. Step 3 only moves information about a fact that's already correctly settled by steps 1-2; failing to notify delays visibility, it doesn't corrupt anything, so retrying without compensating is the right, cheaper answer specifically because the failure mode is fundamentally different in kind, not just in severity.

The direct relationship to Ticketmaster's payment sequencing (P8, Deep Dive Q): Ticketmaster deliberately sequences its own payment step strictly after the seat hold succeeds — and, notably, is the one explicit exception in this document to reflexively moving slow work off the hot path (Patterns Playbook C), because the user is actively waiting on a definitive yes/no. That two-step sequence (hold, then charge, with a single compensating action — release the seat — if the charge fails) is the minimal case of exactly this pattern: one point of failure, one compensation. This design generalizes the identical idea to an arbitrary-length chain, with its own explicit compensation defined per step, which is precisely the point at which an ad hoc "hold then charge" sequence stops being sufficient and a formally named saga, with an orchestrator that persists progress durably, becomes the right tool to reach for.

Q. Deep Dive 5 — Async Reconciliation Jobs

Requirement this addresses: auditability (D) — a deliberate second line of defense, built on the assumption that idempotency (M) and the saga's compensations (P) are already correct, but that "should never happen" and "cannot happen" are different claims, and this is exactly the domain where you build the safety net for the gap between them anyway.

The mechanism: a periodic batch job (daily, or more frequently for higher-value merchants) pulls the payment processor's own settlement report — a file or API listing every transaction the processor believes it processed and settled — and diffs it against the corresponding internal ledger transactions. Three categories of mismatch matter:

• Internal ledger shows succeeded; processor has no matching record. Most likely a bug somewhere in the saga (P) or a misread response — this is the scariest category, because it implies this system believes money moved that never actually did.
• Processor settled a different amount than the ledger recorded. Often a currency-conversion or fee-calculation discrepancy — smaller in impact, but still a real drift between what the system believes and what actually happened.
• Processor has a settled transaction with no corresponding internal record at all. Frequently traces back to a dropped or unprocessed webhook (R) — money moved, and this system doesn't yet know it.

Auto-resolve narrowly, escalate everything else: a mismatch within an explicitly tolerated, well-understood bound (a sub-cent rounding difference from currency conversion) can be auto-corrected with a small, explicitly-tagged correcting LedgerTransaction (N) — never a silent mutation, always a new, attributable entry. Anything outside that narrow, well-understood category goes to a manual review queue rather than being auto-corrected on a guess, because guessing wrong here isn't a UX inconvenience, it's a real, incorrect movement of money layered on top of the first mistake.

Why this is explicitly a second line of defense, not the primary mechanism: reconciliation runs hours after the fact, at best — it is far too slow to be the thing that prevents a double charge in the moment (that's M and O's job) or that unwinds a failed multi-step transaction promptly (that's P's job). Its value is entirely in catching whatever slips past those first-line mechanisms anyway — a bug in the saga orchestrator, a webhook silently dropped, an edge case nobody anticipated — which is precisely why a mature financial system runs it unconditionally, not as an afterthought bolted on only once a discrepancy is first discovered the hard way.

R. Deep Dive 6 — Idempotent Webhooks from the Payment Processor

Requirement this addresses: the async-notification functional requirement (D) — but inbound this time: the processor telling this system that something changed, not this system telling a merchant.

At-least-once, out-of-order delivery is the expected default, not an edge case: the processor delivers webhook events for state changes (a charge settling, a later dispute, a refund confirming) the same way every real-world async delivery mechanism in this document works — at-least-once, per the same underlying admission named in Prerequisites O that exactly-once delivery isn't achievable over a network. A slow acknowledgment from this system triggers the processor's own redelivery, so the same event can legitimately arrive more than once; a network partition on the processor's side can deliver events out of their logical order (a dispute notification arriving before the succeeded event that logically precedes it).

Dedup by the processor's own event ID, a different key from the API-boundary idempotency key: each inbound WebhookEvent (H) carries an event_id assigned by the processor itself — a distinct identifier from the Idempotency-Key a merchant supplied when originally creating the charge (M). A WebhookEvent row keyed by that event_id, checked before any processing logic runs, means a redelivered event is acknowledged with a 200 OK immediately, with no side effect repeated, regardless of how many times the processor resends it.

Handling out-of-order arrival without assuming delivery order matches logical order: a PaymentIntent is modeled as a small, explicit state machine with a defined set of valid transitions (created → processing → succeeded → refunded, or created → processing → failed). An incoming event that doesn't represent a valid transition from the record's current state — a refund-confirmed event arriving before the succeeded event that logically precedes it — is not blindly applied; it's queued or retried briefly rather than forced through, on the reasonable expectation that the missing predecessor event is likely already in flight and will arrive shortly. This is a cheaper, more targeted fix than trying to impose a strict global order on webhook delivery itself, which the processor doesn't guarantee and this system can't control.

S. Deep Dive 7 — Handling Refunds & Partial Refunds

Requirement this addresses: refund and partial-refund functional requirements (D) — and a direct test of whether N's ledger discipline was actually internalized, not just applied to the happy-path charge.

A refund is a new, balanced LedgerTransaction, never a deletion or a mutation of the original: exactly the same principle N establishes for the original charge — the original charge's entries are permanent history and are never touched. A refund reverses the charge's economic effect by writing a fresh transaction whose entries move the same amount in the opposite direction (credit back toward the customer-facing side, debit out of merchant_payable), explicitly referencing the original transaction_id it reverses. The ledger after a refund shows both the original charge and its reversal, in full — the honest, complete history of what actually happened, rather than a record edited to look as if the charge never occurred.

Partial refunds are the identical mechanism at a lesser amount, with one derived value that matters: a charge's remaining refundable balance is computed, not stored, as original_amount − SUM(refund amounts already issued against it) — read live from the ledger each time it's needed, the exact same "derive, don't mutate" discipline N applies to account balances generally, reapplied here to a different number. A second partial refund attempt is validated against this freshly-computed remaining balance, which is what correctly prevents refunding more than was ever charged even across several independent partial refunds issued at different times.

Refunds get their own idempotency key and their own saga, not a shortcut through the charge's existing machinery: a refund is exactly as much a mutating financial side effect as the original charge (I) — it moves real money back toward the customer and deserves identical protection: a client-supplied Idempotency-Key (M) so a retried refund request never issues the refund twice, and its own saga sequence (call the processor to reverse the charge, write the reversing ledger transaction, notify the merchant) with the same per-step compensation reasoning as P, applied to the refund's own steps rather than assumed to be automatically covered by the original charge's machinery.

T. Full Solution at Scale — Final Architecture

The idempotency store and the ledger's ACID core are the two genuinely strongly-consistent pieces (V); the saga durably tracks progress across everything downstream of them, and reconciliation independently double-checks the whole picture after the fact.

U. Design Evolution

What stays stable throughout: the small, idempotency-key-gated PaymentIntent/Refund contract from I — every later refinement changes how a request's side effects are sequenced, recorded, or double-checked, never the basic shape of what a merchant actually sends and receives.

V. Consistency Model

This is, alongside Ticketmaster (P8), one of the two most strongly-consistency-weighted designs in this document — but for a genuinely different underlying reason, worth stating precisely rather than lumping the two together. Ticketmaster's strong consistency (P8-V) protects a scarce, physically singular resource — a seat that cannot exist in two "sold" states, because only one buyer can ever actually sit in it. This system's strong consistency protects a mathematical invariant — a transaction's debits and credits must sum to zero, or the ledger's own record of reality is simply false, independent of any resource being contended for. Every LedgerTransaction commits as a single ACID unit (K, N) — there is no acceptable "partially written" or "eventually balances" state, which is a materially stronger requirement than Prerequisites L's general CAP/PACELC framing allows for the rest of this design: this is not a system choosing availability over consistency for its ledger core, full stop.

And yet — this is the detail worth making explicit in an interview — nearly everything surrounding that strongly-consistent core is deliberately asynchronous and only eventually consistent: outbound merchant notification (R) can lag by seconds without harm; the reconciliation job (Q) runs hours after the fact by design; even the idempotency key store (M), while itself requiring an atomic insert-if-absent, only needs to be consistent for the duration of its TTL, not forever. The strong-consistency requirement is scoped as narrowly as possible (Patterns Playbook J) — to the ledger commit itself, and nothing wider — precisely because delay in telling someone about a financial fact is harmless, while the fact itself ever being wrong, even briefly, is not. This narrow-island shape is the same general pattern Patterns Playbook J catalogs elsewhere, applied here to the single highest-stakes island in the entire document.

W. Failure Scenarios

• The idempotency key store is unavailable when a charge request arrives: the request is rejected outright rather than processed unprotected — failing closed, not open, is the only acceptable choice when the alternative is an unprotected charge attempt (M).
• The processor call times out with an ambiguous outcome: the saga queries the processor's status endpoint for a definite answer before deciding whether to proceed or retry — never a blind retry (O).
• The saga orchestrator crashes mid-sequence: because its progress per PaymentIntent is durably persisted, not held only in memory, it resumes from the last completed step on restart — no step is blindly re-executed, and no step is silently skipped (P).
• A ledger write partially fails (some but not all of a transaction's balanced entries would commit): the enclosing ACID transaction rolls back atomically (K) — an unbalanced ledger state is structurally impossible to observe, not merely unlikely.
• A processor webhook is redelivered many times: dedup by event_id (R) makes every redelivery beyond the first a pure no-op — no repeated state transition, no repeated side effect.
• Reconciliation finds a discrepancy with no obvious explanation: it's escalated to manual review, never auto-corrected on a guess (Q) — an unexplained mismatch in a financial system is exactly the case where a wrong automated fix is worse than a delayed correct one.

X. Bottlenecks & Scaling Boundary

Y. Design Trade-Offs

Z. Common Bad Designs

• Mutating a balance column directly with plain UPDATE statements. The single most important mistake to avoid on this problem — it destroys the reconstructable history a financial system is obligated to preserve, independent of any concurrency concern.
• Treating a disabled submit button as sufficient duplicate protection. Client-side UI state has nothing to do with what happens at the network and server layer — a dropped connection and an automatic client retry happen well below where a disabled button could ever intervene; only a server-side idempotency key actually protects against this (M).
• Blindly retrying a timed-out call to the payment processor. The single most common way this specific problem produces an actual double charge — an ambiguous timeout must be resolved by querying status, not by assuming the safest guess (O).
• Treating a refund as decrementing the original charge's amount field. Erases the historical record of what was actually charged and destroys the audit trail the same way V1's mutable balance does (S).
• Treating reconciliation as optional or "nice to have, if we have spare engineering time." A financial system's whole design philosophy is that "should never happen" and "cannot happen" are different claims — skipping the second line of defense because the first line is believed to be correct is exactly the complacency this problem is built to test for (Q).
• Assuming webhooks arrive at-most-once or in logical order. Both assumptions are false in practice for any real async delivery mechanism, and a design built on them silently mishandles retried or out-of-order events instead of deliberately deduplicating and sequencing them (R).

AA. Interviewer Follow-Ups

AB. Interviewer Evaluation Rubric

• Weak candidate: proposes a mutable balance column updated directly on each charge, with no idempotency protection anywhere, and has no answer for what happens when a client retries a timed-out request.
• Mid-level: adds an idempotency key at the API boundary correctly, but still models balances as a mutated column rather than a computed ledger aggregate, and treats "roll back a failed multi-step charge" as a vague gesture rather than a concrete, per-step compensating action.
• Senior: proactively reaches for an append-only, double-entry ledger and can explain why a balance must be computed, not stored; separates the idempotency-key concern from the ledger concern cleanly; recognizes the processor-timeout ambiguity as a distinct failure mode from a client-side retry, requiring a status query rather than a blind retry.
• Staff+: is unprompted and explicit about the saga pattern's orchestration-vs-choreography trade-off and why orchestration fits a domain that will eventually need a single, queryable "what happened, step by step" answer; treats reconciliation as a deliberate, always-on second line of defense rather than a response to a specific incident; correctly scopes strong consistency to the ledger commit alone and can defend why the surrounding system is safely, deliberately async.

AC. Interview Simulation

AD. Online Solution Comparison

AE. Interview Cheat Sheet