Design a Payment Gateway (Stripe/PayPal-like)

Problem statement

Design an online payment gateway in the style of Stripe or PayPal: a platform that lets merchants accept card and bank-based payments without ever touching sensitive credentials. The gateway must tokenize payment credentials, authorize, capture, or void transactions, issue full or partial refunds, communicate with external banking networks, and keep a provably correct record of every cent. It must do this under PCI-DSS compliance, near-total availability, active fraud pressure, and complete audit traceability.

This is not a CRUD service that happens to move money. A social feed can retry a write; a gateway cannot double-charge a customer, lose a capture, or forget a refund. The design therefore separates four concerns that weaker answers merge: the merchant API surface, the payment orchestration workflow, the external banking network edge, and the financial record (the ledger). Money correctness lives in the ledger and the state machine; latency lives in the API; unpredictability lives at the bank edge.

The four-party model you must name

Every serious payment interview assumes you can draw the four-party model. The cardholder pays at a merchant. The merchant sends the transaction to an acquirer (the merchant's bank or a processor acting for it). The acquirer routes an authorization request through the card network (Visa, Mastercard, and similar) to the issuer (the cardholder's bank), which approves or declines. The gateway is the merchant-side orchestrator of this exchange: it accepts the credential, strips it out of merchant scope via tokenization, formats and routes the authorization, normalizes the response, drives capture and settlement, and reports the outcome.

Some platforms, Adyen being the canonical example, collapse gateway, processor, and acquirer into one integrated stack with their own acquiring licenses. Others, the classic Stripe or Braintree model, sit as an aggregation layer over many acquirers and networks. The interview answer should state which model it assumes, because owning the acquiring rail changes failover, settlement, and reconciliation design.

Why the problem is distinctive

Three properties make this different from generic e-commerce backend design. First, the dominant external dependency is a set of legacy banking networks whose failure signature is not an error but silence: a timed-out authorization is an unknown state, not a decline, and acting as if it were a decline double-charges or loses money. Second, the data contains regulated cardholder data, so architecture is a compliance instrument: the point is to shrink PCI scope, not merely to be fast. Third, the source of truth for money is a double-entry ledger, and every side effect (charge, refund, fee, payout) must be expressible as balanced postings.

Public operating baseline versus design assumptions

Public evidence establishes the scale of the category. Stripe announced it processed $1.4 trillion in payments in 2024, up from roughly $1 trillion in 2023. Adyen reported about €547 billion in total processed volume for 2023 on a single integrated platform. PayPal reported $1.53 trillion in total payment volume for 2023, and its leadership has publicly cited peak capacity around one hundred thousand transactions per second. Visa has stated VisaNet can handle more than 65,000 transactions per second and reported over 260 billion processed transactions in fiscal 2023. These are cited company figures used as context, not requirements of our design.

For capacity planning this answer assumes a mature gateway with 50 million payment attempts per day, an 8x daily-to-peak ratio driven by flash sales and holiday events, 150 million outbound webhook deliveries per day, and 40 active acquirer and wallet integrations. Unless tied to a named company figure, every number in this answer is an explicit design assumption, target, or budget.

The four architectural planes

1. Merchant API plane: public REST APIs, hosted payment fields, developer experience, idempotency, API keys, and webhooks out.
2. Orchestration plane: payment intent state machines, retry and routing logic, risk decisioning hooks, and saga coordination.
3. Banking network plane: acquirer adapters, ISO 8583 or REST rails, asynchronous network results, reversals, and settlement files.
4. Record plane: double-entry ledger, immutable audit trail, token vault, reconciliation, and reporting.

A strong answer keeps these planes separate. The ledger never waits on a bank round trip; the API never blocks indefinitely on the network plane; and the token vault is a physically isolated subsystem whose only job is to make cardholder data disappear from everywhere else.