Designing Robust Payment Account Systems for E‑Commerce Platforms

Account systems are the foundation of payment platforms, directly influencing system characteristics; this article explores how to design a payment account system for e‑commerce.

Payment Account vs. Login Account

Two distinct concepts must be separated:

Payment Account : the credential representing a user's ownership of funds within the payment system.

Login Account : the credential used for system authentication and personal information. A user may have multiple login accounts, each of which can own multiple payment accounts (e.g., wallet, stored‑value card). Generally, payment accounts are not shared across login accounts.

Design Requirements for Accounts

When designing a payment system, consider the following needs:

Transaction needs : check if an account is locked, has sufficient balance, is valid, etc.

Accounting needs : record all account activities (spending, recharge, transfer) to satisfy corporate accounting.

Reconciliation needs : match transactions and balances with payment channels, merchants, and individuals.

Risk control needs : anti‑money‑laundering, fraud detection, etc. (covered in separate articles).

Credit assessment needs : provide core data for evaluating users, assets, merchants (covered elsewhere).

The priority follows the order: transaction, accounting, reconciliation, risk control, credit.

Transaction and Account

Transactions rely on accounts; funds flow from one account to another. The initiator is the “transaction subject” (individual or organization), and the receiver is the “counterparty.” In e‑commerce, a third party— the payment channel—also participates, adding a third account to the flow.

Accounting and Account

Companies must record each transaction in detail. Transactions are classified (e.g., food, bandwidth, office supplies) into accounting subjects, which may have multiple hierarchical levels. For e‑commerce, participants (merchants, buyers, channels) each need both a ledger (summary) account and detailed sub‑accounts.

Internal vs. External Accounts

When a user pays with a bank card, the e‑commerce system interacts with the bank’s external account, recording only transaction details and cumulative spend because the real balance is unknown. Conversely, internal accounts such as “wallet” or “stored‑value card” are managed by the e‑commerce platform and can track full balances and transaction histories.

Collection vs. Acquiring Accounts

Integrating with banks or third‑party payment providers often requires opening a collection account on the channel side. The e‑commerce platform then creates a corresponding acquiring account to record the channel’s transaction flow for reconciliation.

Account Modeling

Account modeling must align with business scale and development stage. It consists of three core models: entity model, account model, and transaction model. The transaction model can generate detailed account ledgers for reconciliation.

Entity Model

Attributes specific to payment include:

User ID (mapped to login account ID)

Permission to execute payments

Payment password

Phone number for password reset

Email for password reset

User security level

Account Model

Typical account types in e‑commerce:

Virtual currency account

Deduction (subscription) account

Wallet (internal) account

Third‑party payment account

Bank card account

Settlement account (for settling with payment providers or banks)

Tax deduction account

Key attributes for each account:

Account number/ID (with a predefined rule for type identification)

Account name (display name)

Currency type (separate sub‑accounts per currency)

Accounting subject code

Control flags include permissions for recharge, withdrawal, overdraft, payment, inbound/outbound transfers, security guarantees, activation, and freezing.

Financial fields include total balance (available + frozen), available balance, and frozen amount (used during payment reservation).

Third‑party information (e.g., bank or payment provider) must store IDs, account numbers, app IDs, and expiration dates, while sensitive data such as passwords or CVV must be encrypted or stored separately.

Transaction Model

Transaction records (or “流水”) capture comprehensive data for risk control and credit analysis. Essential fields:

Transaction serial number (used for sharding)

Creation and last‑modified timestamps

Accounting subject code

Related order number and details

Fee information (settlement currency, original fee, actual fee)

Subject information (ID, type, name, account, IP, phone, platform, email, location)

Counterparty information (similar fields)

Channel information (entity ID, channel account, execution time, channel order number, error codes/messages)

Conclusion

The account and transaction models are intricate; whether to record all listed details depends on business needs. Future articles will demonstrate how to apply these models in actual transaction processing.