Troubleshooting

PunchOut opens a blank page

The buyer clicks through and gets a white screen, a frame that never loads, or your site loading but immediately logging them out.

Short answer

Two modern causes dominate, and neither existed when most PunchOut documentation was written: the browser refusing to frame your site (X-Frame-Options or a CSP frame-ancestors rule), and your session cookie being dropped because it lacks SameSite=None; Secure in a third-party frame.

Causes, most likely first

Ordered by how often each one turns out to be the culprit, not by how interesting it is. Work down the list.

  1. Your headers forbid framing

    How to confirm: Open the browser console during a punchout. A refused frame logs an explicit error naming X-Frame-Options or frame-ancestors. Many hosting platforms and security plugins set X-Frame-Options: SAMEORIGIN by default.

    Fix: Allow the buyer’s origin specifically via Content-Security-Policy frame-ancestors. Do not remove the protection entirely — allow the origins that need it.

  2. Cookies are dropped in the frame

    How to confirm: Your site loads inside the frame but behaves as though the shopper is not logged in, or loses the session on the first navigation. Browsers now block cookies without SameSite=None; Secure in third-party contexts.

    Fix: Set SameSite=None and Secure on the session cookie. This is the single most common cause of "it works when I open the URL directly but not from the buyer".

  3. The session URL has already been used

    How to confirm: Most implementations make the punchout session URL single-use. Reloading, or the buyer’s system prefetching it, consumes it before the shopper arrives.

    Fix: Decide deliberately whether the URL is single-use, and if so return a clear message rather than a blank page when it is reused.

  4. Mixed content

    How to confirm: The console reports blocked resources. An HTTP asset on an HTTPS page is blocked outright, which can leave a page that renders as blank.

    Fix: Serve every asset over HTTPS, including images referenced in catalogue data.

  5. A redirect loop

    How to confirm: The network tab shows the same URL repeating. Usually an authentication guard that does not recognise the punchout session and bounces to a login that bounces back.

    Fix: Ensure the punchout session satisfies whatever your normal auth guard checks, before that guard runs.

If it is not on your side

Ask the buyer whether their system opens punchout in an iframe, a new tab, or the same window. The answer changes which of the above applies, and it is a setting on their side you cannot see.

Check the document itself

Paste your cXML or OCI payload into our free tester. It runs entirely in your browser and reports the structural problems buyers reject on.

Open the tester

Related questions

It works when I paste the session URL into my browser. Why not for the buyer?

Because pasting it makes your site first-party. Inside the buyer’s frame it is third-party, and different cookie and framing rules apply. This specific symptom is almost always SameSite.

Is it safe to allow framing?

Allowing named origins through frame-ancestors is safe and is what the directive exists for. Removing the header altogether is not — that permits anyone to frame you, which is the clickjacking risk the header prevents.

Other failures

Rather not be the one debugging this?

We build and run the endpoint, and deal with the buyer’s technical team directly. Pricing is published in full.

See pricing Send us the error