In-System Accounting
There is a set of implemented processes that build up an internal system accounting.
The main Idea is to track cash-in and cash-out operations, commissions and balances on user’s wallets. For this purpose there can be created any types of coins (wallets) within the system as well as different types of atomic operations (see definitions below).
Below we describe main terms and entities used within the system code and API documentation to provide more details on how the accounting layer is built.
Wallet – in-system account, internal wallet in SDK which represents balance. The wallet can be at any level – system, merchant, referrer, gate etc. In the code, the wallet is named as coin.
Core Entities
• BusinessProcess – is a process that causes atomic transactions, long. Having access to the Source code you can extend any Business Process with a set of required atomic transactions. See our example.
• BusinessRequest – adds statuses to processes
• Transaction – single atomic step.
What is a Transaction?
Transaction is an atomic operation on 1 or 2 coins of the same Issuer. It has no status or flow, because it is persisted within a single database transaction.
There are following transaction types in the system:
| Type | Description |
| issue | create a coin with defined balance; |
| transfer | simple funds transfer from srcCoin to destCoin; |
| split | issue destCoin and transfer some funds there from srcCoin; |
| merge | transfer all funds from srcCoin to destCoin and delete srcCoin; |
| redeem | withdraw funds from srcCoin; |
| balance | withdraw funds from srcCoin for checking it’s balance (currently not used); |
| commission | funds transfer from srcCoin to destCoin, where destCoin is a commission one; |
| authorization | hold funds for transfer from srcCoin to destCoin (destCoin may be absent); |
| commission_authorization | hold funds for transfer from srcCoin to destCoin , where destCoin is a commission one; |
| capture | capture (remove hold and perform transfer) funds held by authorization transaction; |
| commission_capture | capture funds held by commission_authorization transaction; |
| reversal | remove hold created by authorization transaction; |
| commission_reversal | remove hold created by commission_authorization transaction; |
| hold |
What is a Business Process?
BusinessProcess is any process that can cause a balance change of Coin. Its main purpose is grouping Transactions by the business function they perform.
For example, GateProcess can have up to 8 Transactions: several funds holds, accounting transfers, hold captures etc. So to show transaction history for a user we need to group them into a “container” which is our BusinessProcess.
The BusinessProcess class is defined as abstract to force developers to specify related business information in each implementation. JPA inheritance strategy is JOINED, so each subclass must have its own table and therefore migration for it. Read more about Business Processes.
What is a Business Request?
BusinessRequest is an entity allowing BusinessProcess to become more flexible in case of status transition flow.
For example, BusinessProcess can be in pending status, while its BusinessRequest can have either pending, requires_confirmation, approved_by_accountant, etc.