The three layers, in order of trust
Authoritative: webhook or authenticated GET
Your server should confirm a payment one of two ways:- Wait for a gateway webhook (
payment.captured,payment.declined,payment.failed, and related events) — see Webhook event types and Verify webhook signatures. - Call the authenticated session GET directly, with your secret key:
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 yoursuccess_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.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):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.
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.