End-to-End Payments Platform: Checkout to Payout, Ledger Integrity and Fraud Controls

Design a payment system. Choose whom it serves and which payments it must handle, then walk through how a payment moves from start to finish, how the system stays correct and secure, and how you would tell whether it is working. ```hint Follow one payment Trace a single purchase from the moment the payer confirms to the moment the payee can use the money. Most of the hard decisions, such as retries, refunds and settlement, show up somewhere along that path. ``` ### Clarifying Questions - Who pays whom: shoppers paying online merchants, a marketplace collecting from buyers and paying sellers, people sending money to each other, or a business billing its own customers for subscriptions and usage? - Should money move through an existing payment processor and the card and bank networks, or does the scope include becoming a licensed processor ourselves? - Which payment methods and countries must the first version support? - Are refunds, chargebacks and payouts to sellers in scope, or only collecting the payment? ### What a Strong Answer Covers - A chosen scope: participants, payment methods, markets, and an explicit out-of-scope list - The full payment lifecycle (authorize, capture, settle, refund, dispute, pay out) with the main components and what each owns - Correctness under failure: no double charges, safe retries, and records that reconcile with the processor and the bank - Fraud, seller risk and compliance obligations, and how they shape the design - Success metrics for payers, payees and the business, with guardrails such as fraud losses and chargeback rate ### Follow-up Questions - A buyer's payment request times out and they tap Pay again. Walk through how the system makes sure they are charged only once. - How would the design change to launch in a country where most people pay by instant bank transfer rather than by card? - Overnight, the share of approved payments drops by several points. How would you find the cause?