An embedded form works for you but fails for visitors: check browser storage

Start with the visitor’s task and the two addresses

Record the page that contains the form and the provider’s supported direct form address. Check that both refer to the same published form, not a public version and an editor preview. Note the failing step: initial display, sign-in, moving to another step, attachment upload, submission or confirmation.

For a fictional workshop, the embed might display appointment choices correctly but return to sign-in when the visitor selects a time. That is a different issue from a blank frame before any choices appear. A screenshot of the first screen cannot establish that either full journey works.

Write the expected final result as well: a visible confirmation and, where appropriate, a test record in the provider’s authorised dashboard. A disappearing spinner does not prove a submission was accepted. If the result of a previous attempt is uncertain, check the record before retrying.

First establish whether the frame is permitted to load

Inspect the browser’s relevant Console and Network context while reproducing the failure. A refusal to frame the provider, a missing script and a successful page followed by a session error require different fixes. Our Console and Network guide covers collecting that evidence without exposing credentials.

The provider’s response can restrict embedding through Content Security Policy frame-ancestors. Your site may need to be an approved ancestor. Adding a permissive attribute to your own frame cannot override that response. Give the provider the intended public origin and use its documented embedding route.

The iframe reference also describes sandbox and permission controls. An embed can be allowed to appear while a particular script, form submission or navigation remains restricted. Compare the actual markup with the vendor’s current supported instructions; preserve deliberate restrictions and investigate the specific missing permission.

Do not remove every sandbox token, allow every origin or disable the site’s security policy to make the screen appear. A restriction may be serving a necessary purpose. If the integration requires permissions the site cannot responsibly grant, use the supported standalone route instead.

Then examine the session’s cross-site storage dependency

MDN’s third-party cookie guide explains why a service embedded on a different site may not receive the same cookies it uses in a direct tab. Browser policies and user settings vary. Owning both domains does not, by itself, turn two different sites into one cookie context.

A cross-site cookie may require SameSite=None and Secure for the intended use. Those attributes express cookie behaviour; they do not force a browser to permit third-party storage. Nor can your WordPress page change cookies that the form provider sets on its own service.

In the workshop example, note whether the frame repeatedly sends the visitor to sign-in and whether the associated request reports missing session state. Ask the provider whether its published embed supports visitors with third-party cookies blocked. Do not conclude that every login loop is a cookie problem: redirects, expired sessions and configuration mistakes can produce similar symptoms.

Understand what partitioning and storage access actually solve

Partitioned cookies, also called CHIPS, keep a service’s embedded state separated by top-level site. A form can retain state under one website without making that same state available under every other website that embeds the service.

Consequently, signing into a provider directly does not establish that every partitioned embed shares that login. A partitioned design can suit state local to an embed, but it is not a universal replacement for shared sign-in. The provider must design and test its own session flow.

The Storage Access API offers a supported way for eligible embedded content to request access to otherwise restricted state. Secure context, user interaction, permission rules and browser differences matter. Access can be denied, so a usable failure path is part of the integration.

A storage-access prompt is not the same as your site’s cookie-banner choice. Explain the task clearly without instructing visitors to approve every prompt. Do not paste an unfamiliar script into the page that claims to bypass the browser’s decision.

Give visitors a fallback before the technical repair is finished

Place a visible link beside the embed, such as “Open the booking form on the provider’s website.” Use the official direct address, identify the destination and keep the link available even when the frame fails silently. Avoid a link that depends on the same broken script.

Tell visitors that they may need to restart the form if progress cannot be carried across. Do not promise that unsent answers will transfer unless the provider explicitly supports and you have verified that behaviour. Avoid passing answers or personal information in the fallback URL.

Review the direct page’s keyboard operation, labels, errors and confirmation too. Moving the problem into another tab is not a complete recovery if that route also requires an unavailable login. The accessible-form review provides a separate acceptance checklist.