WooCommerce PunchOut

What moves between the procurement system and WooCommerce

A PunchOut connection on WooCommerce has the same flows as on any store. WooCommerce keeps the products, the stock and the orders; the PunchOut documents run in the integration.

Facts on this page were checked against the WooCommerce and WordPress developer documentation and source on October 3, 2026. The documents themselves are on cXML PunchOut and OCI PunchOut.

What WooCommerce offers and what is built around it

Signing the buyer in

WordPress signs a user in with wp_set_auth_cookie(). Called with $remember false, the cookie is a browser session cookie, and WordPress still ends the login after two days or when the browser closes, whichever comes first. With $remember true it lasts 14 days by default. A PunchOut sign-in uses the first: the session ends with the browser, and a link copied from it opens nothing a week later.

The plugin adds one route. The setup request for customer 10432 arrives at the integration, which stores the session with its return URL and BuyerCookie and answers with a start URL that carries a one-time identifier. The route checks the identifier, calls wp_set_auth_cookie() for the WordPress user linked to that session and opens the catalog.

Which user is linked matters more on WooCommerce than elsewhere. A signed-in user's cart is saved in the user meta _woocommerce_persistent_cart_ and follows that user to every device. Ten buyers at one customer on one shared WordPress account fill one cart between them. The integration links each PunchOut session to its own user, created from the UserEmail or Contact in the setup request when the buyer sends one.

WooCommerce's own session lasts 7 days for a signed-in user and 2 days for a guest, set in WC_Session_Handler. That is longer than SAP Ariba's six-hour PunchOut session, so the cart does not disappear on the store side during a session.

Prices per buying organization

WooCommerce core has one regular_price and one sale_price per product and no customer groups. A contract price per buyer comes from outside the product. The integration keeps a price table per buying organization, filled from the ERP, and the plugin sets that price on each cart line of a PunchOut session:

The product pages and the catalog show the same prices in the session, so the buyer never sees 12.50 and then 9.60 in the cart. Product data itself is written through the REST API's batch endpoints, which take up to 100 objects per request by default: 4,000 products is 4,000 / 100 = 40 requests.

From the WooCommerce cart to the PunchOut cart

The checkout button is replaced by a transfer button in a PunchOut session. The plugin reads the cart from the Store API, which returns the cart of the current session. A line of the cart of Bakker Installatie B.V., shortened:

{
  "sku": "10482",
  "name": "Duplex receptacle 20 A, white",
  "quantity": 120,
  "prices": {
    "price": "960",
    "currency_code": "USD",
    "currency_minor_unit": 2
  },
  "totals": { "line_total": "115200", "line_total_tax": "0" }
}

1. Prices are strings in minor units. With currency_minor_unit 2, "960" is 960 / 10^2 = 9.60 and "115200" is 1,152.00. Check: 120 x 9.60 = 1,152.00.
2. line_total excludes tax, which line_total_tax holds. The cXML Total excludes tax as well, so the line totals add up without correction: 1,152.00 + 298.00 + 18.75 = 1,468.75.
3. sku becomes SupplierPartID or NEW_ITEM-VENDORMAT. A variation without its own SKU has no part number for the buyer and is held back with an error in the log.
4. WooCommerce has no unit field. UnitOfMeasure and the classification come from product meta fields, filled once per product.

The Store API's rate limiting is off by default; when a store switches it on, it counts only POST requests, 25 per 10 seconds by default. Reading the cart is a GET and is not counted.

The purchase order back into WooCommerce

The OrderRequest arrives at the integration, which answers it and creates the order with POST /wp-json/wc/v3/orders. WooCommerce's built-in offline gateways, bank transfer (bacs), cheque and cash on delivery, carry no PO number. The order is created with set_paid false and the PO number goes into meta_data:

set_paid true would set the order to processing and reduce stock as if it were paid. A PunchOut order is on account, so the integration leaves it false and the order status follows the ERP. The reply to the procurement system comes from the integration's queue, not from WordPress, so a slow WordPress host does not turn into a timeout at the buyer.

When it goes wrong

The same pieces on other platforms: Shopify, Magento and BigCommerce. What a store needs in full is on the PunchOut hub, and how amounts in minor units and tax travel between systems is on money, tax and rounding. Tell us which procurement system your customer uses.