Integration reference
Confirmation policy matrix
Map amount tiers, asset types, and use cases to confirmation depth and human review gates—merchant-defined, not universal.
01
Purpose
Map merchant use cases to confirmation depth and human review requirements. This is policy design—not a guarantee about chain behavior.
| Use case tier | Typical gate | Human review trigger |
|---|---|---|
| Low materiality digital goods | Paid or Confirmed per policy | Amount tolerance breach |
| Standard B2B invoice | Confirmed per rail policy | Reference mismatch |
| High materiality / treasury | Confirmed + finance reconciliation | Any ambiguity or sanctions flag |
| Payout initiation | Recognized balance + dual control | Ledger/provider disagreement |
- 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