Guide
Payment lifecycle decision tree
Operator-oriented paths from detection through policy confirmation, exceptions, and books-ready gates—without collapsing states.
Definitions: Payment state transition · Settlement checkpoint · Settlement eligibility
Conceptual operational diagram for this guide. Not live merchant data or metrics.
01
After detection (Paid or equivalent)
Ask: does amount, asset, and reference meet settlement eligibility? If no, route to exception queue—do not auto-fulfill high-risk SKUs unless policy explicitly allows.
02
Policy confirmation gate
Confirmed means your configured confirmation semantics met—not merely that an explorer showed a transfer. Entitlements and operational finality may track Confirmed; treasury posting may still wait for finance reconciliation.
03
Exception branch
Underpayment, wrong reference, or timing skew: pause automated posting, assign taxonomy class, collect evidence (payment_id, rail context, timestamps). Support shortcuts that bypass provider-plane transitions create operational drift.
04
Books-ready / treasury posting
Finance reconciliation satisfied? If yes, record treasury posting under controls. If no, keep commerce/provider states honest—do not mark internal ledger state “final” informally.
- 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