Problem Statement & Context
What a payment gateway does and why it matters
Problem Statement & Context
A payment gateway is the security and reliability layer between merchants and the payment networks. It accepts card/bank details, tokenizes them, and orchestrates authorization → capture → refund → settlement. It is one of the highest-trust services in commerce because a single request path touches money, identity, and compliance at once.
The two journeys
- Customer: enter card → gateway tokenizes + creates a payment intent → 3DS/OTP if required → approve/decline → receipt.
- Merchant: create intent (amount, currency) → confirm authorization → capture when ready → webhooks + reconcile → settlement to bank.
Why this is the hardest correctness problem in commerce
The load-bearing requirement is brutal and simple: never charge a customer twice, and never lose a charge — even though the request path crosses the public internet, a flaky processor, and several services that can each fail mid-flight. A retried checkout, a processor timeout that actually succeeded, a duplicate webhook — every one is a chance to double-charge or drop money. So the whole design is organized around two invariants: idempotency (every money operation is keyed so a retry is a no-op) and a double-entry ledger (every movement is a balanced, append-only fact). Throughput matters, but correctness is non-negotiable — a gateway that is fast but occasionally double-charges is worthless.
Scale anchors
150M monthly shoppers; 25M checkout attempts/day; 6× promo peaks; webhook fan-out to 100K merchants. These anchor latency budgets, queue sizing, and ledger sharding.
Key Highlights
- •A payment gateway is the security + reliability layer between merchants + payment networks: tokenizes card/bank details + orchestrates authorization -> capture -> refund -> settlement — the highest-trust service (one path touches money, identity, compliance)
- •Two journeys: customer (enter card -> tokenize + create payment intent -> 3DS/OTP if required -> approve/decline -> receipt), merchant (create intent -> confirm auth -> capture when ready -> webhooks + reconcile -> settlement to bank)
- •The load-bearing requirement: NEVER charge twice + NEVER lose a charge, even though the path crosses the public internet, a flaky processor, and several services that can fail mid-flight (a retried checkout, a timeout that succeeded, a duplicate webhook are all chances to double-charge or drop money)
- •The whole design is organized around two invariants: idempotency (every money op keyed so a retry is a no-op) + a double-entry ledger (every movement a balanced append-only fact) — correctness is non-negotiable, a fast gateway that occasionally double-charges is worthless; anchors 150M shoppers, 25M checkouts/day, 6× peaks, 100K merchants
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will separate authorization from capture to keep payment state explicit."
- "We will isolate PCI scope by pushing PAN data into a dedicated vault."