# Design a Reliable Payment Processing System Design a payment-processing service for merchants. A client creates a payment, the service submits it to an external payment processor, asynchronous updates may arrive later, and the merchant must be able to retrieve the authoritative status. Focus on preventing duplicate charges and preserving an auditable money trail under retries and partial failures. ### Constraints & Assumptions - Clients, services, queues, and the external processor can time out or retry. - A timeout does not prove that the processor rejected the request. - Payment state changes must be durable and auditable. - Monetary values use an exact minor-unit representation plus currency. - The initial design may support one processor, but should expose a clean integration boundary. ### Clarifying Questions to Ask - Which operations are required beyond authorization and capture, such as voids or refunds? - Is capture immediate or separate from authorization? - What consistency and status freshness do merchants require? - Which party supplies the idempotency key, and how long is it retained? ### Part 1: API, State, and Data Model Define the create/read interfaces, payment state machine, idempotency behavior, and durable records. #### What This Part Should Cover - Stable payment and attempt IDs, exact amounts, and immutable request identity. - Valid state transitions with append-only events or equivalent audit evidence. - Idempotent retries that return the original logical result. ### Part 2: External Processing and Reconciliation Explain how the service handles submission, timeouts, callbacks, duplicate messages, and disagreement with the processor. #### What This Part Should Cover - Durable intent before side effects and a reliable dispatch pattern. - Correlation IDs, signed callback validation, deduplication, and monotonic transitions. - An explicit unknown/pending state plus periodic reconciliation. ### Part 3: Reliability and Operations Describe scaling, tests, observability, and controls for sensitive operations. #### What This Part Should Cover - Partitioning without losing per-payment serialization. - Retry limits, dead-letter review, backpressure, and processor circuit breaking. - Fault-injection and invariant tests around every persistence/network boundary. - Metrics and audit controls that support incident investigation. ### What a Strong Answer Covers - Idempotency at both the client boundary and external-processor boundary. - A precise state machine that never equates timeout with failure. - Durable events, reconciliation, and safe duplicate/out-of-order handling. - Exact money representation, authorization boundaries, and operational visibility. ### Follow-up Questions - How would you migrate an in-flight merchant from one processor to another? - How would you model a partial refund without corrupting the original payment history? - Which invariant would you continuously verify to detect duplicate capture?