Designing Payment Account Systems for E‑Commerce Platforms

The account system is the foundation of a payment platform, directly influencing its characteristics. This article explores the design of payment account systems for e‑commerce, starting from basic concepts and modeling.

Payment Account vs. Login Account

Two distinct concepts are defined: Payment Account , the credential representing a user's monetary rights within the payment system, and Login Account , the credential for system authentication and personal information. A user may have multiple login accounts, each linked to one or more payment accounts (e.g., wallet, stored‑value card). By default, "account" refers to a payment account.

Design Requirements for Accounts

Account design in a payment system should consider the following needs:

Transaction needs : check lock status, balance sufficiency, validity, etc.

Accounting needs : record all behaviors (spending, recharge, transfer) according to corporate accounting rules.

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

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

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

These requirements are prioritized from transaction to accounting, reconciliation, and risk control as the system evolves.

Transaction and Account

Transactions rely on accounts; funds flow from a source account to a target account. The initiator is the “transaction subject” (person or organization), and the receiver is the “counterparty.” In e‑commerce, a third party—typically a payment channel—also participates, leading to three accounts per transaction: subject account, counterparty account, and channel account.

Accounting and Accounts

Companies must record each transaction in detail, classifying them into accounting subjects (e.g., food, bandwidth, office supplies) that may have multiple hierarchical levels. Both total‑ledger (summary) and detail‑ledger accounts are needed for merchants, buyers, and channels.

Internal vs. External Accounts

External accounts are those held by banks or third‑party payment providers; the system can only record balances and transaction details, not the actual balance. Internal accounts (e.g., wallet, stored‑value card, credit account) are created by the e‑commerce platform and can track full balance and consumption details.

Collection vs. Acquiring Accounts

When integrating with banks or third‑party payment providers, merchants must open a collection account on the channel side to receive funds. The channel supplies daily transaction statements for reconciliation, effectively acting as an acquiring institution.

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

The entity model includes attributes specific to payment, such as user ID, payment permission, payment password, password reset phone/email, and security level.

Account Model

Various account types may be defined, including virtual‑currency accounts, withholding accounts, wallet accounts, third‑party payment accounts, bank card accounts, settlement accounts, and tax‑withholding accounts. Key attributes are:

Account number/ID (with a rule for type encoding)

Account name

Currency type (separate sub‑accounts for each currency)

Accounting subject code

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

Financial attributes cover total balance, available balance, and frozen balance (used during payment reservation).

Third‑party information includes entity ID, external account number (e.g., bank card or open_id), app_id, and expiration date. Sensitive data such as passwords or CVV must be encrypted or stored separately, with integrity checks to prevent tampering.

Transaction Model

Transaction records (or transaction ledgers) capture comprehensive details needed for risk control and credit analysis, such as:

Unique transaction serial number (used for sharding)

Creation and last‑update timestamps

Accounting subject code

Related order number and description

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

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

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 complex; whether to record all listed information depends on business needs. Future articles will discuss how to apply these models in actual transaction processing.