Designing Robust Payment Account Systems: Key Concepts and Modeling Strategies

Payment Account and Login Credential

Account system design must differentiate two concepts: a payment account, which is the credential representing a user's ownership of funds in the payment system, and a login credential, which is used for system authentication and personal information. One user may have multiple login credentials, each of which can be linked to multiple payment accounts (e.g., wallet, stored-value card). Generally, payment accounts are not shared across login credentials.

Design Requirements for Accounts

When designing accounts in a payment system, consider the following aspects:

Transaction needs : check if the account is locked, if the balance is sufficient, and if it is valid.

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

Reconciliation needs : reconcile with payment channels, merchants, and individuals to verify transaction correctness.

Risk control needs : support anti‑money‑laundering and anti‑fraud measures (covered in separate articles).

Credit needs : provide core data for credit assessment of users, assets, and merchants (covered in another article).

These five needs are prioritized in the order of transaction, accounting, reconciliation, risk control, and credit, and are incorporated progressively as the payment system evolves.

Transaction and Accounts

Transactions start with account involvement. A transaction moves funds from one account to another. The initiator is the transaction subject (individual or organization), and the recipient is the counter‑party. In e‑commerce, transactions may also involve a payment channel.

Because e‑commerce platforms lack settlement qualifications, the actual fund movement is performed by the payment channel’s interface, which also charges fees. Thus, a single transaction typically involves three accounts: the subject’s account, the counter‑party’s account, and the channel’s account.

Accounting and Accounts

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

Internal vs. External Accounts

When users pay with bank cards, the e‑commerce system interacts with banks, creating external accounts that the system can only record transaction details for, without knowing the actual balance. Conversely, internal accounts such as wallets or stored‑value cards are managed by the e‑commerce platform and provide full balance and transaction visibility.

Questions such as when a coupon needs an account or how to handle rechargeable stored‑value cards are left for future articles.

Receiving and Acquiring Accounts

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

Account Modeling

Account modeling must align with business needs and evolve with company scale. It comprises three core models: entity model, account model, and transaction model. The transaction model yields detailed account flow records for reconciliation.

Entity Model

The entity model includes attributes specific to payment, such as:

User ID (mapped to login credential ID)

Permission to execute payments

Payment password

Phone number for password reset

Email for password reset

User 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. Each account should have the following basic attributes:

Account number/ID (system‑generated, with a rule for type prefix)

Account name (displayed to the user)

Currency type (separate sub‑accounts for each currency)

Accounting subject code (typically a primary subject code)

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

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

Third‑party information (e.g., bank or payment provider IDs, account numbers, app IDs, expiration dates) must be stored securely, with sensitive fields encrypted and, where appropriate, placed in separate tables. Integrity checks should be added to detect tampering.

Transaction Model

Transaction records (or transaction logs) capture the core flow of each transaction. Important fields include:

Unique transaction serial number

Creation and last‑modification timestamps

Accounting subject code

Associated order number and details (name, description, address)

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

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

Counter‑party information (similar fields)

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

Conclusion

The account and transaction models described are complex; whether to record all this information depends on business needs. Future articles will explore how to apply these models in actual transaction processing.