Diagnose the failed request or blocked capability before changing the integration. Cookie restrictions, framing policies, authorisation problems and game-runtime failures require different fixes. WebKit documents default third-party cookie blocking, while browser framing controls can independently prevent an embedded page from loading. (webkit.org)
Use this diagnostic sequence:
| Symptom or evidence | Next investigation |
|---|---|
| Your page blocks the frame URL | Inspect your frame-src policy and the intended supplier allowlist. (developer.mozilla.org) |
| Supplier response refuses framing | Ask the supplier to confirm permitted parent domains and its frame-ancestors or X-Frame-Options policy. (developer.mozilla.org) |
| Authentication works in a tab but not in an embed | Investigate third-party storage dependencies with the supplier. (webkit.org) |
| Console identifies a CORS failure | Identify the specific fetch or API request; do not assume the iframe navigation itself is the problem. (developer.mozilla.org) |
| Controls or scripts fail in a sandbox | Compare required capabilities with the iframe’s sandbox configuration. (developer.mozilla.org) |
Also check the account’s domain registration, launch-token validity and intended territorial access against the supplier documentation.
Capture the device model, OS, browser version, page URL, timestamp, consent state, console messages and a redacted network trace. Reproduce with normal privacy settings; asking visitors to disable browser protections is not an acceptable default remediation.
Do not strip response headers, proxy around a geographic restriction or broaden permissions indiscriminately. Escalate the specific failure with evidence.