What is a punchout catalog?

A punchout catalog is a supplier web shop opened from inside a buyer’s procurement system. The buyer shops with the supplier’s search, configuration and contract prices, then returns the cart to the procurement system, where it becomes a requisition, goes through approval and is sent back to the supplier as a purchase order.

What is the difference between cXML punchout and SAP OCI?

cXML punchout uses XML documents: a server-to-server setup request and response, then a cart returned as a PunchOutOrderMessage through the browser. SAP OCI uses HTML forms: the catalog is called with URL or form parameters and the cart returns as hidden NEW_ITEM fields. cXML also covers orders and invoices; OCI covers only shopping.

Secure OCI is a variant described in SAP’s OCI 5.0 specification where the procurement system first calls the catalog backend server to server to initialize a session, receiving a session id, and the browser launch then carries only that session id instead of the user name and password.

What does a supplier need to implement for cXML punchout?

A setup endpoint that authenticates the sender, stores the request under a short-lived session id and returns a StartPage URL; a shop session bound to that request; a cart return that posts a PunchOutOrderMessage with the original BuyerCookie; hardened XML parsing; proper status codes; and an order endpoint that accepts the later OrderRequest.

Should a B2B shop build punchout itself or use a gateway?

Use a gateway when many buyers on different procurement systems need connecting quickly, or when certification and support matter more than cost. Build when you have a few large buyers on known systems and an engineering team that can own XML security, testing and per-buyer quirks. Compare against published gateway pricing.

Punchout catalogs: cXML and SAP OCI

A punchout catalog is a supplier’s web shop opened from inside a buyer’s procurement system. The buyer uses the supplier’s search, configuration and contract prices, then sends the cart back to their own system, where it becomes a requisition, goes through approval and returns to the supplier as a purchase order. Buying happens in the shop; control, budgets and approvals stay with the buyer.

This article explains the two protocols that carry this round trip, cXML PunchOut and SAP’s Open Catalog Interface, including Secure OCI, what a supplier shop has to implement and harden, who asks for punchout, what a gateway costs compared with building it, when punchout is the wrong tool, and a go-live checklist.

What problem does punchout solve?

It lets large buyers keep their purchasing rules while using the supplier’s shop. Procurement departments want every purchase to pass through their own system for budgets, cost centers and approvals, but they do not want to maintain the supplier’s catalog, configurator and contract prices themselves. Punchout splits the job: the supplier runs the shopping experience, the buyer’s system owns the decision.

That is why punchout often appears as a contract condition in enterprise and public-sector deals. For the supplier it changes what “done” means: the shop is no longer the end of the purchase, it is a stop in the middle of someone else’s process, and every line in the returned cart has to be something the buyer’s ERP can post.

How does the cXML PunchOut round trip work?

Three cXML messages carry it: a PunchOutSetupRequest and its response open the session server to server, and a PunchOutOrderMessage brings the cart back through the shopper’s browser. cXML is maintained at cxml.org, current version 1.2.071 as of August 2026, and also covers catalogs, orders, confirmations, ship notices and invoices (cXML.org).

The cXML PunchOut round trip: the cart comes back through the shopper’s browser as a quote, and the purchase order arrives later as a separate OrderRequest after the buyer’s approval.

<cXML payloadID="1760600000.4711@buyer.example" timestamp="2026-10-08T09:12:00+02:00">
  <Header>
    <From><Credential domain="NetworkID"><Identity>BUYER-123</Identity></Credential></From>
    <To><Credential domain="DUNS"><Identity>SUPPLIER-456</Identity></Credential></To>
    <Sender>
      <Credential domain="NetworkID">
        <Identity>BUYER-123</Identity>
        <SharedSecret>…</SharedSecret>
      </Credential>
      <UserAgent>Procurement 2026</UserAgent>
    </Sender>
  </Header>
  <Request>
    <PunchOutSetupRequest operation="create">
      <BuyerCookie>8f3c1a…</BuyerCookie>
      <Extrinsic name="UserEmail">p.huber@buyer.example</Extrinsic>
      <BrowserFormPost><URL>https://procurement.buyer.example/punchout/return</URL></BrowserFormPost>
    </PunchOutSetupRequest>
  </Request>
</cXML>

