Integration reference
Rail selection decision matrix
Decision dimensions for enabling settlement and payout rails—risk, reconciliation cost, and operational maturity tradeoffs.
01
Purpose
Use this matrix when enabling inbound settlement or outbound payout rails for an approved merchant environment. It frames tradeoffs—you still document exact configuration in your internal runbooks.
02
Decision dimensions
Score each candidate rail against operational maturity—not marketing coverage.
Illustrative dimensions (merchant-defined weighting).
| Dimension | Lower operational cost | Higher operational cost |
|---|---|---|
| Reconciliation complexity | Single asset, stable memos | Multi-hop, memo-less sends |
| Confirmation latency | Predictable confirmation policy | Long async finality windows |
| Exception volume history | Low taxonomy noise in sandbox | Frequent amount/reference mismatches |
| Treasury posting clarity | Clear recognition gates | Ambiguous detection vs posting |
| Webhook maturity | Documented events + retries | Sparse event catalog |
- 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