cXML PunchOut Integrations for Ecommerce

SUMMARY: This guide explains cXML PunchOut integrations: what punchout catalogs are, how a punchout session works (with a real cXML example), the difference between Level 1 and Level 2 punchout, and what it takes to connect an ecommerce store to procurement systems like SAP Ariba, Coupa, Jaggaer, and Oracle Supplier Network. Sandcastle builds these integrations end to end, including cXML invoicing, with delivered implementations on nopCommerce and AbleCommerce.

What Is cXML PunchOut?

cXML (Commerce eXtensible Markup Language) is the protocol most procurement systems use to talk to supplier websites. PunchOut is the interaction it enables: a buyer working inside their procurement system clicks your catalog, “punches out” to your ecommerce store, shops your live catalog with their negotiated pricing, and returns the cart to their procurement system as a requisition. The purchase order then flows through their internal approval process and back to you.

For suppliers, punchout is usually not optional. When an enterprise, government, or university buyer adopts a procurement platform, they expect their suppliers to support it. Suppliers who cannot punch out get replaced by ones who can.

New to the concept? Start with our primer: What Is Punchout in Ecommerce?

What Is a PunchOut Catalog?

A punchout catalog is not a file you upload; it is your live ecommerce site, presented to procurement users as if it were a catalog inside their purchasing system. That distinction is what makes punchout better than static catalogs: your pricing, inventory, and product data stay current because buyers are looking at your actual store. The alternative, static CIF or spreadsheet catalog files, goes stale the day you export it.

A punchout catalog can also show buyer-specific contract pricing, restricted product sets, and custom configurations per customer, because your store knows which procurement account punched in.

How a PunchOut Session Works

Setup request: the buyer clicks your catalog in their procurement system, which posts a PunchOutSetupRequest to your store’s punchout endpoint. It authenticates with credentials in the cXML header and includes a BuyerCookie that identifies the session.
Store session: your store validates the credentials, creates a session for that buyer’s account with their pricing, and responds with a PunchOutSetupResponse containing the URL to send the user to.
Shopping and PunchBack: the buyer shops normally. At checkout, instead of paying, they return the cart, and your store posts it as a PunchOutOrderMessage back to their procurement system.
Purchase order: the requisition goes through the buyer’s approval workflow, and the resulting PO is sent to you, either as a cXML OrderRequest your store ingests automatically or through whatever channel you already use.

A minimal PunchOutSetupRequest looks like this:

<cXML payloadID="2026-07-28T10:00:00-08:00@buyer.example.com" timestamp="2026-07-28T10:00:00-08:00">
  <Header>
    <From><Credential domain="NetworkID"><Identity>AN01000000001</Identity></Credential></From>
    <To><Credential domain="DUNS"><Identity>123456789</Identity></Credential></To>
    <Sender>
      <Credential domain="NetworkID">
        <Identity>AN01000000001</Identity>
        <SharedSecret>********</SharedSecret>
      </Credential>
    </Sender>
  </Header>
  <Request>
    <PunchOutSetupRequest operation="create">
      <BuyerCookie>7b8c9d0e</BuyerCookie>
      <BrowserFormPost><URL>https://buyer-procurement.example.com/punchout/return</URL></BrowserFormPost>
    </PunchOutSetupRequest>
  </Request>
</cXML>

Your store’s job is to authenticate that request, map the buyer to the right account and pricing, and hold onto the BuyerCookie and return URL for the cart handoff.

Level 1 vs. Level 2 PunchOut

Level 1 is store-level: the buyer clicks your catalog and lands on your storefront or a landing page, then searches within your store.

Level 2 is product-level: your product data is indexed inside the procurement system itself, so buyers searching there see your items in their results and deep-link directly to the matching product page in your store. Level 2 requires supplying index files to the procurement network in addition to the punchout endpoints, and it significantly improves how often buyers find and buy your products.

Sandcastle has implemented both levels, and for suppliers with large catalogs we typically recommend planning for Level 2 from the start.

What is the difference between cXML and OCI punchout?

cXML and OCI are two different protocols for the same job: handing a buyer from their procurement system into your catalog and returning a cart. cXML came out of Ariba and is what SAP Ariba, Coupa, Jaggaer, and Oracle Supplier Network expect. OCI is SAP’s Open Catalog Interface, and it is what you meet when the buyer is punching out from SAP ERP itself.

The practical differences show up in three places. The setup request is a signed XML document in cXML and a simple form post of parameters in OCI. The session is carried in a cXML PunchOutSetupResponse versus OCI’s HOOK_URL. And the cart comes back as a cXML PunchOutOrderMessage versus an OCI form post of indexed fields.

None of it is hard once you have done it, but the two are not interchangeable, and a catalog built for one will not answer the other. We have delivered both.

Procurement Systems We Connect To

Punchout is a standard, but every procurement platform has its own setup process, test requirements, and quirks. We have connected supplier stores to systems and networks including:

