Skip to main content
Disclaimer: This article contains AI translations and should only be used as reference. Contact Cobo’s support team through [email protected] if you have any questions.
This article introduces the various types of accounts involved in fund management, and how funds are efficiently allocated and managed between accounts through settlement and allocation after payment collection.

​
Accounts

An account is a virtual fund entity managed in the system ledger, without a one-to-one correspondence to on-chain wallets or addresses.
  • Each operation such as payment collection, settlement, fees, refunds, or payouts creates detailed entries in the ledger, which dynamically update the balance of each account.
  • Fund allocation between accounts (such as automatic settlement or manual allocation) only flows within the ledger and does not directly result in on-chain transfers. Only when performing payouts or refunds will actual on-chain asset transfers be triggered.
The following accounts are currently supported:
  • Developer account: A single account that holds the developer balance. This represents funds belonging to you as the payment collection service provider.
  • Merchant accounts: Each merchant corresponds to an account that holds its respective merchant balance. Each merchant represents an actual business entity receiving payments.
When you perform operations such as payouts or refunds, you need to select which account to use as the source of funds.

​
Deposit attribution

Every deposit must be attributed to a merchant account before it can be settled. How Cobo determines the destination merchant depends on the pay-in mode:
  • Top-up mode: Cobo resolves the payer associated with the receiving address, then attributes the deposit to the merchant that was bound to that payer and address at the time they were created. Replacing a payer’s top-up address does not change this attribution — see Impact after address replacement.
  • Order mode: Cobo attributes the deposit to the merchant that was stored on the order at the time the order was created. This destination does not change even if a later deposit arrives against the same order address.
To support both perspectives, Cobo’s accounting records preserve two sides of every deposit: the payment owner (the payer or order the funds were paid for) and the receiving address the funds arrived at. This lets you trace a deposit back through either the payer/order relationship or the specific on-chain address it used.
Deposits received after an order has already reached Expired, the terminal Underpaid status, or Completed are not attributed to the merchant account, since the order can no longer accept the deposit as part of its normal payment. See Late payment for how these deposits are detected and reported.

​
Fund settlement and allocation

Funds can be distributed between accounts in two ways:
  • Automatic settlement: During the payment collection process, funds are automatically settled to merchant accounts and the developer account based on predefined rules.
  • Manual allocation: You can use the Allocate feature to manually transfer funds between accounts.

​
Automatic settlement

When a payment is received, the system automatically distributes funds to the corresponding merchant account and developer account based on predefined rules. The diagram below illustrates this settlement process. The specific settlement rules may vary depending on the payment collection mode:

​
Top-up mode

In top-up mode, fund settlement is based on the developer fee rate (developer_fee_rate) set when creating the merchant. The developer fee rate determines the proportion of each top-up that is settled to the developer account. For details on configuring this rate, refer to Merchants. Example: When the developer fee rate is 1%, a 100 USDT top-up will be settled as 99 USDT to the merchant account and 1 USDT to the developer account. Before/after example: Suppose the merchant account balance is 500 USDT and the developer account balance is 50 USDT before the deposit. A 100 USDT Top-up deposit with developer_fee_rate set to 0.01 posts two independent balance-change records: Each share is posted as its own balance-change record, and the developer’s share is rounded down to the token’s supported precision. If the developer fee rate rounds down to 0 for a given deposit (for example, a very small deposit at a low rate), no PSP_TOP_UP record is created for that deposit — only the MERCHANT_TOP_UP record is posted. You can observe the gross amount received by calling List payer transactions, and the resulting balances by calling List merchant balances, Get developer balance, and List balance changes.

​
Order mode

In order mode, fund settlement is based on the amount parameters set when creating the order. The ratio between the developer fee (fee_amount) and the payable amount (payable_amount) determines the proportion of each order that is settled to the developer account; pricing_amount may not be present at all for orders priced directly in cryptocurrency, so it cannot serve as the basis for this ratio. For details on configuring these parameters, refer to Payment collection in order mode. Example: When the order amount is 99 USDT and the developer fee is 1 USDT, the actual received amount of 100 USDT will be settled as 99 USDT to the merchant account and 1 USDT to the developer account: Before/after example: Suppose the merchant account balance is 500 USDT and the developer account balance is 50 USDT before settlement. For a normal Payment Order with fee_amount set to 0, a 100 USDT deposit that exactly matches the payable amount credits the full amount to the merchant account: The developer balance is unchanged because fee_amount is 0. For a worked example with a nonzero fee_amount, see Payment collection in order mode.
Special case handling:
  • Overpayment/Underpayment: Funds are settled according to the same ratio as above
  • Late payment: The received funds are not settled to the merchant account through the automatic-settlement flow described above. See Late payment for how late payments are detected and reported.

​
Refunds

The source of the refund amount can be either the merchant account or the developer account.
  • When the refund amount comes from the merchant account, you can specify a developer fee to charge a service fee for the refund. For example, when the refund amount (payable_amount) is 100 USDT and the developer fee (merchant_fee_amount) is 1 USDT, 1 USDT from the 100 USDT refund will be settled to the developer account, and the payer will actually receive 99 USDT.
  • When the refund amount comes from the developer account, the developer fee field will be ignored, and the full refund amount will be deducted from the developer account and transferred to the payer.
The following diagram shows the settlement and flow of funds during the refund process (sample data):

​
Manual allocation

In addition to automatic settlement during payment collection, you can also use the Allocate feature to manually transfer funds between accounts. For details, see Allocate funds.

​
Balances

Account balance refers to the total amount of funds in an account that can be used for payouts or refunds at a specific moment. This balance can be queried through the Balance module in the Payments App or by calling List merchant balances and Get developer balance. Payout eligibility is based on this ledger balance, not on whether the underlying on-chain funds have already been physically consolidated (swept) to a payout-ready address. A merchant or developer account can show a sufficient ledger balance and be eligible for a payout while fund consolidation is still catching up in the background. For how Cobo prepares and consolidates funds ahead of a payout, and the timing this can add, see Crypto payouts. Balance changes mainly come from the following activities: Situations that increase balance:
  • Automatic settlement during payment collection
  • Manual allocation transfer in
  • Automatic settlement during refunds (only applicable to the developer account)
Situations that decrease balance:
  • Payout
  • Refund
  • Manual allocation transfer out
The following diagram shows the main sources and destinations of merchant account balances and developer account balances (allocation operations not included):