Accounting Model
The SDK.finance Accounting Model gives an opportunity to see in-system money circulation in the separate wallet balance on the runtime.
The Approach
There are two types of account usage: accounting (use for the accounting calculation) and circulation (use for issuing calculation)
The issuing_balance account is a wallet with usage=accounting, which reflects all the incomes/outcomes to/from the certain Currency issued in the system (with particular and unique currency, e.g. issuing1_balance USD1=currency USD1).
The client_system_commission account is the wallet to account internal system commissions.
This wallet is created along with client’s wallet or during operation processing if it doesn’t exist.
Accounts with usage=accounting must not be included in the circulation volume
Accounts with usage=circulation must be included in the circulation volume
The technical_transit account is used for the technical splitting of the transaction amount to separate accounts (for commission, settlement, etc). After the operation is processed the balance of this account always must be equal to 0.
To reconcile the volume of circulation (which was through a particular Currency issued, e.g. Currency USD1) in the system it is required to compare the balances of the Currency1 account (coin type=issuing1_transfer) – with the balance of issuing1_balance (coin type=issuing1_balance) this balances must be equal
Account Types
Account or Wallet is an internal wallet in SDK which represents balance. Wallet can be at any level – system, merchant, individual, gate etc. In the code, wallet is named as coin.
Each type of account can be technical and not technical (technical: TRUE/FALSE). Technical accounts are temporary containers for technical operations, which have a limited life cycle according to the Business Process flow.
Wallet type | Organization | Description | Level | Usage | Collector |
|---|---|---|---|---|---|
regular_gate_commission | system, gate-provider | Wallet for Individuals gate operations commission. It is used for calculations of commission income for specified 3rd party provider and specific commission collector. Recipient of the commission depends on the collector parameter for this wallet type:
It is created automatically for the definite currency when commission for gate operation is configured in any contract | gate | Accounting | Provider |
business_gate_commission | system, gate-provider | Wallet for Merchants gate operations commission. It is used for calculations of commission income for specified 3rd party provider and specific commission collector. Recipient of the commission depends on the collector parameter for this wallet type:
It is created automatically for the definite currency when commission for gate operation is configured in any contract | gate | Accounting | Provider |
technical_transit | system | Transit wallet for money movement consistency. When the operation is completed the balance of this account must be 0. It is created automatically for each operation. | operation | Circulation | – |
regular_system_commission client_system_commission is used instead | system | Wallet for Individual internal operation commission OR gate operation commission, when the commission is taken within the circulation. It is created automatically for the definite currency when commission for internal operation is configured in any contract. | system | ||
business_system_commission client_system_commission is used instead | system | Wallet for Merchant internal operation commission OR gate operation commission, when the commission is taken within the circulation. It is created automatically for the definite currency when commission for internal operation is configured in any contract. | system | ||
client_system_commission | individual, merchant | wallet to account internal system commission wallet is created along with client wallet or during operation processing if not exists | business user | circulation | – |
issuing_balance | system | Wallet for money issued in the system (shows circulation money volume). It is created automatically for the definite currency when commission for any operation is configured in any contract | system | Accounting | – |
debt_gate_settlement | gate | Wallet to account money that the system paid to provider because provider commission is greater than commission deducted from the client. Such operation is possible if It is created automatically for the definite currency when commission for gate operation is configured in any contract | gate | accounting | – |
debt_gate_commission | gate | Wallet to account provider commission that is not covered by commission deducted from the client, because provider commission is greater than commission deducted from the client. Such operation is possible if It is created automatically for the definite currency when commission for gate operation is configured in any contract | gate | Accounting | Provider |
exchange_reserve | system | Wallet for exchange reserve for Currency Exchange operation. It is created automatically for the definite currency when commission for currency exchange operation is configured in any contract | system | Circulation | – |
client | individual, merchant | Wallets owned by business users (individual, merchant). It is created by the business user or by the service user on behalf of the business user. | Business user (Individual, merchant) | Circulation | – |
gate | gate-provider | Wallet for provider settlement money flow for gate operations. Works as transit account and when operation is completed balance of this wallet should be 0. | gate | Accounting | – |
reserve | system | Wallet for cash which is being transferred between cash desks. It is created automatically for the definite currency when commission for cash desc operation is configured in the any contract for any cash desk. | system | Circulation | – |
cash | cash desk, merchant* *merchant – as legacy logic | Wallet for cash desk. It is created automatically:
Cash desk operations: | cash desk | Accountinf | – |
prepaid | individual, merchant | Special type of the wallet for prepaid vouchers. It is created when user creates prepaid voucher. Prepaid vouchers allow business users to purchase a voucher with a specific denomination and redeem it for goods or services later on. | client | Circulation | – |
cashback_payer (is not used) | the merchant obligation before the payers to pay cashback, the funds from this coin are sent to payer client coin at the end of the month | client | |||
cashback_merchant (is not used) | the obligation to pay cashback for merchant who accept payment, the funds on this account are sent to payer client coin (also to the commission coin) at the end of the month | client |
*Level – the logical level of the account, is not linked with a certain organization
Supported commission directions for all operation types
The System supports the following commission directions for operations (via Front-end and API):
Operation type | Supported commission direction |
|---|---|
TOPUP via provider | OUT (tab Provider Commission) |
WITHDRAW via provider | IN (tab Provider Commission) |
PURCHASE via provider | OUT (tab Product Commission) |
TRANSFER | IN, OUT, SHARED |
TOPUP via bank | OUT |
WITHDRAW via bank | IN |
Merchant PAYMENT | IN |
INVOICE | IN |
Voucher CREATION | OUT |
Voucher ACTIVATION | IN |
TOP UP via cash desk | OUT |
WITHDRAW via cash desk | IN |
ISSUE CARD (based on PURCHASE via provider operation) | OUT (tab Product Commission) |
Creation of all other commission directions for certain operations is blocked on the Front-end, API, and code level. For source code clients it’s possible to unlock and use additional configurations.