Designing Robust Payment Account Systems for E‑Commerce: Key Concepts and Models

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

Payment Account and Login Account

Account system design must distinguish two concepts: payment account and login account. A payment account is the credential representing a user's ownership of funds in the payment system; a login account is the credential for system access and personal information. One user may have multiple login accounts and each login account may have multiple payment accounts (e.g., wallet, stored‑value card). Generally, payment accounts are not shared across login accounts.

Design Requirements for Accounts

In a payment system, account settings are considered from several aspects:

Transaction requirements : e.g., checking if an account is locked, balance sufficiency, validity.

Accounting requirements : record all account activities such as spending, recharge, transfer according to corporate accounting needs.

Reconciliation requirements : reconcile with payment channels, merchants, individuals to verify transactions and balances.

Risk control requirements : anti‑money‑laundering, anti‑fraud, etc., which rely on account data. (Detailed analysis in separate articles.)

Credit assessment requirements : evaluate credit of users, assets, merchants, also relying on account data. (Detailed analysis in a later article.)

These five requirements are prioritized in the order of transaction, accounting, reconciliation, and risk control. As the payment system evolves, new requirements are gradually incorporated.

Transaction and Account

Account setup usually starts with a transaction. A transaction requires account support; funds flow from one account to another. The initiator is the transaction subject (individual or organization), and the receiver is the counter‑party (also individual or organization). In e‑commerce, transactions may also involve a channel.

Because e‑commerce platforms lack settlement qualifications, funds flow between the subject and counter‑party is typically handled by invoking payment‑channel interfaces, which also charge fees. Thus a single transaction involves three accounts: the subject’s account, the counter‑party’s account, and the payment‑channel account. Detailed analysis will follow in a later article.

Accounting and Account

Companies need detailed records for each transaction. Transactions are classified (e.g., food, bandwidth, office supplies) into accounting subjects, which may have multiple hierarchical levels. Summaries are kept at each level. In e‑commerce, participants (merchants, buyers, channels) each require both a ledger account and a detail account.

Internal and External Accounts

When users pay with bank cards, the e‑commerce payment system must interface with banks, deducting funds from the external account. External accounts (bank or third‑party) can only record transaction details and cumulative consumption; their real balance is unknown. Internally, platforms may create wallet accounts (e.g., “零钱”) that track full balance and transaction details. Other internal accounts include stored‑value cards and credit accounts.

Questions such as when a coupon needs an account or whether a prepaid card requires an account will be answered in subsequent articles.

Receiving and Acquiring Accounts

When integrating with banks or third‑party payment providers, merchants are required to open a receiving account where funds are transferred. The channel provides daily transaction statements for reconciliation, effectively acting as an acquiring institution. The e‑commerce side creates a corresponding acquiring account for recording channel transactions.

Account Modeling

Account modeling must align with business needs and varies with company size and development stage. It includes 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 overlaps with user and merchant models but adds payment‑specific attributes:

User ID (mapped to login account ID)

Permission to execute payments

Payment password

Phone number for setting or resetting payment password

Email for setting or resetting payment password

User security level as defined by business rules

Account Model

Various account types may be defined, such as virtual‑currency accounts, deduction accounts, wallet accounts, third‑party payment accounts, bank card accounts, settlement accounts, and tax‑deduction accounts. Each account requires basic attributes:

Account number (ID) : usually system‑generated with a rule indicating account type.

Account name : user‑defined display name.

Currency type : separate sub‑accounts for each currency if needed.

Accounting subject code : typically the primary accounting subject.

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

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

Bank and third‑party payment information includes third‑party entity ID, external account identifier (e.g., bank card number or open_id), app_id, and account expiration date. Sensitive data such as passwords or CVV must be encrypted and stored securely, possibly in separate tables, with additional verification fields to detect tampering.

Transaction Model

Transaction records, transaction flows, and account ledgers share the core concept of transaction flow. Account flow is the transaction flow from the account perspective. Comprehensive transaction data is essential for risk control and credit analysis. Key fields include:

Unique transaction serial number (used for sharding)

Creation and last modification timestamps

Accounting subject code

Associated order number provided by the merchant

Order name, description, address, etc.

Fee information: settlement currency, original fee, actual fee

Transaction subject details: ID, type, name, account, account type, IP, phone, platform, notification email, location, etc.

Counter‑party details: ID, type, name, account, account type, phone, platform, notification email, etc.

Channel details: channel entity ID, channel account, execution time, channel‑side order number, error codes and messages if any.

Conclusion

The account and transaction models are complex; whether to record all this information and how to use these models in transactions will be explored in future articles.