BigCommerce Integration – Feature & Process Guide

BigCommerce is a storefront platform connector, not a third-party marketplace like Amazon, eBay or TikTok Shop. There's no "listing onto someone else's marketplace" here — a BigCommerce store is the seller's own store, and Pentagon Connect pulls and pushes that seller's own catalog, orders and refunds to and from it. It behaves much more like our Shopify connector than like a marketplace integration: categories, brands, pricing, stock and order data all belong to the seller's own BigCommerce instance, and the seller (via Pentagon Connect) has full control over their own store's listings and orders.

A BigCommerce store is connected using credentials issued once from the store's own control panel and stored against the Pentagon Connect account from then on. A store can be set up as a Single Store or a Multi Store account, which changes how a new product goes live — see Product Management below.

Quick Reference

Product Management

Pricing & Stock

Orders & Fulfilment

Refunds, Returns, Cancellations & Claims

Product Management

Creating products

• Products are created one at a time; if a product has variants (e.g. size/colour), the whole variant group is created together in one step.
• Once a variant group exists on BigCommerce, no further variants can be added to it — the only way to add variants later is to delete the product and relist it from scratch.
• Variant options are limited to BigCommerce's own variant types (colour, size, etc.); of everything else recorded against the product, only the brand carries through onto a variant.
• Brand and category are checked against the store's own BigCommerce brand and category list before a product is sent — a brand or category that doesn't already exist in the store blocks that product from being created.
• On a Single Store account, a successful create publishes the product immediately. On a Multi Store account, a successful create only marks the product as created — it still needs a separate step to be assigned to the store's actual sales channels before it goes live.
• Only three conditions are accepted: New, Used, or Refurbished. Anything else is rejected before it's sent to BigCommerce.

Updating products

• Content, price and stock can each be updated once a product is live.
• Product images can't be changed through an update — they're only set when the product is first created.
• Protect Price and Protect Quantity stop those fields being overwritten by an update. If either is set on even one variant within a variant group, that field is protected for the whole group.
• Closing (deactivating) even one variant in a listing stops the update for the entire listing, since BigCommerce updates all variants in a group together.
• Custom name/value fields on the product are kept in sync automatically — added, updated or removed to match what's recorded in Pentagon Connect — without creating duplicate fields.
• Multi Store accounts get the same channel-assignment step as creation, but only after a successful update; if the update itself fails, that step is skipped.

Deactivating / removing products

• Closing a listing stops any further updates being sent for it.
• Deleting removes the product outright; deleting a single variant removes the entire variant group it belongs to, not just that one variant.
• Deleting a product that no longer exists on BigCommerce is silently skipped rather than raising an error, and a bulk delete of many products at once can partially succeed with no error surfaced for the ones that didn't go through.

Pricing & Stock Sync

• Price and stock keep in sync automatically once a product is live on BigCommerce.
• RRP-based discounting: if an RRP is set and it's higher than the current price, BigCommerce shows the item as discounted, with the RRP as the "was" price; if RRP isn't higher than price, only the standard price is sent.
• A store-level default weight is used for any product that doesn't have its own weight set.
• A product's shipping cost and free-shipping display come from whichever shipping option is assigned to it (or the store's default); if more than one option is configured, the highest-priced one is used, and if none is configured those fields are simply left blank.
• No rate limits are documented for how much or how often data can be pushed to a BigCommerce store.

Order Management

Getting orders

Orders are imported automatically and continuously — the first import looks back 90 days, and later runs pick up anything created or changed since the last check. Each order's line items, shipping address and any coupon (BigCommerce allows at most one per order) come in as part of the same import.

Order information we store

• Order ID, order status, currency and key dates
• Customer email
• Shipping address (name, company, full address)
• Discount detail — whether a discount came from a promotion, a coupon, or both, and the amount
• Per line item: product, quantity, price, and how much of that line has shipped or been refunded so far
• Gift-wrap cost, where applicable, worked out per unit

Order status is simplified into Pentagon Connect's own set (Pending, Ready for Shipping, Shipped, Partially Shipped, Cancelled). Orders that were abandoned at checkout and never completed are not imported at all. A couple of BigCommerce statuses (disputes and partial refunds) get extra handling rather than a simple one-to-one mapping, so the status shown may lag slightly behind BigCommerce's own label in those specific cases.

Shipping orders

Not documented. A large reference list mapping carrier names to the codes BigCommerce expects was found alongside the other order-management material, which strongly suggests tracking numbers and "mark as shipped" are supported — but the detailed shipping/consignment flow itself wasn't part of the source material reviewed for this guide. Treat shipping-flow questions as a gap to confirm against the live integration rather than something this guide can answer directly.

Cancellations

Not documented. No dedicated seller-triggered cancellation flow was found in the source material reviewed; cancelled and declined orders are reflected in the order status Pentagon Connect stores, but a distinct cancel action isn't covered here.

Refunds & returns

• Every refund is checked and quoted before anything is sent — if that check fails, the refund is never attempted, so an ineligible refund is stopped up front rather than erroring out at BigCommerce.
• Full refunds, and combined product-plus-shipping refunds, are supported.
• Partial refunds are supported by whole line quantity — refunding only some of the units on a multi-quantity line is not supported.
• Shipping refunds can only be for the full shipping amount, never a partial amount.
• Gift-wrap cost can be refunded as its own item, alongside a product or shipping refund.
• Whether a refund is recorded as processed "offline", and whether refunded amounts include tax, are both controlled by account-level settings rather than decided per refund.
• Only one refund per order is processed at a time — an order with two refunds queued needs a second pass to clear the second one.
• BigCommerce doesn't have a separate "return" concept — a return is handled the same way as any other refund.

Claims / incidents

Not applicable. BigCommerce has no buyer-initiated claims or incident mechanism to support — since this is the seller's own store rather than a marketplace, refund and cancellation decisions rest entirely with the seller (via Pentagon Connect), with no third-party operator role to raise or resolve a claim.

Carriers Supported

BigCommerce ships with a large built-in list of carrier codes (well over 500) that a tracking number can be matched against when marking an order shipped. However, since the shipping/consignment flow itself is not documented (see Shipping orders above), exactly how carrier matching behaves in practice — including what happens when a carrier isn't on the list — should be confirmed against the live integration rather than assumed from this guide.

Known Limitations

• No adding variants after creation — a variant set is locked once created; the product must be deleted and relisted to change it.
• No image updates — product images can only be set at creation, not changed afterwards.
• Condition is limited to New, Used, or Refurbished.
• No partial-quantity product refunds — only whole line quantities can be refunded.
• No partial shipping refunds — only the full shipping amount can be refunded.
• One refund per order per cycle — an order with multiple refunds queued clears them one at a time.
• One coupon per order is all BigCommerce allows.
• Bulk delete can partially succeed silently — invalid or already-missing product IDs are skipped with no error raised.
• Deleting one variant removes the whole variant group it belongs to.
• Multi Store accounts need an extra step after create/update to assign a product to sales channels before it's fully published.
• No documented rate limits for how much or how often data can be pushed to a store.
• Shipping/tracking flow and seller-triggered cancellations are not documented in the source material this guide was built from — treat both as open questions to confirm rather than assume unsupported.

Source Materials

This guide was built from Pentagon Connect's internal BigCommerce integration specifications covering authentication, product catalog management, order retrieval, and refunds.