Guide
Treasury recognition flow
How finance acceptance differs from lifecycle Confirmed states—and why treasury posting is typically the strictest recognition gate.
Definitions: Treasury recognition · Treasury posting · Finance reconciliation
Conceptual operational diagram for this guide. Not live merchant data or metrics.
01
Recognition vs Confirmed
Confirmed reflects provider lifecycle semantics under your policy. Treasury recognition is when finance accepts funds for allocation, reporting, or release—often after finance reconciliation matchers succeed.
02
Reference flow
- Verified lifecycle event updates provider plane.
- Commerce and provider planes align via matchers or exception queue.
- Finance reconciliation validates books-ready criteria.
- Treasury posting recorded under dual-control or approval rules where required.
- Payout orchestration—if any—is a separate initiated workflow.
03
Stablecoin treasury notes
USDT and other stablecoin flows amplify rail-context discipline: same asset symbol on different networks is not interchangeable operationally. Recognition policy should reference rail context, not ticker alone.
- 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