Skip to main content
Webhooks are how RadiumOne tells your server about things that happen outside a direct API response — a payment that settles, a delayed decline, or a settlement batch closing. They’re also your recovery path when a request to RadiumOne times out: the eventual outcome still arrives as an event even if your original call never got a synchronous answer.

How it works

  1. Your server creates a payment (purchase or authorize) and gets a synchronous response.
  2. RadiumOne emits an event (for example payment.captured) to your registered endpoint, signed with your webhook secret.
  3. Your endpoint verifies the signature and responds 2xx quickly.
  4. If delivery fails, RadiumOne retries on a backoff schedule for up to about 30 hours before giving up on that event.
  5. If you never see the event you expected (a missed delivery, or your endpoint was down), call an authenticated GET to 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 its whsec_… 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.
A minimal handler putting all of this together:

Recovery after timeouts

If a purchase, authorize, capture, void, or refund call times out or returns a 5xx 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.
Treat any client-side redirect or callback as a hint only. Always confirm the final payment status from your server, using an authenticated GET request or a webhook — never from a query parameter or browser postMessage alone.

Test your integration

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

Go-live notes

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.
Last modified on September 15, 2026