SAP Ariba: the origin of cXML and the largest procurement network. Setup involves your Ariba Network account, punchout endpoint registration, and buyer-specific test rounds.
Oracle Supplier Network (OSN) and Oracle Procurement: punchout and document exchange for buyers running Oracle’s procurement stack.
Coupa: widely adopted in mid-market and enterprise purchasing, with its own supplier portal configuration.
Jaggaer: common in higher education, research, and public sector purchasing.
Others: most systems that speak cXML (and some that use OCI) follow the same pattern. If your buyer’s system supports punchout, we can connect to it.

The practical work is rarely the protocol; it is coordinating credentials, test environments, and certification rounds with each buyer’s procurement team. We handle that coordination as part of every integration.

Platform Implementations

Punchout is not a plugin you switch on; it has to hook into your store’s authentication, pricing, cart, and checkout. That is why we build it as a custom integration matched to your platform:

nopCommerce: we have designed and delivered punchout integrations for nopCommerce stores, including Southland Medical’s Coupa-connected store, covering punchout sessions, buyer-specific catalogs, cart return, and cXML order intake. See our nopCommerce development services and our deep dive on PunchOut for nopCommerce.
AbleCommerce: we have delivered punchout for AbleCommerce as well, and we are one of the few remaining agencies with deep AbleCommerce experience. For a platform-specific look, see PunchOut for WooCommerce and AbleCommerce.
Shopify, BigCommerce, WooCommerce: these platforms do not support punchout natively. We can implement it for stores on any of them using middleware endpoints that bridge cXML to the platform’s APIs.

What an Implementation Involves

Every project is different, but the shape is consistent:

Discovery: which procurement systems your buyers use, which punchout level they need, how orders should flow into your systems, and what buyer-specific pricing looks like.
Endpoint development: the punchout setup, session, and cart-return endpoints on your store, plus credential management for each buyer.
Order and invoice flow: how POs arrive, from fully automated cXML OrderRequest ingestion to email-based flows, and how confirmations and cXML invoices get back to the buyer.
Buyer testing and certification: each buyer’s procurement team runs test transactions before go-live. This coordination phase is where timelines are usually decided, and where having a partner who has done it before matters most.
Go-live and support: monitoring the first real transactions and supporting new buyer onboarding as more of your customers request punchout.

PunchOut vs. EDI

They solve different problems and often coexist. PunchOut handles the shopping experience: how a buyer browses your catalog and builds a cart from inside their procurement system. EDI, or cXML documents such as OrderRequest and InvoiceDetailRequest, handles document exchange: purchase orders, confirmations, and invoices. Many suppliers implement punchout for catalog access and automated documents for the order lifecycle. Sandcastle builds the complete cycle, including cXML invoice transactions, the final step of a punchout system.

Talk to a PunchOut Team That Has Done This Before

Sandcastle is a Seattle-based development team that builds custom cXML PunchOut integrations for B2B suppliers across the United States, from the first PunchOutSetupRequest to automated invoicing. If a customer has asked you to support SAP Ariba, Oracle Supplier Network, Coupa, Jaggaer, or another procurement system, we can tell you exactly what it will take. Explore our cXML PunchOut solutions or request a free project evaluation.

FAQ

What is cXML PunchOut?

cXML PunchOut is a protocol used for direct interaction between a buyer’s procurement system and a supplier’s e-commerce website. It allows users to “punch out” from their procurement system to the supplier’s catalog, select items, and then bring back the cart to their system to complete the purchase.

How does cXML PunchOut benefit my business?

cXML PunchOut streamlines the procurement process by automating order processing, ensuring up-to-date product information and pricing, reducing errors from manual entry, and providing a more efficient and user-friendly shopping experience.

Are cXML PunchOut integrations secure?

Yes, cXML PunchOut integrations are designed with security in mind, using encrypted communication and authentication to ensure that data exchanged between procurement and e-commerce systems is protected.

Can cXML PunchOut be integrated with any e-commerce platform?

Not all e-commerce platforms natively support cXML PunchOut, but many can be integrated using third-party applications or custom development. It’s important to check the compatibility or available extensions of your specific e-commerce platform.

How do I implement cXML PunchOut with my current procurement system?

To implement cXML PunchOut, you’ll need to coordinate with your e-commerce platform provider and procurement system for compatibility, possibly engage a third-party service for the integration, and then set up and test the connection thoroughly before going live. It often involves configuring user authentication, mapping product catalogs, and setting up communication protocols.

Is punchout the same as EDI?

No. PunchOut lets buyers shop your live catalog from inside their procurement system, while EDI exchanges business documents such as purchase orders and invoices. They complement each other, and many B2B suppliers need both. Sandcastle has implemented the full cycle, including cXML invoice transactions.

Do Shopify, BigCommerce, or WooCommerce support punchout natively?

No major SaaS ecommerce platform supports cXML punchout out of the box. It requires a custom integration that bridges the procurement system’s cXML messages to your platform’s APIs. That is exactly the work Sandcastle does.

How do you test a punchout connection?

Testing happens against the buyer’s procurement test environment: validating credentials, running setup requests, returning test carts, and confirming the requisition data arrives correctly. Most procurement teams require successful test rounds before enabling production access.

How long does a punchout integration take?

The development work is usually the predictable part. Overall timelines depend mostly on coordination with your buyer’s procurement team for credentials, test environment access, and certification rounds. We scope both parts honestly in a free project evaluation.