Troubleshooting

The requisition was approved and no order reached you

The buyer confirms the requisition was approved and the order issued. Nothing arrived in your system, and your punchout is working perfectly.

Short answer

The cart and the order travel different routes. The cart came back through the shopper’s browser; the OrderRequest is a server-to-server POST to a separate endpoint that you may never have configured, because no amount of punchout testing exercises it. That is the first thing to check and usually the answer.

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. The order endpoint was never configured, or still points at test

    How to confirm: Punchout has always worked and no order has ever arrived. These are two separate configurations on the buyer’s side and going live with one does not go live with the other.

    Fix: Give the buyer the production order endpoint explicitly and ask them to confirm what is stored. Test both routes before go-live, not just the one the shopper touches.

  2. Your endpoint rejects their credentials and nobody is watching

    How to confirm: Search your access logs for 401s or 403s on the order endpoint. The buyer retried, failed, and gave up, and nothing in your application raised an alert because the request never got that far.

    Fix: Alert on authentication failures at the order endpoint specifically. A silent 401 on a route that should receive revenue is worth paging someone for.

  3. You dropped it as a duplicate

    How to confirm: The buyer’s log shows a successful transmission and you have no record. If the order carried a payloadID you had seen before, your own deduplication discarded it.

    Fix: Log deduplicated documents rather than discarding them silently, so that "we never received it" and "we received and ignored it" stay distinguishable.

  4. The buyer routes orders by another channel entirely

    How to confirm: They send POs by email or through a supplier portal and never enabled cXML order transmission, which is common when punchout was enabled by a catalogue team and ordering by a different one.

    Fix: Ask which channel the PO is issued on. This is a question, not an investigation, and it is worth asking before reading any logs.

  5. The order is held in an approval you cannot see

    How to confirm: The buyer says approved and means the requisition was approved, which is not the same as the order being issued. Budget checks and sourcing rules sit between the two.

    Fix: Ask for the purchase order number. If there is no PO number yet, there is no document to look for and nothing is wrong on your side.

If it is not on your side

Ask for the buyer’s transmission log for the specific PO number: whether a send was attempted, what response came back, and how many retries ran. Those three facts place the failure on one side or the other immediately, and nothing else does.

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

Do we need to acknowledge a cXML order?

Yes — an HTTP 200 carrying a cXML Status, returned quickly. Many platforms treat a slow acknowledgement as a failure and retry, so an endpoint that does the order processing before responding generates duplicates of its own making.

Can we poll for orders instead of receiving them?

Some platforms support it and most prefer you receive. If you cannot host a reliable endpoint, say so during setup — polling arranged up front is routine, and polling proposed after a month of lost orders is not.

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