Setup request: carries operation="create", inspect or edit, a BuyerCookie the buyer uses to match the returned cart to the user, and the BrowserFormPost URL where the cart must go; user details arrive as Extrinsic elements or a Contact, and vary per procurement system (PunchOutCommerce).
Setup response: a Status of 200 and a StartPage URL that logs the shopper in. A sound pattern is to store the request under a random session id, validate it when the shopper arrives, and expire unused ids after about five minutes.
Cart return: an HTML form posted by the browser to the BrowserFormPost URL with the cXML in a hidden field named cXML-urlencoded. The PunchOutOrderMessage must echo the BuyerCookie, and each ItemIn carries quantity, SupplierPartID, unit price, description and unit of measure (PunchOutCommerce).

Two details cause most production bugs. The returned cart is a quote, not an order; the real order arrives later as a cXML OrderRequest, and the SupplierPartAuxiliaryID you put on each line must come back on that order unchanged, because it is often the only link to a configured item or a contract price. And the BuyerCookie is not authentication: it passes through the supplier, so buyers should not trust it alone on return, and suppliers must never put secrets in it.

How does SAP OCI work, plain and secure?

OCI is an HTML-form protocol: SAP launches the catalog URL with parameters, and the catalog returns the cart as hidden form fields posted to a return address. The launch typically carries USERNAME and PASSWORD, the required HOOK_URL where the cart must go, and ~TARGET for the form target in framed sessions; credentials belong in a POST body, because a GET exposes them in URLs and logs (PunchOutCommerce).

The OCI RoundTrip: credentials and the return address travel as form parameters, and the cart returns as hidden fields; Secure OCI replaces the credentials with a server-issued session id.

<form method="post" action="{HOOK_URL from the launch request}" target="{~TARGET}">
  <input type="hidden" name="NEW_ITEM-DESCRIPTION[1]" value="Cable gland M20x1.5 IP68">
  <input type="hidden" name="NEW_ITEM-QUANTITY[1]"    value="50">
  <input type="hidden" name="NEW_ITEM-UNIT[1]"        value="PCE">
  <input type="hidden" name="NEW_ITEM-PRICE[1]"       value="1.84">
  <input type="hidden" name="NEW_ITEM-CURRENCY[1]"    value="EUR">
  <input type="hidden" name="NEW_ITEM-VENDORMAT[1]"   value="70.112.04">
  <button type="submit">Transfer cart</button>
</form>

Fields are named NEW_ITEM-*, such as DESCRIPTION, QUANTITY, UNIT, PRICE, CURRENCY, VENDORMAT and MANUFACTMAT, limited to 255 characters each, with custom fields up to 1,000 according to Unite’s technical documentation (Mercateo/Unite). The scope matters: the OCI RoundTrip covers only catalog and shopping. Electronic orders, confirmations, ship notices and invoices are not part of the specification and travel over other channels such as IDocs or EDI.

Secure OCI removes credentials from the browser. In SAP’s OCI 5.0 specification, the procurement system first calls the catalog backend server to server, using parameters such as SECURE_AUTH_URL and the function INITIALIZE, which returns a SessionId and a SessionTransmissionId; the browser launch then carries only the session id (SAP OCI 5.0). Two caveats: OCI 5.0 is a 2012 SRM document and the latest SAP OCI specification found, and current S/4HANA documentation for the Plant Maintenance catalog scenario still says it supports only OCI 3.0 and below (SAP Help). Ask each buyer which version their system calls.

Aspect	cXML PunchOut	OCI RoundTrip	Secure OCI
Transport	XML over HTTPS, server to server, then browser	HTML forms through the browser	server-to-server init, then browser
Authentication	shared secret or certificate in the header	USERNAME, PASSWORD parameters	session id from INITIALIZE
Cart return	PunchOutOrderMessage in a hidden field	hidden NEW_ITEM-* fields	hidden NEW_ITEM-* fields
Orders, invoices	covered by cXML	not covered	not covered
Typical buyers	SAP Ariba, Coupa, Jaggaer, Oracle	SAP SRM and S/4HANA	SAP systems on OCI 5.0

What must the supplier shop implement?

A setup endpoint, a session that is bound to the setup request, a cart return in both formats if you serve both kinds of buyers, an order endpoint for cXML, and the discipline around them: validation, error codes, logging and data quality. Most of the work is in the details buyers notice only when they fail.

