BigCommerce PunchOut

What moves between the procurement system and BigCommerce

A PunchOut connection on BigCommerce has the same flows as on any store. BigCommerce keeps the catalog, the prices and the orders; the PunchOut documents run in the integration.

Facts on this page were checked against BigCommerce's developer documentation and help center on October 3, 2026. The documents themselves are on cXML PunchOut and OCI PunchOut.

What BigCommerce offers and what is built around it

Signing the buyer in

The Customer Login API signs a customer in when the browser opens /login/token/{token}, where the token is a JWT signed with the API account's client secret. Its payload carries iss (the client ID), iat, a unique jti, operation customer_login, the store_hash, the customer_id and an optional redirect_to, the page to open after sign-in. Three rules from BigCommerce's documentation shape the PunchOut start:

1. The iat claim is valid for 30 seconds. The token cannot be put in the setup response, because the procurement system may open the start URL minutes later. The start URL points to the integration, which signs the token at the moment the browser arrives and redirects at once.
2. The access point URL works once. A refresh of the page, or a second tab with the same URL, gets no session.
3. BigCommerce keeps one active storefront session per customer account. A new sign-in, by any method, ends the other sessions of that customer.

The third rule decides the account structure. If the three buyers of Bakker Installatie B.V. share customer 57, a buyer who opens a PunchOut session at 09:03 is signed out when a colleague starts one at 09:10, and the first cart is no longer theirs. The integration creates one BigCommerce customer per person named in the setup request, all in the customer group of Bakker Installatie, so they share prices and keep their own sessions.

Prices per buying organization

A customer belongs to one customer group. On the Performance plan the group of Bakker Installatie gets a price list with item 10482 at 9.60 USD where the catalog price is 12.50; a variant the price list leaves out falls back to the catalog price. Price lists and group discounts cannot be combined on one group.

The price list is filled from the ERP. The batch endpoint takes up to 1,000 price records per call, so 4,000 contract prices for one buyer is 4,000 / 1,000 = 4 calls. For 40 buyers that is 160 calls. BigCommerce's rate-limit page gives the Plus and Standard plans 150 requests per 30 seconds, shared by every app on the store, so 160 calls take two windows, about a minute. BigCommerce's help center notes that pricing changes can take up to 10 minutes to show on the storefront. Price changes are therefore scheduled outside the buyer's working hours, so a buyer in a session does not see one price in the catalog and another in the order.

From the BigCommerce cart to the PunchOut cart

The checkout button is replaced by a transfer button in a PunchOut session. The theme reads the cart from GET /api/storefront/carts, which returns the line items with decimal prices. The cart of Bakker Installatie B.V., first line shown:

{
  "currency": { "code": "USD" },
  "isTaxIncluded": false,
  "cartAmount": 1468.75,
  "lineItems": {
    "physicalItems": [
      {
        "sku": "10482",
        "name": "Duplex receptacle 20 A, white",
        "quantity": 120,
        "listPrice": 9.6,
        "salePrice": 9.6,
        "extendedSalePrice": 1152
      }
    ]
  }
}

What the integration does with it:

1. salePrice becomes UnitPrice: 9.6 is written as 9.60. extendedSalePrice is the line value, 120 x 9.60 = 1,152.00.
2. isTaxIncluded false means the amounts exclude tax, as the cXML Total does: 1,152.00 + 298.00 + 18.75 = 1,468.75.
3. sku becomes SupplierPartID or NEW_ITEM-VENDORMAT. For a product with variants it is the variant SKU, which is the part number the buyer has to receive.
4. BigCommerce has no unit field. UnitOfMeasure and the classification come from product metafields, filled once per product.

The purchase order back into BigCommerce

The OrderRequest arrives at the integration, which answers it from its queue and creates the order with POST /v2/orders:

Each order costs a few calls of the store's quota, 150 per 30 seconds on Standard and Plus, and the quota is shared with every other app. When the store answers 429, the integration reads X-Rate-Limit-Time-Reset-Ms and retries after that wait; the procurement system already has its answer, so it never sees the delay. How backoff works is in API throttling and backoff.

When it goes wrong

The same pieces on other platforms: Shopify, Magento and WooCommerce. What a store needs in full is on the PunchOut hub. Tell us which procurement system your customer uses.