Design the payment-processing backbone that sits between a merchant's checkout and one or more external card gateways (think a popular e-commerce app clicking "Pay now"). Your service accepts a charge request, drives it through a well-defined lifecycle, talks to a flaky third-party gateway, and records the outcome in a way the finance team can trust to the last cent.

Operating context. You serve internal callers (the order and checkout services) over an internal API, not the public internet. Steady state is ~2,000 charge attempts/sec, with 4× spikes during flash sales. Each attempt fans out to exactly one external gateway call, and gateways are the slow, unreliable dependency: p99 gateway latency is 1.5 s, timeouts and 5xx happen on ~1% of calls, and a gateway can be fully down for minutes. The money numbers must be exact — a single double-charge is a customer-trust and chargeback incident, and a single lost capture is lost revenue. Charges, refunds, and reversals all flow through the same core.

Out of scope. PCI card-data vaulting and tokenization internals, fraud/risk scoring, the checkout UI, currency conversion / FX, payouts to merchants, and the gateways' own internals. Assume raw card data is already tokenized upstream and you only ever see a token.

What to produce. A high-level architecture covering: the charge request path and how a caller's retry is made safe (idempotency); the charge state machine and its legal transitions; how you call the external gateway with retries, timeouts, and backoff without ever double-charging; how the authoritative money record (a ledger) relates to the order/charge store and why they are separate; how you reconcile your state against the gateway's truth (webhooks plus a sweep) to catch stuck or unknown charges; and the failure story when the gateway times out after possibly having charged the card. Sketch the components and the request flow; we will probe specifics at checkpoints.