Status codes: answer 400 for a missing or unparsable body, 401 for an invalid sender or shared secret, and 500 for unhandled errors, as a cXML Status element.
Session binding: one setup request, one session, short expiry, and the BuyerCookie stored server side so the cart returns to the right requisition.
Identifiers: unique payloadIDs on every message, and SupplierPartAuxiliaryID or VENDORMAT values that your order import can resolve later.
Item data quality: units of measure, classification codes and contract SKUs that the buyer’s ERP accepts. A line the ERP cannot post becomes a support call.
Logging: keep every inbound and outbound document per session, so a failed requisition can be replayed and explained.

In more than ten years of B2B commerce and PIM work with Spryker and Pimcore, I have found that punchout turns catalog data quality, units, part numbers, contract SKUs and classification codes, into a failure the customer sees inside their own ERP. It is as much a PIM conversation as a protocol one; the data side is covered in the Pimcore ERP delta sync. Configured products are a common punchout use case too, and the configurator rules are their own problem, see headless product configurators for B2B.

Who asks for punchout?

Enterprise buyers on SAP Ariba, Coupa, Jaggaer or Oracle procurement, SAP customers with SRM or S/4HANA catalogs, and public-sector buyers through marketplaces. Amazon Business is a useful indicator of how standard this is: it integrates with more than 200 e-procurement systems, describes punchout as typically the first integration, and runs both cXML and OCI endpoints (Amazon Business).

Its supplier-facing rules are a good model for your own: a user email is mandatory in the setup request, the returned Supplier Part Auxiliary ID must come back on the purchase order, payload IDs must be unique, only new orders are supported, and orders run in a test mode before going live (Amazon Business integration guide). “Level 2” punchout, where the buyer’s system holds a searchable index of your items and the setup request lands the shopper directly on a product page, is Ariba and marketplace terminology rather than part of the OCI specification.

Should you build punchout or buy a gateway?

Buy when you need many buyers on many procurement systems quickly; build when you have a few large buyers on known systems and a team that can own the protocol. A gateway sells pre-built connections and the per-buyer quirks. TradeCentric, formerly PunchOut2Go, publishes supplier pricing starting at $15,000 to $50,000 a year for its mid-market tier with a minimum three-year contract, enterprise by quote, and claims more than 220 ERP and e-procurement integrations as of October 2026 (TradeCentric).

A do-it-yourself layer honestly requires a setup endpoint per protocol, session handling, cart serialization in two formats, an order importer, hardened XML parsing, per-buyer test accounts, and someone who answers when a buyer’s procurement team changes a field mapping. Compare that ongoing ownership with the gateway price for the number of buyers you expect in three years, not this year.

Whichever way you choose, keep the protocol layer separate from the shop core. The shop should expose a clean internal API for “start a session for this buyer user”, “serialize this cart” and “import this order”, and the cXML or OCI adapters, or the gateway, should sit outside it. That keeps a change in one buyer’s procurement system from reaching your checkout code, and it makes a later switch between building and buying a contained project rather than a rewrite.

When is punchout the wrong tool?

When the buyer only needs your items and prices inside their system, a hosted catalog file may be enough; when you already exchange orders with a known partner, an API or EDI link is simpler. Punchout is a session and user-experience protocol, not a data model, so it does not fix product data and adds a browser step that has to work in the buyer’s environment, including framed sessions and their cookie behavior in current browsers.

Agent protocols are the other boundary. UCP, ACP and AP2 assume a software agent buying on someone’s behalf, with different payloads and governance; punchout assumes a person in the buyer’s ERP. Both can coexist, and the comparison is in the UCP, ACP and AP2 guide and in agentic commerce readiness for B2B shops, which treats punchout as the supported enterprise path today.

A punchout go-live checklist

Get a test account in the buyer’s procurement system and per-buyer credentials.
Collect sample payloads for create, edit and inspect, and for every buyer-specific Extrinsic.
Test the cart return end to end in a real browser; I script this round trip with Playwright MCP, because the browser form post is the part unit tests cannot cover.
Verify that SupplierPartAuxiliaryID or VENDORMAT survives into the purchase order and your order import.
Run failure drills: wrong shared secret, expired session, malformed XML, a DOCTYPE in the payload.
Monitor setup latency, cart-return failures and orders that reference unknown items.
Finish with a buyer acceptance test that posts a real requisition through approval.

If you are adding punchout to a B2B shop or deciding between a gateway and your own layer, see my B2B e-commerce work.

Punchout catalogs explained: cXML, SAP OCI and the round trip to the buyer’s ERP

Key takeaways