Design a Visa-Style Card Payment Processing System

Design a Visa-style card payment system. The report records only the prompt. It can be scoped two ways, and choosing and defending a scope is part of the exercise: - **The card network:** the system between merchants' banks and cardholders' banks that moves card transactions between them. - **A merchant-side payment service** that accepts card payments. Design for the network unless the interviewer steers you otherwise, and state how your design would differ for the other scope. ```hint Two clocks A card transaction is approved in real time, but the money moves later. Consider which parts of your design must be fast and always available, and which can run in batches and be exact. ``` ```hint Retries are normal Terminals, merchants' banks and card issuers all retry and time out. Decide how every hop recognizes a message it has already seen. ``` ### Clarifying Questions - Which scope is intended: the card network itself, or a merchant or processor integrating with card networks? - Which transaction types must be supported: purchases only, or also refunds, reversals, pre-authorizations with later capture, and chargebacks? - What peak transaction rate, latency budget for an authorization, and availability target should the design meet? - Must the system approve transactions on an issuer's behalf when that issuer is unreachable? - Which regulatory constraints matter, such as keeping card numbers out of most systems or keeping data within certain regions? ### What a Strong Answer Covers - The parties involved, and the message flows for authorization and, separately, for clearing and settlement - A real-time authorization path built for low latency and very high availability, including routing to the correct issuer - Idempotency and duplicate detection across retries, timeouts and reversals - An exact, auditable record of money movement (a ledger), plus daily settlement and reconciliation - Inline fraud checks that fit the latency budget - Multi-region deployment, failure isolation per issuer or partner, and handling of sensitive card data ### Follow-up Questions - An issuer approves a transaction just after the network has timed out and declined it to the merchant. How do you make the two sides agree? - How would you design settlement so that the net positions between banks sum to zero every cycle? - How would you add a new real-time fraud model without adding latency to every authorization? - How does your design change if you are building a merchant-side payment service instead of the network?