Integration reference
Asynchronous settlement lifecycle model
Intermediate states when detection precedes confirmation and treasury posting—without collapsing to a single paid flag.
01
Intermediate states
Async settlement requires visible intermediate truth across planes—especially when customer communication and fulfillment policies diverge from treasury posting.
| Phase | Provider plane | Commerce may | Finance may |
|---|---|---|---|
| Detection | Paid | Notify pending detection | Not post |
| Policy wait | Paid or intermediate | Hold high-risk SKUs | Not post |
| Confirmed | Confirmed | Fulfill per policy | Begin reconciliation |
| Recognized | Confirmed | Complete order | Treasury posting allowed |
- 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