Deposit Flow

A deposit receives externally sent assets into an OOLIN account balance. Address allocation, transfer discovery, and completed credit are different points in the process. A customer wallet confirms completion through deposit detail status.

Deposit Addresses explains destination information, allocation, and retrieval before sending funds. This page covers processing after assets are sent to that destination.

External deposit stages

Select the customer account, asset, and network
  → provide the deposit address and required memo
  → customer sends funds externally
  → discover the deposit record
  → track confirmation and processing
  → confirm COMPLETED and query the balance/ledger

Stage	What to verify	Meaning for the wallet
Prepare destination	Account, supported asset/network, address/memo	Provide deposit instructions
External transfer	Send the selected asset on the selected network	Sending alone does not prove wallet credit
Discover deposit	deposit_id, type, amount, status	Display the record and start tracking
Processing	Confirmation, approval, verification states	Deposit is not yet complete
Completion	status: COMPLETED, confirmed_at	Confirm successful receipt
Verify records	Balance and DEPOSIT / CREDIT ledger entry	Check credited funds and reconcile

Confirmations indicate how firmly the blockchain has established a transfer. Processing time depends on the network and deposit policy; elapsed time alone does not confirm completion.

A 100 USDT customer deposit

Assume the customer's initial USDT balance is zero and they send 100 USDT to the correct destination.

• Once discovered, display the 100 USDT deposit with its processing state.
• Track that deposit_id while it is non-final and wait for successful funding.
• At COMPLETED, query the USDT balance and related deposit ledger entry.
• Without concurrent activity, the completed deposit increases the balance by 100 USDT.

An explorer observation or tx_hash does not prove account credit completed. If your service applies order or reward effects after deposit completion, make repeated processing of the same completion response idempotent.

Discovery and status tracking

Deposit lists find new records; detail queries retrieve later states of already discovered deposits.

Purpose	API	Persist
Discover external deposits	GET /deposits?account_id={account_id}&type=EXTERNAL&after_id={cursor}	deposit_id and list next_cursor
Track an existing deposit	GET /deposits/{deposit_id}?type=EXTERNAL	Last state and records requiring another check

An ID cursor does not replay later status changes. Keep polling a processing deposit by detail even after the discovery cursor advances. Persist items and the cursor, then resume discovery from the stored checkpoint after a restart.

External and internal deposits can use different ID ranges. Distinguish (type, deposit_id) and maintain separate cursors. Do not use tx_hash alone to identify every deposit record.

Success, processing, and refund states

Deposit APIs provide detail status without user_status.

State	Your service's behavior
PENDING, INSPECTED, APPROVE_PENDING, APPROVED, VERIFIED	Continue detail polling without marking success
REFUND_REQUIRED, REFUND_REQUESTED, REFUND_PENDING	Track refund progress and operational follow-up without successful funding
COMPLETED	Confirm receipt and reconcile balance/ledger
REFUNDED, FAILED	Record an unsuccessful final outcome

A completed refund differs from successful wallet credit. Use deposit IDs and states when requesting support; do not independently adjust balances. See Status Codes for the full contract.

Funds received from another account

An internal transfer increases the recipient account's balance without an external blockchain transfer. General account transfers and customer-to-merchant payments can both receive funds this way.

Query internal deposits with type=INTERNAL; they display PENDING or COMPLETED. The ledger records INTERNAL_IN / CREDIT linked to the original internal withdrawal reference. Confirm an individual transfer/payment through the original withdrawal detail.

Persistence and restart recovery

Persist deposit type/ID, account, asset, network, raw amount/decimals, status, tx_hash, confirmed_at, and last-check time. Maintain discovery cursors separately from non-final deposits to recover both tasks after a restart.

Follow Issue a Deposit Address and Check a Deposit for examples. Balances and Ledger explains the records after credit.