In-System Accounting

28. 03. 2023

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.
• BusinessRequest – adds statuses to processes
• Transaction – single atomic step.

What is a Business Process?

BusinessProcess is any process that can cause balance change of Coin. It’s main purpose is grouping Transactions by 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. BusinessProcess class is defined as abstract to force developer to specify related business information in each implementation. JPA inheritance strategy is JOINED, so each subclass must have it’s own table and therefore migration for it.

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 it’s BusinessRequest can have either pending, requires_confirmation, approved etc.

What is a Transaction?

Transaction is an atomic operation on 1 or 2 coins in the same currency. It has no status or flow, because it is persisted within 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`