Designing Payment Account Systems for E‑Commerce Platforms

Payment account system is the foundation of a payment system; its design directly affects system characteristics. This article discusses designing payment account systems for e‑commerce, starting from basic concepts and modeling.

Payment Account and Login Account

Distinguishes payment accounts (fund ownership certificates) from login accounts (system login credentials). A user may have multiple login accounts and each login account may have 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 several aspects:

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

Accounting requirements : record all behaviors (spending, recharge, transfer) per accounting needs.

Reconciliation requirements : match transactions and balances with channels, merchants, 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 later).

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

Transaction and Account

Account setup starts with transactions; a transaction moves funds from a source account to a target account. The initiator is the transaction subject (person or organization); the receiver is the counter‑party. In e‑commerce, a third‑party payment channel is also involved.

Because e‑commerce platforms lack settlement qualifications, funds flow through payment channels, which charge fees. Thus a single transaction typically involves three accounts: subject account, counter‑party account, and channel account.

Accounting and Account

Companies need detailed bookkeeping for each transaction, categorizing expenses (e.g., food, bandwidth) into accounting subjects, with hierarchical levels (primary, secondary, etc.). In e‑commerce, participants (merchant, buyer, channel) each have a general ledger account and detailed sub‑accounts.

Internal and External Accounts

External accounts refer to bank or third‑party payment accounts; the system can only record transaction details and cumulative consumption, not the real balance. Internal accounts (e.g., wallet) are created by the e‑commerce system and can track full balance and consumption details.

Questions such as when a coupon needs an account are left for future articles.

Collection and Settlement Accounts

When integrating with banks or third‑party payments, a collection account is required on the channel side to receive transaction flows, which can be used for daily reconciliation.

Account Modeling

Account modeling includes three core models: entity model, account model, and transaction model. The transaction model can derive detailed account flow records for reconciliation.

Entity Model

Attributes related to payment entities include user ID, payment permission, payment password, password reset phone/email, and security level.

Account Model

Various account types may be defined, such as virtual currency account, deduction account, wallet account, third‑party payment account, bank card account, settlement account, and tax‑deduction account. Each account has basic attributes (account ID, name, currency, accounting code) and control attributes (allow recharge, withdrawal, overdraft, payment, inbound/outbound transfer, security, activation, freeze) as well as fund attributes (total balance, available balance, frozen balance).

Third‑Party Information

Stores third‑party entity ID, account identifier (bank card number or open_id), app_id, and expiration date. Sensitive data like passwords or CVV must be encrypted or stored separately, with integrity checks.

Transaction Model

Transaction records (flow number, timestamps, accounting code, order ID, description, fee details, subject information, counter‑party information, channel information, error codes) form the core data for risk control and credit analysis.

Conclusion

The account and transaction models are complex; future articles will explore how to apply these models in actual transactions.