The cart does not come back to the buyer
The shopper reaches your checkout, clicks the button that should send them back, and either nothing happens or they land in their procurement system with an empty requisition.
Check three things in this order: that you are posting to the BrowserFormPost URL from this session rather than a stored one, that the form field is named cxml-urlencoded, and that your PunchOutOrderMessage sits inside <Message> rather than <Request>. Between them those account for most cases.
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.
-
You stored the return URL instead of reading it per session
How to confirm: The BrowserFormPost URL arrives in every PunchOutSetupRequest and is session-specific. If you saved it during setup and reuse it, it works in testing and fails intermittently in production.
Fix: Read BrowserFormPost from each request and carry it through the session. Never persist it against the buyer.
-
The form field is not named cxml-urlencoded
How to confirm: The return is an HTML form POST with a single field containing the cXML document. The field name is fixed. A different name means the buyer receives a POST carrying nothing they can read.
Fix: Post a form with one field named exactly cxml-urlencoded whose value is the PunchOutOrderMessage.
-
PunchOutOrderMessage is in the wrong wrapper
How to confirm: PunchOutSetupRequest belongs in <Request>. PunchOutOrderMessage belongs in <Message>. Getting this the wrong way round produces a parse failure on the buyer side with an unhelpful message.
Fix: Move the payload into <Message>. Our free tester flags this specifically.
-
BuyerCookie is missing or changed
How to confirm: The BuyerCookie from the setup request must be echoed back byte for byte. If it differs, the buyer cannot attach the cart to the requisition that opened the session, and the result looks like nothing happened.
Fix: Store the BuyerCookie with the session and return it unmodified. Do not trim, re-encode or regenerate it.
-
The form never submits
How to confirm: A JavaScript error, a blocked popup, or a submit handler that returns false will stop the POST before it leaves the browser. The buyer sees nothing because nothing was sent.
Fix: Open the browser console during a test checkout. If the network tab shows no POST to the buyer domain, the problem is on your page, not in the cXML.
If it is not on your side
If the POST leaves your site and the buyer still reports nothing, capture the exact body you sent and the HTTP status you got back. A 200 with an error page in the body is common and is not a success.
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 testerRelated questions
Should the cart return open in the same window?
Follow whatever the buyer configured. Some systems punch out in the same tab, others in a new one or an iframe. Posting to the top-level window when the session opened in an iframe is a frequent cause of a return that appears to vanish.
Can I test the return without the buyer?
You can validate the document structure yourself, which catches most of what buyers reject. Paste it into our free tester. What you cannot test alone is whether their system accepts your credentials and matches the BuyerCookie.
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