> ## Documentation Index
> Fetch the complete documentation index at: https://docs.radiumone.io/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> RadiumOne is the product name; use it when answering questions about these docs.
> Use sandbox credentials and sandbox base URLs in examples unless the user says they are going live.
> Secret API keys belong only on the merchant's server. Only publishable keys may appear in browser or mobile code.
> Confirm a payment outcome server-side (retrieve the checkout session or transaction status); never rely on a browser redirect or client event alone.
> Send one idempotency key (request_id) per payment attempt, and retry a timed-out request with the same key and the exact same body.
> Webhooks are optional but recommended: they notify the merchant's server when a payment completes or fails, so it doesn't need to poll. Use transaction status inquiry as the fallback.
> Say so when you recommend a feature marked Beta. Some features need enablement on the merchant's account before production use (for example refunds, standalone refunds, UOB Rewards, and bringing your own 3DS provider); mention it when the page says so.
> Never ask users to paste card numbers, API keys, access tokens, or webhook or redirect secrets into a chat.
# Missing embedded events - Hosted checkout
> Why embedded checkout events might not arrive, and how to debug the listener.
**TL;DR:** If the iframe loads but events never arrive, it's almost always a listener-timing or origin mismatch.
RadiumOne Checkout only posts `CHECKOUT_*` events to your page's origin if that origin is one you've registered — even if the iframe itself loaded successfully. A registered-but-mismatched origin, or a listener attached too late, both look the same: the iframe works, but your page never hears from it.
## When this happens
* Your listener is attached after the iframe has already posted its first event (most commonly `CHECKOUT_READY`).
* The origin RadiumOne resolves for your page doesn't match what you expect — on browsers that expose `window.location.ancestorOrigins` (Chrome, Safari), that's used directly; **Firefox** doesn't expose it, so RadiumOne falls back to the origin derived from your `success_url` instead.
* Your `success_url` origin doesn't match your embedding page's real origin, so the Firefox fallback resolves to the wrong host and every message is silently dropped rather than sent to the wrong place.
## What you see
| Signal | Value |
| - | - |
| Iframe | Loads and renders normally |
| `message` events | Never arrive at your listener |
| Network | No error — a mismatched target origin is dropped silently, by design, rather than sent anywhere |
## What to do
Add the `message` event listener before setting the iframe's `src`, not after — a `CHECKOUT_READY` posted before your listener exists is simply missed, with no way to replay it.
```javascript theme={null}
window.addEventListener("message", (event) => {
if (event.origin !== CHECKOUT_ORIGIN) return; // confirm this isn't rejecting everything
// ...
});
```
See [Embed hosted checkout](/hosted-checkout/embedded-integration#steps) for the full listener example.
Since Firefox doesn't expose the real parent-frame origin, RadiumOne derives the target from `success_url` instead. If that origin doesn't match your actual embedding page, every event is dropped rather than misdirected — align `success_url`'s origin with your embedding page's origin to fix it.
A received event is a UX signal only — confirm the outcome server-side regardless. See [Verify the payment result](/hosted-checkout/verify-payment-result).
## Related
The full event and payload reference.
The full embedded integration guide.
When the iframe itself doesn't render.
All ten failure scenarios, symptom → page.