B2B punchout and the buyers who never see your storefront

Strip away the procurement vocabulary and it is a delegated shopping session with a defined way of handing the basket back.

A buyer inside their employer’s procurement application picks your company from an approved supplier list. That application sends your system a PunchOutSetupRequest — a cXML document carrying credentials and the identity of the buyer. Your system replies with a PunchOutSetupResponse containing a StartPage URL, which the reference guide describes as the URL passed to the browser to begin the session, and which must “contain enough state information to bind to a session context on the remote website”.

The buyer’s browser opens that URL and they shop — in your catalogue, at their contracted prices, with their entitlements applied. When they finish, the basket comes back as a PunchOutOrderMessage. The transport detail is worth knowing because it surprises people: the guide is explicit that remote websites do not send this document directly to the procurement system. It is assigned to a hidden field on an HTML form, url-encoded, and posted by the buyer’s own browser to the address supplied in the BrowserFormPost element of the original setup request.

The cXML guide also sets out two things that get scoped as “phase two” and should not be. The StartPage URL “should be valid for only a limited amount of time”, because deactivating it is what stops unauthorised people reaching your session. And subsequent edit and inspect sessions are required, because — in the guide’s words — users cannot change order details for punchout items, such as quantity, within their procurement application; they have to re-punch-out with an edit session. A buyer who wants three instead of two is coming back to your site to do it.

It is tempting to read punchout as a preference and offer a nice login instead. It is not a preference. For the buyer it is policy: their organisation has decided that spend must pass through approval workflows, land against budget codes, and be visible for reporting before anything is committed. A corporate card on your checkout defeats all three, which is precisely why it is often disallowed.

The consequence is binary rather than gradual. A supplier without punchout is not a slightly less convenient supplier; they are a supplier whose products do not appear when the buyer searches their own system. You are not losing on price or service. You are absent.

That is also why the commercial case is easy to build and easy to overstate. It is worth asking, before anything is scoped, how many accounts are actually asking, what those accounts are worth annually, and whether they have a deadline — a procurement platform migration on their side is the usual trigger. Punchout built speculatively, for a buyer profile nobody has named, is an integration you will maintain for years with no traffic through it.

Shopify’s native B2B is genuinely good at the things it covers. The developer documentation describes a Company with CompanyLocation and CompanyContact records, catalogues assigned to locations for exclusive product selections and pricing, payment terms, draft orders for a contact to approve, and B2B order querying and import. Availability is plan-gated: Shopify states your plan must support B2B capabilities.

What that documentation does not contain is any reference to punchout, cXML, OCI or procurement platform connectivity. There is no setting to enable, and no first-party endpoint that speaks the protocol. So supporting punchout means something sits in front of Shopify and translates, whether that is an app from the ecosystem or a middleware layer you commission.

The good news is that the company model is the right foundation. Punchout’s central requirement — this buyer, from this organisation, sees this catalogue at these prices — maps directly onto a company location with a catalogue and a price list assigned to it. What the middleware adds is the protocol and the session, not a parallel pricing system. If anyone proposes a punchout build that maintains its own catalogue and prices alongside Shopify’s, that is two sources of truth and a contract dispute waiting to happen.

Identity mapping. The setup request identifies an organisation and a buyer in the procurement system’s vocabulary. Something has to resolve that to a Shopify company location, and to decide what happens when it cannot — a new site, a renamed entity, a buyer who has moved department. Failing open, by dropping the buyer into your ordinary retail storefront at retail prices, is the worst available outcome and the most common default.

Session isolation. Two buyers from two competing organisations may be punched out at the same time, each entitled to see a different catalogue and different prices. Contract pricing leaking between sessions is not a bug you disclose in a release note; it is a commercial incident. Test it explicitly, with concurrent sessions, as part of acceptance rather than as a later hardening pass.

Basket transfer fidelity. Every line returned has to carry what the procurement system needs to build a requisition: the buyer’s own part number where they use one, unit of measure, unit price, tax treatment, and a description their approver will recognise. This is where most projects lose time, because it is where your product data meets somebody else’s data model and the two disagree about units. A catalogue priced per pack and requisitioned per item will produce an approved purchase order for the wrong amount, and nothing in the flow will flag it.

The basket transfer is not an order. It becomes a requisition, which goes through approval — often more than one — and only then does a purchase order come back to you, by whatever channel you agreed. That can be hours later, and on larger accounts it is routinely days.

Three consequences follow, and every one of them is an operations decision rather than an engineering one. Prices may have moved between the basket and the purchase order, so you need a stated position on which price wins and a tolerance above which you query rather than accept. Stock was never committed, because nothing was ordered, so a punchout basket for the last six units guarantees nothing. And the purchase order may not match the basket, because an approver edited it, which means someone must reconcile rather than assume.

Decide all three before launch and write them into the trading terms. Discover them afterwards and they arrive as a series of individually small disputes with your largest customers, which is how punchout projects acquire a reputation for being more trouble than they are worth.

Punchout is not the only way into a procurement system, and it is the most expensive. A hosted catalogue — a priced product file loaded into the buyer’s system on a schedule — gets you visible and orderable without any session handling at all, and for a stable catalogue of a few hundred lines it is often sufficient. Ask the buyer whether their system supports it, because plenty do and nobody volunteers it. Punchout earns its cost when the catalogue is large, volatile, configurable or genuinely personalised per account, so that a static file is out of date the day it lands.

There is also a limit worth raising early with any punchout customer who buys consumables. Shopify states plainly that “B2B doesn’t support purchase options, such as subscriptions, pre-orders, and try before you buy.” So a buyer asking for a standing monthly order cannot be served by a native B2B selling plan, and the honest options are a reorder flow that makes repeating a basket trivial, a scheduled draft order created from your side, or a separate mechanism outside the B2B company model — the trade-offs of which we go through on [subscriptions and recurring ordering](/services/integrate/shopify-subscriptions-and-recharge). Promising replenishment on a punchout account without checking this is a common way to discover it at user acceptance testing.

The summary we would give before you spend anything: name the accounts, confirm which protocol their system speaks and whether a hosted catalogue would do, get the pricing and unit-of-measure model agreed in writing, and treat the purchase-order reconciliation as part of the project rather than as something finance will sort out. The protocol is the specified, documented, comparatively easy part. Everything around it is where these projects actually fail.

• Shopify subscriptions and recurring orders
• Price lists, quotes and net terms for B2B buyers
• Wholesale ordering: making a B2B buyer faster, not prettier