Skip to main content
TL;DR: A missing redirect isn’t a failed payment — confirm with a webhook or GET, not the browser.
The shopper’s browser can lose its connection (closed laptop, dropped Wi-Fi, a crashed mobile browser) after they submit payment but before it redirects back to your site. The payment itself is handled entirely between RadiumOne’s servers — it doesn’t depend on the shopper’s browser staying connected — so this is a UX gap on your side, not a lost payment.

When this happens

  • The shopper’s device loses connectivity right after submitting the card form.
  • The shopper closes the browser tab or app before the hosted page finishes redirecting.
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.

What you see

What to do

1

Don't assume the payment failed

A missing redirect only tells you the shopper’s browser didn’t complete the round trip — it says nothing about whether the charge itself succeeded.
2

Wait for the authoritative signal

Fulfil only from a webhook or an authenticated GET — never because the redirect didn’t happen (API reference):
3

Poll with backoff until the session reaches a terminal state

If you’re reconciling by polling rather than waiting on the webhook, back off between calls — processing can legitimately last a few seconds while the gateway completes the charge. Stop once you see completed, failed, expired, or cancelled.

Verify the payment result

The full decision table for every result signal.

Session lifecycle

Statuses in full, including processing.

Handle payment service outages during checkout

When the gateway itself — not just the shopper’s connection — is the problem.

Handle failures

All ten failure scenarios, symptom → page.
Last modified on September 15, 2026