Account system is the basis of payment system, its design directly affects the characteristics of the whole system. This paper discusses how to design the account system for electronic commerce system. Let’s start with some basic concepts to understand how to model.

Payment account and login account

Account system design should first distinguish between two concepts, payment account and login account. These are concepts from two different business areas. Payment account refers to the certificate of owner’s equity of the user’s funds used for transactions in the payment system. Login account refers to the user’s login credentials and personal information in the system. One user can have multiple login accounts, and one login account can have multiple payment accounts, such as change accounts, stored value card accounts, etc. Generally speaking, payment accounts are not shared between multiple login accounts. Unless otherwise specified, all accounts below refer to payment accounts by default.

Account design requirements

In the payment system, account Settings are mainly considered from the following aspects:

  • Requirements for transactions, such as checking whether the account is locked, whether the balance is sufficient, whether it is valid, etc.

  • Record all actions on the account according to the company’s accounting requirements, including expenditure, recharge, transfer, etc.

  • Reconciliation needs, including reconciliation needs with payment channels, merchants and individuals, and checking whether transactions and account balances are correct.

  • Risk control requirements, such as anti-money laundering, anti-fraud, etc., rely on account systems to provide core data. This article will not analyze this content for the time being, and will analyze it in detail in the two articles payment Risk Control and Payment Anti-money Laundering

  • Demand for credit: When conducting credit evaluation on users, assets, merchants and other subjects, it also needs to rely on the core data provided by the account system. This article will not analyze this content for the time being, and will analyze it in the article “Credit and Payment”.

These five requirements, according to their design priorities, also from the payment, bookkeeping, reconciliation, risk control. Payment systems gradually incorporate additional requirements into their design, depending on their stage of development.

Transactions and Accounts

Account setup usually starts with the transaction. The realization of the transaction must be supported by the account, which is the basic element of the transaction. From the point of view of a payment system, the flow of money involved in a transaction is the flow of money from one account to another. The party initiating the transaction is called the counterparty, which can be either an individual or an institution. Funds flow out of an account owned by the subject. The party receiving the transaction is called the counterparty, which can also be an individual or an institution. Different from third-party payment or financial institution transactions, transactions in e-commerce systems also involve channels. As the e-commerce system itself does not have the qualification of clear settlement, the flow of all funds from the transaction subject to the account of the counterparty, in most cases, does not go through the e-commerce system, but by the e-commerce system to call the interface provided by the payment channel, which completes the real payment process. Of course, the channel is not living Lei Feng, in this process, the channel to collect fees. Therefore, in the e-commerce system, a transaction involves three accounts: the principal account, the counterparty account and the payment channel account. How to complete a transaction among these three accounts will be analyzed in detail in the follow-up article “Transaction and Bookkeeping”.

Bookkeeping and accounts

An accountant in a company needs to keep a detailed record of every transaction. Companies generate a lot of transaction activity every day, and for easy management and statistics, a simple approach is to categorize transactions, such as food, bandwidth, office supplies, and so on. This classification, depending on the size of the company and the complexity of the business, may have a level 1, 2, 3 or more structures, which are called accounts. In bookkeeping, in addition to transaction details, you also need to summarize the transaction volume at each level. Generally speaking, level 1 accounts are called general ledger accounts and detailed records are called subsidiary accounts. In the e-commerce system, because there are more participants involved, accounting is relatively complex, but the basic method is similar. Participants of e-commerce can be divided into merchants, buyers and channels. For these three types of participants, general ledger accounts and subsidiary accounts need to be established respectively.

Internal and external accounts

When a user uses a bank card to pay, the e-commerce payment system needs to connect with the bank and deduct funds from the account represented by the user’s bank card. It is connected to the e-commerce payment system of banks, third-party payment institutions, etc. It needs to be connected to the accounts of users in these institutions to perform the deduction or top-up operation, these accounts are also called external accounts. For external accounts, the payment system can only record the details of the account in the system and the accumulated consumption amount, but cannot know the real balance of the account. Many e-commerce companies are playing with the concept of small change, that is, to let users recharge the small change, when using directly deducted from the small change. This requires a change account. This is an account set up by myself in the e-commerce system, so it is also called an internal account, and you can know all the consumption details and balance of the account. Of course, besides small change account number, also can have store value card account number, credit account number to wait. So the question is, when do you need an account, like a coupon, do you need an account? Do I need to set up an account for one – time consumption and one – time recharge? Here first buried a mine, the subsequent introduction of payment and accounting, give the answer.

Receiving account and receiving account

When an e-commerce company wants to connect with a bank, it is often required to open a collection account. When a user makes a payment through the bank, the money is transferred to the account. The same is true for third-party payments. The receivables account is opened in the bank or the third party payment side, namely the channel side. Generally speaking, the channel can provide the transaction flow of this account for supplier reconciliation on a daily basis. In this way, on the e-commerce side, the channel will become a receipt institution. Therefore, on the e-commerce side, a receiving account corresponding to this receiving account is established for reconciliation, which is used to record the transaction flow through this channel.

