Troubleshooting

The PunchOut session times out

The shopper is dropped mid-session, sent back to a login, or finds their basket empty after browsing for a few minutes.

Short answer

Before increasing the timeout, check session affinity. If you run more than one application server without sticky sessions or shared session storage, the shopper is silently switching between servers that do not know about each other — which looks exactly like an expiry and is not one.

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. No session affinity across servers

    How to confirm: The failure is intermittent and unrelated to elapsed time. Longer sessions do not help. Under load it gets worse.

    Fix: Use shared session storage rather than sticky routing where you can. Sticky sessions solve it until an instance recycles.

  2. The session cookie is being dropped in the frame

    How to confirm: Every navigation looks like a new session. This is the same third-party cookie problem that produces a blank page, presenting differently.

    Fix: Set SameSite=None; Secure on the session cookie.

  3. The punchout URL is single-use and got reused

    How to confirm: The shopper used the browser back button, or their system prefetched the link.

    Fix: Decide whether the URL is single-use. If it is, return an explanatory page rather than an expiry error.

  4. The timeout is genuinely too short

    How to confirm: The failure tracks elapsed time reliably. A buyer assembling a large requisition can easily browse for half an hour.

    Fix: Allow at least an hour of inactivity for a punchout session. These are not consumer checkouts and the shopper is often interrupted.

  5. The buyer’s system has its own timeout

    How to confirm: Your session is alive and their requisition has expired. The cart returns and has nowhere to go.

    Fix: Nothing you can change. Worth knowing so you stop looking on your side.

If it is not on your side

Capture whether the failure correlates with elapsed time or with number of page views. That single observation separates a real timeout from a session-affinity problem, and it is the first thing a competent engineer on either side will ask.

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

How long should a punchout session last?

An hour of inactivity is a reasonable floor. Procurement shopping is interrupted constantly, and a shopper who loses a fifty-line basket to a timeout will not rebuild it.

Should we warn before expiring?

Yes, and it is cheap to add. A warning with an extend option turns a lost basket into a mild annoyance.

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