Skip to main content
Webhook delivery is at-least-once and unordered by design. You saw a duplicate id, events for the same transaction arrived out of sequence, or you never saw an event you expected at all.
TL;DR — Dedupe on the event id, sort by created_at for true order, and reconcile against your own stored transaction ids with status inquiry rather than waiting indefinitely.

When this happens

  • Duplicate: the same event id arrives more than once — after a retry, or after a network blip hid a successful 2xx from RadiumOne.
  • Out of order: a retry of an earlier event arrives after a later one for the same transaction.
  • Missed entirely: your endpoint was down, slow, or — if failures were sustained enough — suspended (fatal failure kinds, ≥5 deliveries over ≥24 hours; recovery is admin/support-only, not automatic).

What you see

What to do

1

Dedupe on the event ID

Track id values you’ve already processed and skip a repeat — see Webhooks overview: build your handler for a minimal handler you can adapt. In production, back this with a persistent store that enforces a unique constraint on the event id (a database column, not just an in-memory set) so a duplicate insert fails safely even across restarts or multiple server instances.
2

Order by created_at, not by arrival order

If you need the true sequence for one transaction, sort by each event’s created_at rather than trusting delivery order — see Retries, ordering, and duplicates: ordering.
3

Run a reconciliation job against your own stored transaction IDs

Don’t wait indefinitely for a webhook that may never arrive. RadiumOne has no list-by-order_reference or get-by-ID endpoint — reconciliation depends on the transaction ids you already stored from create responses and prior webhooks. For any of those you haven’t heard a terminal outcome for, poll status inquiry (API reference):
For batch-level reconciliation, see Retrieve a settlement batch.
4

Re-register a suspended endpoint through support

If your endpoint was suspended, fix the underlying issue first (a bad hostname, an expired TLS cert, a route that returns 410), then contact support to reactivate it — see Retries, ordering, and duplicates: endpoint suspension.

Prevent it

  • Make your handler idempotent on event id before you go live.
  • Monitor for an unexpected gap in webhook traffic — a suspended endpoint receives nothing and gives you no other signal.

Test it

See Test your integration for simulated retry, duplicate-delivery, and out-of-order scenarios.

Webhooks overview

Endpoint setup and the handler steps.

Retries, ordering, and duplicates

Delivery guarantees, backoff schedule, and suspension mechanics.
Last modified on September 15, 2026