Account modeling

Having said that, the goal is to model the account. Account model is closely related to the business of a company. Different scales and development stages of a company require different models. Account modeling itself consists of three core models: entity model, account model and transaction model. From the transaction model, an account flow for each role, known as a detailed model, can be derived to support reconciliation.

Entity model

Where the entity model overlaps with the user and merchant models, the entity attributes are set specifically for payment. Generally speaking, payment related entity model needs to include the following attributes:

  • User ID, usually directly mapped to the ID of the login account; .

  • Whether payment is allowed to be made;

  • Payment password;

  • The mobile phone number used to set or reset the payment password;

  • The mailbox for the user to set or reset the payment password;

  • The security level of a user can be set based on service requirements.

According to business needs, can set up a variety of accounts, such as payment account, prepaid card account, withholding account, change account, settlement account and so on. In terms of category, accounts here generally refer to general ledger accounts. Generally speaking, the types of accounts involved in the e-commerce system are:

  • Virtual currency account: Both users and merchants using Qidian Qidou need to establish virtual currency accounts.

  • Account withholding: used to support regular withholding of subscription types;

  • Small change account: the internal account of e-commerce. Users, merchants and clearing units need to set up small change account

  • Third-party payment account: the account established by the user at the third-party payment agency.

  • Bank card number: the user’s bank card information, each card corresponds to an account.

  • Settlement account: used to support settlement with third-party payment companies and banks. The third-party payment shall establish a settlement account for each merchant number; The bank needs to establish settlement account number for debit card and credit card respectively (is it necessary? Bank card directly connected to use).

  • Withholding account: Used to support tax withholding business.

For these accounts, you need to set the following properties: Basic properties, including:

  • The account ID, or account ID, is automatically generated by the system. In particular, agree on rules for account ids beforehand. For example, the first three digits indicate the account type, and the last few digits indicate the account number. Make sure that the account type can be quickly determined based on the account number and that the account number is unique.

  • Account name, usually set by the user, for display.

  • The type of currency used in the account. Note that although a single bank card can support multiple currencies, there are actually separate sub-accounts internally for each currency. A similar modeling scheme can be used for accounts involving multiple currencies.

  • Accounting course code, it is the code of one level accounting course commonly.

Account control related:

  • Whether top-up is allowed;

  • Whether withdrawals are allowed;

  • Whether overdrafts are allowed;

  • Whether payment is allowed;

  • Whether transfer is allowed;

  • Whether transfers are allowed out;

  • Whether there is a safety guarantee;

  • Active or not;

  • Whether to freeze;

Capital related:

  • Current account balance: equal to available balance + frozen balance;

  • Current account available balance;

  • The frozen balance of the current account. A frozen balance is an amount that cannot be used in an account for the time being. At the time of payment, it is often frozen first, after the goods are out of storage, and then the actual implementation of the deduction.

Bank card and third-party payment information:

  • ID of the third party entity;

  • Third-party account number, such as bank card number or open_ID in third-party payment, etc.;

  • Third-party app_id;

  • The expiration date of the account and when the account expires.

Note that some third party information can not be saved, such as user account password, credit card CV number, etc. To prevent account information from being crawled or accidentally leaked, sensitive fields such as passwords need to be encrypted and saved, or even saved in another table. Furthermore, in order to avoid accidental modification of account information, you can also add a verification field, which can be set when data is written, verified when data is read, and closed once any data problem is found.

Trading model

Transaction record, transaction flow, account flow and transaction book, these three confusing concepts, from the data, but not complex, their core is the transaction flow, account flow is from the perspective of the account of the transaction flow. So there are a lot of things that go on in a transaction. What do you need to document? Considering that transaction records will be used for risk control and credit analysis, the more comprehensive information that can be collected, the better.

  • Serial number: Each transaction has a different serial number. The serial number needs to be designed in detail according to the business situation. This number is often the basis of the transaction table to do sub-table sub-library.

  • Transaction record creation time;

  • The last modification time of transaction records;

  • Account code

  • The associated order number, provided by the merchant;

  • Order name, description, associated address and other information;

  • Cost information, including: settlement currency type, original cost, actual cost, etc.;

  • Transaction subject information: record the ID, type, name, account number, account type, IP address, mobile phone number, platform, notification email, current location, etc. This information can be obtained from the body table, but considering that the body table information can be modified at any time, the detailed original information needs to be recorded here.

  • Counterparty information, record the ID, type, name, account number, account type, mobile phone number, platform, notification email, etc.

  • Transaction channel information, record the entity ID of the transaction channel used, the channel account, the time when the channel executes the payment, the order number returned by the channel side, etc. If an error occurs, record the error message and error code received from the channel.

conclusion

As mentioned above, the model for both accounts and transactions is complex. Stay tuned for a follow-up article on whether it’s necessary to record so much information and how to use these models in transactions.

Headline guys, please give me a thumbs up.

Thank you for your attention to this article. If you need to receive the latest works of Phoenix Old Bear in time, please scan the wechat public number of “Phoenix Old Bear”, thank you.