Punch-out Catalogue Integration UK: OCI and cXML

What punch-out is and why buyers ask for it

Large organisations don't let staff buy with a credit card on any website. Purchases go through a procurement system that enforces approvals, budgets and approved suppliers. Punch-out lets a buyer click your catalogue from inside that system, browse your live site with their own prices, fill a basket, and then send that basket back to the procurement system instead of checking out. Their approval workflow runs, and a purchase order is issued to you.

For suppliers to corporate, public sector or education buyers, punch-out is often a condition of staying on the approved list. We've built this before: our OCI-compliant VirtueMart for Joomla let large companies' procurement systems punch out to a Joomla shop. Today we build it for most ecommerce platforms and bespoke B2B portals.

OCI and cXML: the two main standards

OCI exists in versions 4.0 and 5.0, and buyers' SAP teams usually send a field list showing exactly what they expect, including unit of measure codes, material groups and vendor part numbers. We build to the buyer's specification rather than guessing.

How we build it

• Session handling: we authenticate the punch-out request, start a dedicated shop session for that buyer, and hide normal checkout so the only exit is "transfer basket".
• Customer rules: each buying organisation has its own credentials, shared secret, price list, product range and field mappings, managed from an admin screen.
• Field mapping: product codes, units of measure (UN/CEFACT codes are common), classification codes such as UNSPSC where requested, VAT and lead times mapped exactly.
• Order receipt: when the PO arrives, by cXML OrderRequest, email or EDI file, we parse it, match it to the original basket and create the order in your system, which can link into your ERP.
• Logging: every setup request, basket transfer and PO is logged so problems can be traced with the buyer's IT team.

Testing with the buyer

Punch-out projects involve the customer's procurement team as well as yours, so most of the elapsed time is coordination. We prepare a test environment, supply the URLs, identities and shared secrets the buyer needs, and work through their test scripts with them. Typical issues are mismatched units of measure, prices with too many decimal places, or classification codes the buyer's system rejects, and we fix those quickly because we built the mapping ourselves.

Once the first buyer is live, adding the next is usually configuration rather than code.

Sessions, iframes and security

Punch-out has some quirks ordinary ecommerce doesn't. Many procurement systems open the supplier site inside an iframe, which means your session cookie is a third-party cookie from the browser's point of view. We set cookies with SameSite=None; Secure where the buyer's system needs it, or pass a session token in the URL where browsers block third-party cookies entirely, and test in the browsers the buyer's staff actually use.

Each buying organisation has its own identity and shared secret, stored encrypted and rotatable. Punch-out sessions expire after a sensible period, payment steps are removed, and buyers can never see another organisation's prices. Every incoming request is checked against the expected sender, and we log enough detail to diagnose a failed transfer without storing more personal data than needed.

Platforms we work with

We add punch-out to WooCommerce, Magento, OpenCart, PrestaShop and bespoke B2B portals, and can build a dedicated punch-out catalogue alongside your main site if your platform makes it awkward. For trade portals in general see customer portal development and software for wholesalers. Every project is quoted at a fixed price after a free chat, once we've seen the buyer's specification. Get in touch.

What we deliver

• OCI punch-out endpoint with HOOK_URL return and NEW_ITEM field mapping
• cXML punch-out: PunchOutSetupRequest handling, session login and PunchOutOrderMessage
• Per-customer credentials, shared secrets and catalogue restrictions
• Contract pricing and product visibility per buying organisation
• Purchase order receipt (cXML OrderRequest or other formats) into your order system
• Test support with the buyer's procurement team through to go-live
• Admin screens to onboard new punch-out customers without code changes

How it works and what it costs

Every project gets a fixed-price quote after a free initial chat and a short scoping stage. You own the code and the data.

1. Free chat

   Tell us the problem in plain English: what you do now, what goes wrong and what "better" looks like. No charge, no obligation.

2. Scoping

   We map the processes, systems and data involved, agree what is in and out, and write it down so there are no surprises.

3. Fixed-price quote

   You get a fixed price for the agreed scope, or a phased plan for bigger builds, so you can start small and prove it works.

4. Build and test

   We build in short stages you can see and try, test against real data, then go live carefully with a rollback plan.

5. Hand over and look after

   You own the code and the data. We can host it, support it and keep improving it, or hand it to your own team.

Related