A Complete Look at China’s End‑to‑End Internet Payment Architecture

Using a JD.com purchase of “Three Squirrels” snacks as a concrete example, the end‑to‑end payment flow in China is illustrated.

Payment Architecture Overview

A typical internet payment architecture consists of:

Cashier (checkout) – user‑facing page for selecting a payment method.

Order system – records business orders.

Transaction system – translates business actions into payment orders.

Payment system – processes payment instructions.

Payment‑channel subsystem – connects to banking/payment‑channel networks.

Downstream clearing, accounting and settlement components.

After a payment succeeds, transaction data is sent to a clearing centre, then to an accounting system for bookkeeping, followed by notifications to the core accounting module and finally to the fund platform for merchant settlement.

Business Layer vs. Payment Layer

The business layer provides the user‑facing interface and handles transaction requests from business systems. The payment layer interacts with payment channels to complete fund transfers, records inter‑account fund flows, and performs account‑level splitting and merging.

Cashier

The cashier page supports two scenarios:

Payment – a user purchases an item, confirms the order and is redirected to a payment provider (e.g., Alipay, WeChat Pay, UnionPay) to complete the transaction.

Recharge – a user adds funds to an internal wallet via Alipay, WeChat or another merchant‑owned wallet.

Transaction Core

The external transaction system converts business‑level actions into payment orders that the payment system can process. An escrow example shows the flow:

After the user pays, the transaction status becomes “payment successful”.

When the user confirms receipt, the transaction status changes to “completed”.

This demonstrates how basic payment capabilities are wrapped into a product that supports guaranteed transactions.

Member System

The member system manages identities of participants inside the payment platform. It stores a unified member ID, basic profile, and relationships (member‑account, member‑operator, member‑bank‑card). Members are classified as personal or enterprise; enterprise members typically have merchant permissions and configurable parameters such as settlement cycle and channel permissions.

Payment Core

The payment core standardises payment instructions and provides unified services to front‑end products. Its responsibilities include:

Payment Service – wraps backend payment APIs and enables composite payments across multiple channels.

Payment Service Flow – defines atomic processes such as recharge, withdrawal, internal transfer, and refund, and orchestrates them.

Payment Instruction – generated after an order is placed, containing all information required for downstream processing.

Payment Agreement – specifies product code and payment code, governing the processing flow and channel selection.

Accounting Core

The accounting core designs account types, manages accounts, records fund movements, and produces accounting data that reflects inter‑account transactions. It reconciles its ledger with settlement data from payment channels and handles error transactions.

Settlement Core

The settlement core maintains clearing and settlement rules and executes fund distribution according to those rules.

Conclusion

Building a third‑party payment platform in China typically requires dozens of subsystems; the payment process is far from simple.

Code example

--完--
读到这里说明你
喜欢
本公众号的文章，欢迎
置顶（标星）
本公众号 架构师指南，这样就可以第一时间获取推送了~