Skip to main content
Every hosted-checkout integration gives you three signals about a payment’s outcome. Only one of them is proof — the other two are UX hints your server should never fulfil on alone.

The three layers, in order of trust

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.

Authoritative: webhook or authenticated GET

Your server should confirm a payment one of two ways:
  1. Wait for a gateway webhook (payment.captured, payment.declined, payment.failed, and related events) — see Webhook event types and Verify webhook signatures.
  2. Call the authenticated session GET directly, with your secret key:
If neither signal arrives in a reasonable time, see Confirm payment when the redirect never arrives. Either way, check that data.order_reference and data.amount/data.currency match the order you’re fulfilling — don’t fulfil solely because status says completed without also matching the order. A malformed checkout_id or API key on the GET returns 404 resource:not_found; a missing session, or one that belongs to a different account, returns 404 session:not_found with an identical body either way — don’t try to distinguish the two.

UX hint: the redirect signature

If you’ve configured a redirect secret, a successful redirect to your success_url carries checkout_id, status, ts, sig, and transaction_id when one is known. ts is a Unix timestamp in seconds (contrast with the authenticated GET response, where expires_at/created_at/updated_at are epoch milliseconds, and the create response’s expires_at, which is an ISO 8601 string). Verifying sig confirms the URL wasn’t altered in the shopper’s browser — it is not proof that a charge happened, and it is never sent at all on a decline, expiry, or back-button return (see Redirect integration).
RadiumOne doesn’t check ts itself — the checkout team’s guidance is that your server enforces the tolerance: reject a signed return whose ts is more than 5 minutes old, the same as an invalid sig.
In two rare cases — replaying the payment-completion call on a session that’s already reached a terminal state — the redirect can carry success_url (or, for a failed session, cancel_url) with none of the usual query parameters, not even checkout_id. If you see a return with no parameters at all, don’t assume anything from the URL — confirm the outcome with an authenticated GET as described above.
Key encoding differs from webhooks. The redirect signature’s HMAC key is the full rsec_… secret string, used directly. This is different from the webhook signature, whose key is the raw bytes obtained by hex-decoding the string after stripping whsec_. Using the wrong encoding for either one makes every signature fail to verify.
Fail closed. If a redirect secret is configured for your account and a redirect arrives with a missing or invalid sig, treat it as unverified — never as confirmation of payment. Also confirm that checkout_id in the URL matches the ID your server stored for that order before trusting anything else in the URL. See Reject invalid redirect signatures for the full walkthrough.

Decision table

Redirect secret: rotate, don’t delete

A redirect secret can be rotated or deleted from your server (via the gateway API, using a bearer access token):
The rotate response contains the new secret in plaintext — store it immediately. Rotating replaces the secret right away — there’s no platform-side overlap window. But a checkout session signs its redirect with whichever secret was active when that session was created, for the session’s whole life: a session created just before you rotate keeps signing with the old secret until it expires. Sessions last ttl_minutes (5–60 minutes — see Session lifecycle). If you want those in-flight sessions’ redirects to keep verifying, keep the old secret available in your own verifier for at least 65 minutes after you rotate (the 60-minute maximum session lifetime, plus the redirect signature’s 5-minute timestamp tolerance), then remove it.
Deleting the redirect secret downgrades your protection. Once deleted, redirect URLs no longer carry a sig at all, so the UX-hint layer disappears entirely — you’re relying solely on the webhook/authenticated-GET layer (which you should already be doing). If you no longer want signed redirects, prefer leaving the secret in place and simply not depending on it, or contact support about your options — don’t delete it as a routine operation.

Next steps

Webhook event types

The full authoritative payload reference.

Session lifecycle

Statuses, TTL, and cancellation.

Handle failures

Ten common failure scenarios and what to do for each.

Redirect and signature errors

Every signal a return to your site can and can’t carry.
Last modified on September 15, 2026