How it works
- Your server creates a payment (purchase or authorize) and gets a synchronous response.
- RadiumOne emits an event (for example
payment.captured) to your registered endpoint, signed with your webhook secret. - Your endpoint verifies the signature and responds
2xxquickly. - If delivery fails, RadiumOne retries on a backoff schedule for up to about 30 hours before giving up on that event.
- If you never see the event you expected (a missed delivery, or your endpoint was down), call an authenticated
GETto resolve the current status instead of guessing.
Before you begin
Your endpoint must be reachable over HTTPS from the public internet, respond within RadiumOne’s delivery timeout, and return a
2xx status only once you’ve durably accepted the event (see Build your handler below).Register your endpoint
The exact self-service flow for registering a webhook endpoint and getting itswhsec_… signing secret is still being finalized. Until then, contact support with the URL you want events delivered to. See Sandbox and API keys for where the webhook secret fits among your other credentials.
Build your handler
1
Read the raw request body
Capture the exact bytes RadiumOne sent — before any JSON parsing. Signature
verification runs over the raw body; a re-serialized copy (even one that looks
identical) produces a different signature and fails verification. Most frameworks
parse the body automatically unless you opt out for this route.
2
Verify the signature
Check the
X-RadiumOne-Signature header against the raw body before you trust
anything in the payload. See Verify webhook signatures
for the algorithm and generated verifier code.3
Dedupe on the event ID
Deliveries are at-least-once — the same event can arrive more than once. Store
each event’s top-level
id (also echoed in the X-RadiumOne-Event-Id header) and
skip processing if you’ve already seen it. See Prevent duplicate
payments for how this fits into
your wider duplicate-prevention strategy.4
Enqueue, don't process inline
Hand the event off to a queue or background job before doing slow work (database
writes, fulfilment, notifications). Responding fast matters more than finishing fast.
5
Respond 2xx immediately
Return a
2xx status as soon as you’ve durably accepted the event — not after
fulfilment completes. A slow or non-2xx response is treated as a delivery failure and
triggers a retry, which can duplicate work if your processing isn’t idempotent.6
Process the event
Only now branch on
type and data to fulfil the order, update your records, or
trigger reconciliation. See Webhook event types for every
event and its payload shape.Recovery after timeouts
If a purchase, authorize, capture, void, or refund call times out or returns a5xx
or PENDING result, don’t guess at the outcome. Either wait for the matching webhook,
or call GET /v1/transactions/{id}/status directly (API reference) — see
Handle timeouts and unknown outcomes for the full recovery walkthrough.
Test your integration
See Test your integration for simulated delivery, retry, and duplicate-delivery scenarios.Go-live notes
- Register your production endpoint and rotate to a production
whsec_…secret before accepting real payments — see Verify webhook signatures. - Make sure your endpoint responds fast and only over HTTPS; a slow endpoint looks identical to a broken one and can eventually be suspended — see Retries, ordering, and duplicates.
- Review the full go-live checklist.
Next steps
Verify webhook signatures
Algorithm, key encoding, and generated verifier code.
Webhook event types
Every event, its payload shape, and the fields RadiumOne publishes.
Retries, ordering, and duplicates
Delivery semantics, the backoff schedule, and endpoint suspension.
Settlement and reconciliation
Track settlement batches with
settlement.* events.Recover from missed, duplicate or out-of-order webhooks
What to do when delivery doesn’t go as expected.