Integration reference
Provider retry semantics comparison
Conceptual comparison of at-least-once delivery, handler response expectations, and idempotency responsibilities.
01
Conceptual comparison
Validate exact retry behavior against your environment documentation. This table compares responsibilities—not vendor rankings.
| Concern | Provider responsibility | Merchant responsibility |
|---|---|---|
| Delivery attempts | Retry on non-2xx/timeout per their policy | Idempotent handlers + durable writes |
| Duplicate delivery | At-least-once common | Duplicate suppression store |
| Ordering | May reorder under failure | State machine ordering rules |
| Signature | Sign per documented algorithm | Verify raw bytes server-side |
- 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