Developers1 min read
Networks fail mid-request and webhooks are delivered at least once. An integration that is not idempotent will eventually create duplicate transactions or double-process an event.
Outbound requests
- Send an idempotency key on transaction creation and reuse the same key when you retry.
- Retry with backoff on network errors and 5xx responses only.
- Never retry a request whose failure you have not classified — read the transaction first.
Inbound events
- Record processed event identifiers and ignore repeats.
- Make handlers order-independent; delivery order is not guaranteed.
- Never treat an event as an instruction to move money in your own system without reading the transaction state.
Specification
Header names, retry schedules and error semantics are documented in the API reference and the webhook documentation.
Go deeper
Related guides
DevelopersWebhook eventsHow ArosaPay notifies your system of transaction state changes, and how to consume them safely.DevelopersAPI overviewWhat the ArosaPay API covers, how it is authenticated, and where the full reference lives.DevelopersTesting an integrationWhat to exercise before going live, including the exception path most integrations forget.
Last updated