Chapter 11: Payment System Architecture

Payment System Architecture details the architectural design of a robust payment system suitable for a global e-commerce platform like Amazon, focusing on the core functional requirements of the pay-in flow, which moves funds from customers to the site's bank account, and the pay-out flow, which handles transferring money from the platform to the sellers using third-party services like Tipalti. Given the anticipated volume of one million transactions per day, which equates to ten transactions per second, the primary design challenge is guaranteeing correctness and reliability rather than maximizing simple throughput. The high-level architecture includes the Payment Service for orchestration, the Payment Executor for processing transactions, and external Payment Service Providers (PSPs) which interface with Card Schemes like Visa and MasterCard. Crucial supporting internal services are the Wallet, which maintains merchant account balances, and the Ledger, which maintains an immutable financial record using the fundamental double-entry accounting principle, ensuring every transaction is recorded with an equal debit and credit to maintain financial consistency. Due to severe security and compliance obligations, particularly the Payment Card Industry Data Security Standard (PCI DSS), the system avoids storing sensitive data directly by relying on PSP-hosted payment pages or software development kits (SDKs) to collect credit card information. Communication between internal services is preferably asynchronous, often using message queues or systems like Kafka, which enhances scalability and failure isolation, especially when the same payment event needs to trigger multiple side effects across different services, such as analytics or billing. The system must be designed for reliability and fault tolerance, utilizing tracking payment states, retry queues for transient errors, and dead letter queues for messages that fail repeatedly. Central to preventing customer double-charging is the guarantee of exactly-once delivery, achieved by combining the at-least-once assurance of retry mechanisms, which should use strategies like exponential backoff, with the at-most-once assurance provided by idempotency. Idempotency keys, such as the payment order ID or nonce, are utilized in requests to external PSPs and internal databases to ensure repeated identical requests yield the same result without reprocessing. The ultimate defense against inconsistency, particularly between internal records and external PSPs, is reconciliation, a periodic process that compares internal ledger states with settlement files received from banks or PSPs to detect and manually or automatically resolve financial discrepancies. For storage, proven relational databases that support ACID transactions are favored. Security techniques also include HTTPS, tokenization to mask card numbers, and measures like rate limiting to mitigate denial-of-service attacks.