Fundamentals 18 min read

Account Bookkeeping Theory, Design, and Performance in Payment Platforms

This article explains the accounting equation, double‑entry bookkeeping, and the core account architecture of third‑party payment platforms, covering internal account types, balance, transaction logs and vouchers, performance challenges such as distributed transactions and hotspot accounts, and proposes solutions like pre‑debit/post‑credit, balance simplification, merged posting, and multi‑account designs.

Architect
Architect
Architect
Account Bookkeeping Theory, Design, and Performance in Payment Platforms

1. Accounting Theory

The accounting equation states that Assets = Liabilities + Owner's Equity, illustrating how a company's resources (assets) are funded by debts (liabilities) and owners' contributions (equity). An example using Tencent's headquarters shows assets on the left and liabilities and equity on the right.

2. Double‑Entry Bookkeeping

Double‑entry bookkeeping requires every transaction to be recorded twice, ensuring the accounting equation remains balanced. A debit entry must be matched by a corresponding credit entry, which helps prevent errors and simplifies verification.

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

3. Account Design

Third‑party payment platforms maintain both asset and liability accounts to guarantee accurate and traceable fund flows.

Asset accounts : e.g., the reserve account held by the payment platform at the central bank.

Liability accounts : e.g., merchant accounts that represent funds owed to merchants.

Internal account types include:

Personal account (C account) – a cash account owned by an individual.

Merchant account – consists of a B (intermediate) account for pending settlement and a C (cash) account for settled funds.

Bank account – a total‑ledger account for interactions with banks, typically recording only transaction flows.

Key fields stored per account are ID, currency, balance, frozen amount, and status.

4. Account Performance Issues

Two major performance bottlenecks are identified:

Double‑entry bookkeeping often requires distributed transactions across different databases or data centers, which degrade performance.

Hotspot accounts (e.g., high‑frequency accounts like JD or Pinduoduo) cause frequent row‑level locking, overwhelming the database.

Proposed mitigation strategies:

Pre‑debit then post‑credit (split transaction).

Simplify balance updates.

Merge posting (batch updates).

Multi‑account architecture.

5. Pre‑debit then Post‑credit

The transaction is divided into a real‑time debit phase and an asynchronous credit phase, reducing the need for a single distributed transaction.

Examples:

Quick payment : User bank → platform reserve (asset) → merchant B account (liability).

Balance payment : User internal C account → merchant B account.

Illustrative diagrams:

6. Balance Update Simplification

In certain scenarios (e.g., C2B2C transactions), the balance of an intermediate B account may be omitted and compensated by other mechanisms, trading strict bookkeeping for performance.

7. Merge Posting

Balance updates are held in a queue (DB or KV), aggregated, and applied in a single batch, dramatically improving write throughput.

8. Multi‑Account Design

Multiple sub‑accounts spread load across databases or data centers. Two variants exist:

Functional‑separation : dedicated sub‑accounts for inbound, outbound, or both.

Functional‑completeness : each sub‑account can handle both inbound and outbound operations.

9. Processing Logic

The transaction flow for a C2B payment includes:

Remote logging via a log proxy to a remote log service.

Buyer local transaction: decrement buyer balance, insert buyer ledger, create payment voucher, then send an asynchronous message.

Seller local transaction: upon receiving the async message, increment seller balance and insert seller ledger.

begin
    update buyer balance, decrease
    insert buyer ledger
    insert payment voucher
    update seller balance, increase
    insert seller ledger
commit

Flexible (BASE) transactions split the overall operation into two local transactions linked by asynchronous messaging, achieving eventual consistency while avoiding heavyweight distributed commits.

10. Summary

The article introduced accounting fundamentals, internal account composition, performance considerations, and the core architecture and processing logic of a payment platform’s account system, providing practical design guidelines for reliable and high‑throughput financial services.

distributed transactionaccountingmulti-accountbookkeepingpayment platform
Architect
Written by

Architect

Professional architect sharing high‑quality architecture insights. Topics include high‑availability, high‑performance, high‑stability architectures, big data, machine learning, Java, system and distributed architecture, AI, and practical large‑scale architecture case studies. Open to ideas‑driven architects who enjoy sharing and learning.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.