How Do Third‑Party Payment Systems Really Work? A Deep Dive into Payment Architecture

Background

The article analyses the technical architecture of a third‑party payment system, focusing on the evolution of payment models, the core participants, account structures, transaction flows, and functional domain decomposition.

Payment Evolution

First‑party payment : Direct cash transfer between buyer and seller; unsuitable for large‑scale commerce.

Second‑party payment : Bank‑mediated transfers; low‑frequency, high‑value use cases.

Third‑party payment : Licensed platforms (e.g., WeChat Pay, Alipay) that connect to banks via APIs, handling most small‑ and medium‑sized transactions.

Fourth‑party payment : Aggregates multiple third‑party providers and banks to offer a one‑stop solution; currently lacks regulatory approval and carries fund‑security risks.

Core Participants and Account Types

The system serves four roles: users , merchants , banks , and the payment tool itself. Internally it defines three account abstractions:

User Account (U‑account) : Unique ID, balance, and transaction ledger; low concurrency, balance‑sensitive.

Merchant Account (M‑account) : Unique ID, balance, ledger; high concurrency, balance changes frequently but is less sensitive because funds flow continuously.

Bank Account (B‑account) : Represents the actual bank accounts held by the payment institution; limited in number, handles large monetary flows, high concurrency.

Transaction Scenarios

The system supports several fundamental operations:

Recharge : User transfers money from a bank account to the payment tool. The user’s wallet balance and the platform’s reserve (备付金) account increase by the same amount.

Withdrawal : Platform debits the user’s wallet, then moves the same amount from the reserve account to the user’s bank account. The debit is typically frozen first and finalized after the bank transfer succeeds.

Transfer : Internal ledger move from one user to another; total reserve balance remains unchanged.

Payment & Refund : User pays a merchant; merchant’s account receives the funds. A refund moves the money back to the user’s account.

Settlement : After deducting fees, the platform transfers the merchant’s net funds from the merchant account to the merchant’s external bank account.

Key invariant: the sum of all internal wallet balances must always equal the reserve account balance. Any discrepancy indicates potential fund misuse.

Illustrative Flow Diagrams

Images below depict the fund movements for each scenario. They emphasize that recharge/withdrawal affect both the wallet and reserve equally, while transfers only shift balances internally.

Domain Decomposition

The payment ecosystem is split into functional domains that can be composed to satisfy business requirements:

Payment (broad) : Provides basic capabilities such as payment, transfer, and recharge.

Refund : Returns funds from merchant to user or user’s bank.

Withdrawal (Payment) : Moves platform funds to a user’s bank account.

Settlement : Settles merchant accounts after fee deduction and optionally triggers automatic bank withdrawals.

These domains collaborate; for example, settlement depends on the withdrawal capability.

Detailed Account Model

Each account stores:

Unique identifier (ID)

Current balance

Transaction ledger (流水)

Characteristics per account type:

User Account : Low concurrency, few transactions per second, high balance sensitivity.

Merchant Account : High concurrency (many users pay simultaneously), high transaction volume, balance changes rapidly but merchants are less sensitive because funds are continuously flowing.

Bank Account : Limited number of accounts, massive monetary flow (often billions), high concurrency, balance not directly monitored by the payment institution.

Operational Walkthrough

Consider two users, Zhang San and Li Si, each with a bank account, a payment‑tool account, and the platform’s reserve account (备付金). The following steps illustrate typical fund movements:

1. User Recharge

Zhang San recharges ¥20 from his bank to his payment‑tool wallet.

Process:

Bank debits ¥20 from Zhang San’s bank account.

Reserve account (备付金) is credited ¥20.

Payment‑tool wallet balance for Zhang San is increased by ¥20.

2. User Withdrawal

Li Si withdraws ¥10 from his payment‑tool wallet to his bank.

Li Si’s wallet balance is frozen for ¥10.

Reserve account transfers ¥10 to Li Si’s bank account.

After successful bank transfer, the freeze is released and the wallet balance is permanently reduced by ¥10.

3. User‑to‑User Transfer

Zhang San transfers ¥20 to Li Si within the payment tool.

Zhang San’s wallet balance is decreased by ¥20.

Li Si’s wallet balance is increased by ¥20.

Reserve account balance remains unchanged because the operation is internal.

4. Payment & Refund

When Zhang San pays a merchant, the merchant’s account receives the funds. A subsequent refund moves the same amount back to Zhang San’s wallet.

5. Settlement

After a transaction, the platform deducts fees from the merchant’s account and transfers the net amount to the merchant’s external bank account.

Fund Flow Invariants

Across all scenarios, the following holds:

Recharge and withdrawal change both the wallet balance and the reserve account by the same amount.

Transfers only reallocate balances between internal accounts; the reserve balance stays constant.

The reserve account must always equal the sum of all internal wallet balances. A mismatch signals potential misuse of funds.

Domain Interaction Example

The diagram below shows how the five domains cooperate in a typical purchase flow (user → merchant → settlement):

Operations:

Recharge : User adds funds to the wallet.

Payment : User transfers funds to the merchant’s account.

Refund (optional): Merchant returns funds to the user.

Withdrawal : Merchant or user moves funds to a bank account.

Settlement : Platform settles merchant’s net balance after fees.

Conclusion

The article provides a systematic view of a third‑party payment system, covering:

Evolution from first‑ to fourth‑party payment models.

Core roles (user, merchant, bank, payment tool) and their corresponding account abstractions.

Detailed fund flow for recharge, withdrawal, transfer, payment, refund, and settlement.

Functional domain decomposition that enables modular development and clear responsibility boundaries.

Code example

相关阅读：