Designing Payment Account Systems for E‑commerce Platforms

Account systems are the foundation of payment platforms, and their design directly influences system characteristics. This article explores how to design a payment account system for e‑commerce, starting from basic concepts and moving to modeling.

Account systems are the basis of payment systems; their design directly impacts system features. This article discusses how to design a payment account system for e‑commerce, beginning with basic concepts and modeling.

Payment Account and Login Account

The account system design must distinguish two concepts: payment accounts and login accounts. A payment account is the credential representing a user's ownership of funds in the payment system, while a login account is the credential for system access and personal information. One user may have multiple login accounts, each linked to multiple payment accounts such as wallet, stored‑value card, etc. Generally, payment accounts are not shared across login accounts.

Account Design Requirements

In a payment system, account settings consider the following aspects:

Transaction requirements : check if the account is locked, balance sufficient, validity, etc.

Accounting requirements : record all behaviors on the account (spending, recharge, transfer) according to company accounting needs.

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

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

Credit requirements : provide core data for credit assessment of users, assets, merchants (covered elsewhere).

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

Transaction and Account

Transactions start with account support. Funds flow from the payer’s account to the payee’s account. The payer is the transaction subject (individual or organization), and the payee is the transaction counterpart. In e‑commerce, transactions may also involve payment channels.

Because e‑commerce platforms lack settlement qualifications, funds typically move through payment channels, which also charge fees. Thus, a single transaction often involves three accounts: the payer’s account, the payee’s account, and the channel’s account.

Accounting and Account

Companies need detailed records for each transaction. Transactions are classified (e.g., food, bandwidth, office supplies) into accounting subjects, which can have multiple hierarchical levels. In e‑commerce, participants include merchants, buyers, and channels, each requiring both summary (general ledger) and detail (sub‑ledger) accounts.

Internal and External Accounts

When users pay with bank cards, the e‑commerce system interacts with banks, creating external accounts that the system can only record details for, not actual balances. Internal accounts such as wallets, stored‑value cards, and credit accounts are created within the system and can track full balances and transaction details.

Collection and Acquiring Accounts

When integrating with banks or third‑party payment providers, merchants must open collection accounts on the channel side. These accounts provide daily transaction statements for reconciliation, effectively acting as acquiring accounts for the e‑commerce platform.

Account Modeling

Account modeling varies with business scale and development stage. It includes three core models: entity model, account model, and transaction model. The transaction model can derive detailed account flows for reconciliation.

Entity Model

The entity model overlaps with user and merchant models but adds payment‑specific attributes such as user ID, payment permission, payment password, password reset phone/email, and security level.

Account Model

Depending on business needs, various accounts can be created: virtual‑currency account, deduction account, wallet account, third‑party payment account, bank card account, settlement account, and tax‑deduction account. Each account requires attributes like account ID, name, currency type, accounting subject code, and control flags (e.g., allow recharge, withdrawal, overdraft, payment, transfer in/out, security, activation, freeze).

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

Third‑party information includes entity ID, third‑party account identifier (e.g., bank card number, open_id), app_id, and expiration date. Sensitive fields must be encrypted and possibly stored in separate tables with integrity checks.

Transaction Model

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

Unique flow number

Creation and modification timestamps

Accounting subject code

Associated order number, name, description, address

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

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

Counterpart information (ID, type, name, account, phone, platform, email)

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

Summary

The account and transaction models are complex, and whether to record all details depends on business needs. Future articles will discuss how to use these models in transactions.