Guide
Settlement vs payout
Inbound settlement rails, merchant balance semantics, and payout orchestration are related—but conflating them creates treasury and support incidents.
Definitions: Settlement rail · Payout rail · Payout orchestration
Conceptual operational diagram for this guide. Not live merchant data or metrics.
01
Inbound settlement
Settlement rails observe and confirm inbound merchant payments on configured networks/assets. Detection and confirmation follow lifecycle semantics—not every Confirmed payment automatically triggers outbound movement.
02
Merchant balance vs wallet slogans
Merchant balance is a ledger-oriented view under product accounting rules. It is not a promise that funds are instantly withdrawable on any rail at any time.
03
Payout orchestration
Withdrawal requests initiate payout orchestration subject to controls, selected payout rails, and finance approval—not implicit on every payment event.
- Retries are normal. Webhook delivery is at-least-once. Design consumers to tolerate duplicates and out-of-order arrivals where possible.
- Asynchronous by design. Payers, chains, and your servers operate on different clocks. UI and finance should not assume synchronous finality.
- Eventual consistency. API reads, webhooks, and portal views may briefly diverge during transitions. Reconciliation jobs exist to converge truth.
Walkthroughs: /operations