Design and Architecture of a Checkout System: Scenarios, Features, Third‑Party Integration, and Large‑Scale Data Solutions

1 Background Introduction

1.1 Background

The term "checkout" is intuitive, mirroring the physical checkout counter where a cashier scans items, calculates the price based on membership, promotions, and then the user pays via electronic or cash methods to complete the purchase.

Online payment has become ubiquitous, but the underlying processes, logic, security guarantees, and operational stability are complex; this article explores those aspects.

1.2 Concept Definitions

收单 : From the platform perspective, the entire process of collecting payment from the user.

提现 : The user withdraws their balance to third‑party wallets such as WeChat or Alipay.

打款 : Transfer of money from a ZuanZuan account to a user’s account, generally encompassing withdrawals.

三方 : Refers to third‑party payment providers (e.g., WeChat Pay, Alipay) involved when a user pays.

1.3 Definition of Checkout in This Article

In an e‑commerce site, the checkout page allows users to select a payment method and complete the transaction. The diagram below (click for larger view) shows the simplified steps of a ZuanZuan purchase and the checkout’s position in the flow.

2 Scenario Problems

Before detailing the checkout logic and architecture, several real‑world scenarios are examined.

Problem 1: Who receives the money and how?

In physical stores the cash exchange is straightforward, but in electronic payments disputes can arise when a seller claims not to have received funds.

Problem 2: Has the user actually paid?

Users may claim payment without a successful transaction; how should the system handle this?

Problem 3: What if the transaction amount is tampered with?

Amount manipulation is common; the article cites a news example of a mistaken large payment and asks how e‑commerce can prevent such issues.

Problem 4: How to handle duplicate payments?

When a user pays the same order with multiple payment methods (e.g., Alipay then WeChat), the system must detect and resolve the duplication.

3 Checkout Feature Overview

The following images illustrate the typical checkout UI in the ZuanZuan app, as well as support for mini‑programs and PC pages. The checkout is a critical touchpoint, offering multiple payment options such as WeChat, Alipay, installment plans, and combined payments.

Key visible elements include the amount to be paid and the selectable payment methods. Less visible aspects involve environment‑specific payment options (Android, iOS, mini‑programs, PC), varying merchant accounts, credit‑card strategies per user/item, internal document flows, and exception handling.

4 Third‑Party Product Capabilities

The checkout relies on third‑party payment providers; their capabilities and integration points are briefly introduced (detailed docs reside on the providers’ sites).

1) Different environments require different payment products; integrating a provider’s SDK enables secure APP payments, each product must be separately activated.

2) Payment method availability (balance, debit card, Huabei, credit card, etc.) can be controlled via parameters.

5 Checkout Implementation Logic and Architecture

5.1 Interaction Flow

Several flowcharts illustrate the overall interaction and internal logic.

From the payment center’s perspective, the sequence diagram of the order‑placement process is shown below:

The internal checkout detail flowchart follows:

5.2 Payment Center Technical Architecture

Having introduced the checkout, the article now discusses technical details.

5.3 Checkout Payment Configuration Rule Engine

The checkout initially needed to support diverse environments, business lines, and third‑party products. Embedding all routing logic in code would lead to tangled if‑else statements, so a rule engine Easy Rules is employed.

Define business rules (name, description, priority, match logic, success/failure actions).

Business rules consist of elements such as business information and seller information.

Define scenario rules (business rule, terminal info, version, available payment method set).

Using the rule engine avoids excessive code branching and eases extension. A more complete routing rule diagram is shown below:

The current rule engine lacks low‑code support, which is a future improvement direction.

5.4 Large‑Scale Data Solutions

As data volume grows (payment‑related core tables have reached billions of rows), storing everything in a single table becomes infeasible. Common solutions include sharding (horizontal/vertical) and hot‑cold databases.

Advantages

Disadvantages

Sharding

1) Write load is distributed across databases, improving write performance.

1) Queries without a shard key can be inefficient.

2) Cross‑shard transactions become complex.

Hot‑Cold DB

1) Transaction handling is simple.

2) Hot tables have high read/write performance due to smaller size.

1) Modifying data in the cold store requires compatibility handling.

2) Overall write throughput is limited.

For payment scenarios—rare data modifications, low reuse after three months, and strong transaction requirements—the hot‑cold approach is chosen. The cold store uses TiDB (a distributed MySQL‑compatible database) for scalability; when cold data must be updated, a back‑fill process is applied.

6 Scenario Problem Review

Problem 1: Who receives the money and how?

The system determines the appropriate third‑party account based on payment info and business configuration, then creates a payment order using the account’s certificates and keys.

Problem 2: Has the user paid?

In disputes, the transaction ID can be queried on the third‑party platform.

Problem 3: How to prevent amount tampering?

The payment order’s amount is set by the system during creation, eliminating user‑entered amount entry and thus preventing tampering.

Problem 4: How to handle duplicate payments?

After receiving a success callback, the system re‑queries the third party; if a different successful payment record exists for the same order, a refund is processed.

About the Author

Zhang Yiming, backend R&D engineer at ZuanZuan Payments.