Design and Architecture of a Payment Checkout System

The article introduces the concept of a checkout system, likening it to the physical cash register in a supermarket where items are scanned and the total price is calculated based on membership level, promotions, and payment method.

It then defines key terms from the platform perspective: 收单 (the whole process of collecting payment from the user), 提现 (user withdrawing balance to third‑party wallets), 打款 (paying money to a user, including withdrawals), and 三方 (the third‑party payment providers such as WeChat Pay or Alipay).

The checkout page is described as the UI where users select a payment method and complete the transaction, with examples of the app, mini‑program, and PC versions supporting multiple payment options like WeChat, Alipay, installment plans, and combined payments.

Several real‑world payment scenarios are discussed, including questions about who receives the money, how to verify a payment, preventing transaction amount tampering, and handling duplicate payments.

Functionally, the checkout displays the payable amount and available payment methods, which vary across environments (Android, iOS, mini‑programs, PC) and versions, and involve different merchant accounts, credit‑card strategies, and internal document flows.

The article outlines third‑party product capabilities, noting that different environments require different SDKs and that payment methods (balance, debit card, credit card, installment) can be controlled via parameters.

Implementation details are presented through interaction flow diagrams and a technical architecture diagram of the payment center. A rule engine ( Easy Rules ) is used to route payment requests based on business rules, scene rules, terminal information, version, and available payment methods, avoiding hard‑coded if‑else logic.

To handle the massive data volume (billions of payment‑related rows), the system adopts a cold‑hot database strategy: hot data resides in a high‑performance MySQL‑compatible store, while cold data is stored in a distributed TiDB cluster. This approach balances write performance, transaction simplicity, and scalability.

Finally, the article revisits the earlier scenarios, explaining how the system determines the correct third‑party account, verifies payment status via transaction IDs, prevents amount tampering by fixing the amount at order creation, and resolves duplicate payments through idempotent callbacks and refund processing.