OCI Punchout: Connect Procurement Portals to Your Shop

Punchout describes a simple but powerful mechanism: instead of loading articles and prices into the customer's procurement system as a static catalogue file, that system connects directly to your shop at runtime. The buyer works in their familiar procurement environment, clicks your supplier catalogue and is redirected into your shop via a session handoff. There they browse a current assortment with their conditions and send the finished cart back into their approval and ordering process in structured form. The term Punchout refers precisely to this passing from one system into the other and back again.

Two standards have established themselves for this handoff. The Open Catalog Interface, OCI for short, was developed by SAP and transfers cart data over HTTP using URL parameters and HTML form fields (SAP Open Catalog Interface). It is lean and widespread in SAP-centric purchasing systems. cXML, the Commerce eXtensible Markup Language, was published by Ariba in 1999 and exchanges the Punchout messages as validatable XML documents (cXML Reference Guide). Both achieve the same goal but differ in data format and scope. Which standard is required is dictated by your customer's procurement system, which is why a robust SAP integration should ideally master both routes.

The economic backdrop makes clear why the effort pays off. German B2B online trade via shops and marketplaces recently reached around EUR 476 billion and grew by 11.7 percent, considerably faster than consumer retail (Statista). Any wholesaler or manufacturer wanting to grow in this segment with large purchasing organizations can hardly avoid Punchout, because these customers' purchasing departments simply order from their own system and not through a separate shop login.

In many wholesale relationships, orders still arrive by fax, PDF attachment or an informal e-mail. Each of these orders has to be entered by hand on the receiving side: typing article numbers, checking quantities, reconciling prices, creating the order. This is slow, ties up staff and is error-prone. The BME reports that around 60 percent of companies name a lack of personnel and time resources as the biggest obstacle to digitalization (BME) - precisely the resources that manual order entry consumes. Digital procurement addresses this because ordering, approval and order creation mesh without media breaks.

The effect is measurable in the research. Almost all companies can simplify the ordering process through digitalization (95 percent), and 92 percent report easier communication with their business partners (Bitkom). At the same time, 53 percent admit they still have difficulties implementing digitalization (Bitkom) - the need is recognized, but the technical bridge is often missing. Punchout is one of these bridges: it turns your shop into the digital ordering channel for exactly those customers who still fax today. For topics such as creditworthiness and credit limits in the ordering process, see our article on the credit limit check in B2B checkout.

Technically, Punchout is a roundtrip in several steps that runs entirely over HTTP. It begins with the setup: the procurement system sends a request to your shop, authenticates and passes a so-called HOOK_URL to which the cart is later returned. Your shop then opens a session and answers with the start address of the catalogue. From there the buyer browses, assembles the cart and triggers checkout. On checkout, the cart is returned in structured form to the HOOK_URL, lands as a purchase requisition in the customer's approval workflow and, once released, becomes the actual order. This clean separation of catalogue session and actual order is a recurring pattern in API development for commerce.

The excerpt shows OCI's basic principle: the setup call passes user context and HOOK_URL, and the return happens as an HTML form with NEW_ITEM fields that the browser sends to the HOOK_URL. cXML solves the same flow via XML documents: a PunchOutSetupRequest to start, a PunchOutSetupResponse with the start address and a PunchOutOrderMessage for the cart. Because the handoff runs over HTTP and the buyer's session, authentication and securing the endpoints are central. How to harden such interfaces against attacks is covered in the article on NIS2-compliant hardening of ERP interfaces. Whether the roundtrip runs robustly is decided in practice by the middleware in between, which handles session, mapping and error handling.

OCI and cXML pursue the same goal but were designed from different angles. OCI is deliberately lean: HTML form fields and URL parameters suffice to return a cart. This makes the integration straightforward but reaches limits with very complex or configurable products, because the data model provides fewer fields (SAP Open Catalog Interface). cXML is document-based and richer: it knows formal XML schemas, supports server-to-server messages and, besides the catalogue roundtrip, can also transport the actual order as an OrderRequest (cXML Reference Guide).

In practice, the OCI-or-cXML question is rarely an either-or decision but depends on the specific customer. A large customer with SAP purchasing often expects OCI, a big purchasing organization on an e-procurement platform usually cXML. A viable integration therefore maps both protocols onto a common internal data model, so that each new customer becomes a configuration rather than a new build. You know this principle of a protocol-independent middle from the EDI integration via EDIFACT, which in B2B trade often runs alongside Punchout. For the structured order and document flow afterwards, the same SAP integration applies as for classic orders.

The real value of Punchout only emerges through customer-specific content. When the buyer jumps into your shop via handoff, they should not see the general web shop but exactly the assortment and prices their framework contract provides. This individualization decides whether Punchout is accepted as a serious procurement solution. The BME names real-time collaboration with suppliers as a decisive factor for more than 80 percent of purchasing leaders (BME), and it is precisely this closeness that an individual Punchout catalogue creates.

Price determination is the most demanding part. Customer-specific prices, tiers and time-limited conditions live in the ERP and must reach the catalogue with good performance. How to solve this with synchronization and caching is deepened in our article on customer-specific price synchronization in B2B. For the handed-over article numbers to match on both sides, you also need clean mapping between the customer key and the internal catalogue - a topic covered in detail by the article on data mapping between ERP and shop.

A Punchout integration is not a one-off project but an interface that wants ongoing maintenance. Each large customer brings its own requirements: a different protocol, deviating field mappings, own article numbers, specific cost-centre logic. That is why a robust solution places the entire Punchout logic in a middleware between procurement system and shop rather than in the shop itself. This layer receives setup requests, manages sessions, translates between OCI or cXML and the internal model and returns the cart correctly. The shop stays lean and the customer-specific complexity remains manageable in one place - an approach we pursue consistently in our integration services.

Servicing involves more than the initial build. Catalogues age, prices change, contracts expire and procurement systems update their Punchout profiles. A maintained interface monitors the sessions, logs failed returns and catches format deviations before they surface at the customer. Across more than 50 integration projects, ongoing maintenance - catalogue updates, price reconciliation, monitoring of handoffs - has proven to decide the success or frustration of a Punchout integration (project experience). Precisely this continuous care is the core of a wholesale integration that keeps customers in the purchasing system long term. Our references show the project approaches behind it.