Design a Payment System: Time-Boxed High-Level Design

Design a payment system that lets a product accept payments from its users: a user checks out, is charged, and the purchase is confirmed only once the payment has succeeded. The interviewer asked for a quick high-level design rather than a deep dive, so the goal is to cover the end-to-end flow, the main components and the few decisions that make a payment system correct, in limited time. Assume the system does not connect to card networks itself. It integrates with an external payment service provider (PSP) that processes the card or wallet payment. ```hint Retries meet money A request to charge times out. Before deciding to retry, ask how the system makes sure the user is not charged twice. ``` ```hint Two records of the truth Your database and the provider can disagree after a crash or a lost notification. Think about how the system notices that and repairs it. ``` ### Constraints and Clarifications - Correctness comes before latency: a user must never be charged twice, and an order must never be marked paid when the money was not collected. - Keep it high level: the components, the main flow, the data you store, and how failures are handled. ### Clarifying Questions - Is this pay-in only (users pay the platform), or must the system also pay out to sellers or creators? - Does the system ever see raw card numbers, or does the provider's hosted page or SDK tokenize them? - Which payment methods and currencies must be supported? - What volume and peak rate should the design handle? - Does the user wait synchronously for the result, or can confirmation arrive asynchronously? ### What a Strong Answer Covers - A clear end-to-end flow from checkout to confirmation, including the provider's asynchronous notification - Idempotency on every step that can be retried - A payment state machine and an append-only ledger, with amounts in integer minor units - Reconciliation against the provider's records - Failure handling for timeouts, duplicate or lost notifications, and crashes between steps - Staying out of card-data scope, and spending the limited time on the correctness core ### Follow-up Questions - How would you add payouts to sellers, and how does the ledger change? - How would you route between two payment providers, and fail over when one degrades? - A payment is stuck in a pending state for an hour. How does the system resolve it, and what does the user see? - How would you support full and partial refunds without breaking reconciliation?