PunchOut Catalog Integration for Shopify B2B

A PunchOut catalog is a supplier webstore that a buyer reaches from inside their own procurement system rather than from their browser. The buyer is in Ariba, Coupa, Jaggaer or SAP, clicks your name in their supplier list, and lands in an authenticated session on your storefront — already identified, already priced at their contract rates. They build a cart, click a return button, and the cart is transferred back into their procurement system as a requisition. Approval happens there, and a purchase order comes back to you. The buyer never leaves their procurement workflow, and you never have to maintain a static price file inside their system. That last part is the reason PunchOut exists: hosted catalogs go stale the day you upload them, while a PunchOut session reads live pricing and live stock every time.

They are the two dominant PunchOut protocols and they solve the same problem differently. cXML — commerce eXtensible Markup Language, originated by Ariba — is XML-based: the procurement system sends a PunchOutSetupRequest containing credentials and a return URL, your endpoint answers with a PunchOutSetupResponse carrying a session start URL, and the finished cart goes back as a PunchOutOrderMessage. It is what Ariba, Coupa and Jaggaer speak natively. OCI — Open Catalog Interface, SAP’s standard — is simpler and older: the handshake is an HTTP call with URL parameters, and the cart returns as an HTML form POST of named fields rather than a structured document. Neither is harder to build than the other, but they are not interchangeable, and a supplier serving both a Coupa buyer and an SAP buyer needs both endpoints. Scope which of your customers use which before you build anything.

No, and it is worth being direct about that. Shopify Plus has excellent native B2B — company accounts, catalogs, price lists, payment terms, B2B checkout — but it does not ship a cXML or OCI endpoint, and there is no setting to turn one on. PunchOut on Shopify is a middleware pattern: a service that terminates the procurement system’s handshake, authenticates the session, maps the buyer to the right Shopify company and catalog, hands them into the storefront, and serializes the returned cart back into cXML or OCI. Shopify’s native B2B objects are what make this tractable rather than painful — the company, catalog and price list model maps almost directly onto what a PunchOut session needs to expose. The middleware supplies the protocol; Shopify supplies the commerce.

Plan 8 to 14 weeks for a first PunchOut endpoint, and expect the calendar rather than the code to set the pace. The build itself — handshake, session authentication, catalog scoping, cart serialization — is well-defined work. What extends the timeline is certification: each buyer’s procurement team has to test the connection in their own sandbox, and their availability, not yours, decides when that happens. Ariba and Coupa both run supplier enablement processes with their own queues. Additional buyers on the same protocol are much faster afterwards, usually two to four weeks, because the endpoint already exists and only the credentials, catalog scope and pricing mapping change. Budget the first one honestly and the rest get cheap.

Four things a DTC-grade storefront has no reason to carry. Contract pricing, resolved per buying organisation at session time rather than at page-cache time. Catalog scoping, so a buyer only sees the SKUs their agreement covers — procurement teams treat an out-of-contract item in the cart as a compliance failure, not a browsing convenience. Classification codes, usually UNSPSC, because the requisition and the spend analytics on the buyer’s side are built on them. And a unit-of-measure model that survives the round trip, since procurement systems reason in the buyer’s purchase units, not your selling units. Get any of those wrong and the cart returns, but the requisition fails validation — which is the failure mode that costs the most to debug because it happens on someone else’s system.

The cart becomes a requisition, goes through the buyer’s approval chain, and comes back to you as a purchase order — and that PO is a separate integration, not part of PunchOut. Most enterprise buyers send it as cXML OrderRequest or as EDI 850, and expect an acknowledgement in return. From there the same relationship usually wants EDI 855 for order confirmation, 856 for advance ship notice, and 810 for invoicing. Teams often scope PunchOut on its own, ship it, and then discover that the buyer will not go live until the PO channel exists too. Scope both from the start even if you build them in sequence.

Hosted catalogs — a price file uploaded into the buyer’s system — are cheaper to start and worse to live with. Every price change and every product addition becomes a file exchange, stock is never represented, and configurable or made-to-order items cannot be expressed at all. They make sense for a short, stable, low-SKU line. PunchOut earns its cost when your catalog moves, when pricing is negotiated per account, when stock matters to the buying decision, or when the buyer wants search and comparison rather than a spreadsheet. The honest test: if you would be embarrassed by how stale your hosted file is three months after upload, you need PunchOut.