If punchout is new territory, start with how punchout works; this page assumes you know the round trip and want to know which protocol your project actually needs. The short version: your buyers decide for you. Ariba, Coupa, Jaggaer, Oracle and Workday mean cXML. SAP SRM, S/4HANA and most of German-speaking Europe mean OCI. The long version is about what each choice commits you to.
Which protocol do you need?
- North American Enterprise (Ariba, Coupa, Oracle): You need cXML. Full 2-way round trip with electronic PO return is standard.
- European / DACH SAP Buyers (SRM, S/4HANA): You need OCI. Form-based cart return; verify the PO return path early with the buyer.
- Global Suppliers: You will inevitably need both. Running them from a unified catalog avoids data drift and duplicate infrastructure.
Two shapes of the same idea
cXML is document-based. Everything is a typed, validatable XML document: PunchOutSetupRequest to open a session, PunchOutOrderMessage to return the cart, OrderRequest to deliver the purchase order. Structure is the point: carts carry clean metadata like UNSPSC classifications, units of measure, tax data and cost centers, and both sides can validate what they receive. The price of structure is that you need real schema handling and real error handling, on both ends.
OCI is a form post. The buyer's ERP calls your catalog URL with a HOOK_URL return address; when the buyer is done, your side answers with an HTML form of NEW_ITEM fields that submits itself back. No schemas, no documents, no validation layer. It is quick to build and easy to read, and it gets strained exactly where structure would help: extra fields, custom data, anything beyond the standard list.
| Dimension | cXML (Commerce XML) | OCI (Open Catalog Interface) |
|---|---|---|
| Primary Architecture | Document-based XML exchange via HTTP POST | HTML form post via browser (HOOK_URL parameter) |
| Cart Transfer | PunchOutOrderMessage (cxml-urlencoded or cxml-base64) | Auto-submitting HTML form with indexed NEW_ITEM-* fields |
| PO Return Leg | Native cXML OrderRequest directly to connector endpoint | Cart only. PO arrives via separate channel (EDI, email, cXML, or manual) |
| Schema Validation | Strict DTD/XSD validation on both ends | None. Ad-hoc field names and string lengths |
| UNSPSC & Units | Mandatory UnitOfMeasure & Classification in XML elements | Optional NEW_ITEM-MATGROUP and NEW_ITEM-UNIT fields |
| Dominant Systems | SAP Ariba, Coupa, Jaggaer, Oracle, Workday | SAP SRM, SAP ERP (ECC / S/4HANA), DACH enterprise buyers |
| Common Gotchas | Missing UOM mapping (EA vs BX), auxiliary part ID stripping | Session lost in iframes (needs returntarget), credentials exposed in GET URLs |
The return leg is the real difference
cXML purchase orders are accepted durably, checked against the transferred cart and placed in the Purchase orders inbox in the PunchRelay app. Nothing is created in Shopify until someone on your team reviews the PO and clicks Create Shopify order. The order is then created unpaid, with payment pending, ready to fulfill. OCI returns a cart only; the purchase-order leg is agreed and tested separately for each buyer.
The OCI Return Leg Void
Because OCI specifies no return purchase order standard, many legacy punchout vendors stop at the cart transfer. The merchant is left manually keying orders from buyer emails or ERP printouts. In PunchRelay, cXML OrderRequest is native. OCI buyers who can send cXML purchase orders use the same path: the PO lands in your inbox, and your team creates the Shopify order.
Where each one bites in practice
The spec-level comparison misses what integration teams actually spend time on: per-buyer dialects.
- cXML cart transfer arrives as
cxml-urlencodedfor one buyer andcXML-base64for the next; each connection gets configured, not assumed. - cXML item lines require UnitOfMeasure and UNSPSC classification, neither of which exists in a typical commerce catalog; suppliers need a mapping layer (EA, BX, CS and friends) before the first test.
- cXML has no standard way for an OrderRequest to reference the punchout session that produced the cart; correlation rides in SupplierPartAuxiliaryID and depends on the buyer echoing it back. Buyers who strip it need their own correlation setup.
- OCI has no standard correlation field at all; OCI 4.0 offers NEW_ITEM-CUST_FIELD1 through 5, and whether the ERP preserves them must be verified per connection.
- SAP frequently embeds the punchout catalog in an iframe, so the transfer form must honor the
returntargetparameter or the cart gets stuck inside the frame. - OCI setup calls can arrive as HTTP GET, which puts credentials in the URL: logs need masking and buyers should be nudged toward POST. And after the cart transfer there is no acknowledgment, so your side never learns whether the ERP accepted the cart. Session logging matters twice as much for OCI because you only ever see one direction.
Geography, then both
North American enterprise buying runs overwhelmingly on cXML networks: Ariba, Coupa, Jaggaer, Oracle, Workday. In Europe, and especially in DACH, OCI is the de facto standard wherever SAP handles purchasing. A supplier selling on both continents, or a European supplier with one American buyer, ends up needing both protocols sooner than expected. That is the practical argument for handling cXML and OCI in one connector with one catalog, one contract-pricing source and one log view, instead of running two integration projects that drift apart.
PunchRelay does exactly that for Shopify stores: both protocols against the same Shopify B2B catalog, with the OCI purchase-order reality handled honestly. Start from the page that matches your buyer: Ariba, Coupa, or OCI for SAP.