Account Accounting Theory, Design, Performance Issues, and Core Architecture in Third‑Party Payment Platforms

1. Account Accounting Theory

The fundamental accounting equation is Assets = Liabilities + Owner's Equity . In the context of a payment platform, assets represent the funds held by the platform, liabilities represent the funds owed to users or merchants, and equity represents the platform's own stake.

Double‑entry bookkeeping (also called debit‑credit accounting) requires that every transaction be recorded twice – once as a debit and once as a credit – to keep the equation balanced. For programmers, the key point is that a single monetary amount must be written to two related accounts with opposite directions.

“借贷”的理解 两个字意思都有歧义，不要尝试从字面意义去理解，在会计中借贷只是两个记账符号，表示两个相反的方向，不绝对代表数量的增减，所有的账户都是左借右贷，资产类账户增加是借，减少是贷，负债类账户刚好相反，增加是贷，减少是借。

2. Account Design

Third‑party payment platforms maintain both asset‑type accounts and liability‑type accounts:

Asset accounts: e.g., the platform’s reserve account at the central bank where user funds are initially deposited.

Liability accounts: internal accounts that track which merchant each user’s funds belong to; these are liabilities because the money ultimately belongs to others.

Internal accounts are classified as:

Personal (C) accounts – cash accounts owned by individual users.

Merchant accounts – each merchant has a B (intermediate) account for pending settlements and a C (cash) account for withdrawn funds.

Bank accounts – aggregate accounts for each bank used for reconciliation, storing only transaction logs.

The core components of an account are balance, transaction vouchers, and transaction logs.

Balance includes account ID, currency, available amount, frozen amount, and status.

Transaction Log records each balance change: log ID, voucher ID, amount, debit/credit direction, and counter‑party account ID.

Voucher stores transaction details such as participants, amount, type, status, and channel.

3. Account Performance Issues

Two main sources of performance bottlenecks:

Double‑entry bookkeeping forces updates on two accounts, often on different DB nodes, requiring distributed transactions that degrade performance.

Hotspot accounts (e.g., high‑frequency merchants) cause frequent row‑level locks, limiting throughput (MySQL ~500 updates/s per row).

Mitigation strategies:

Pre‑debit then credit (split a distributed transaction into a fast local “debit” transaction and an asynchronous “credit” transaction).

Simplify balance updates.

Merge postings (batch multiple updates into a single balance change).

Use multiple accounts to spread load.

3.1 Pre‑debit then Credit

Separate the double‑entry transaction into two local transactions: a real‑time “debit” transaction followed by an asynchronous “credit” transaction.

3.2 Balance Update Simplification

In certain scenarios (e.g., C2B2C), the intermediate B account may skip balance recording and rely on other mechanisms for consistency.

3.3 Merge Posting

Accumulate balance changes in a queue and apply them in bulk, reducing the number of write operations.

3.4 Multiple Accounts

Introduce several sub‑accounts to distribute load. Two designs exist:

Functional separation: some sub‑accounts handle only inbound, others only outbound, or both.

Full‑function sub‑accounts: each sub‑account can process both inbound and outbound transactions, with load‑balancing logic for selection.

Key design considerations include mapping users to multiple accounts, deployment topology (same DB, same IDC, cross‑IDC), fund reallocation strategies, and using CQRS for aggregated balance queries.

4. Core Architecture and Processing Logic

The platform’s transaction processing has evolved through three stages:

Local transactions : early stage with low traffic, all operations on a single DB.

Distributed transactions : two‑phase commit across multiple DBs as traffic grew.

Flexible (BASE) transactions : split distributed transactions into multiple local ones with eventual consistency, driven by the “pre‑debit then credit” pattern.

Typical C2B payment flow (simplified):

begin
    update buyer balance (decrease)
    insert buyer transaction log
    insert payment voucher
    update seller balance (increase)
    insert seller transaction log
commit

In flexible transactions, the buyer side (debit + voucher) forms the first local transaction, while the seller side (credit) is performed asynchronously by an “async posting service”.

Detailed steps:

Remote log is written via a remote‑log proxy to a remote log service for durability and blacklist management.

Buyer local transaction: resource manager updates buyer balance, logs the transaction, and creates the voucher; then an async message is sent to the async posting service.

Seller local transaction: the async posting service receives the message and updates the seller balance and logs the transaction.

The current system mainly uses flexible transactions, with a minority still relying on distributed transactions where necessary.

5. Summary

This article introduced the accounting theory behind payment platforms, the internal account structure, performance challenges, core architectural evolution, and practical solutions such as pre‑debit‑then‑credit, balance‑update simplification, merged posting, and multi‑account designs.