This article describes the known limitations of the BigCommerce integration. These are inherent to the current design of the integration and to the capabilities of the BigCommerce API, and they apply to all subscribers.

Because the integration spans many record types, the limitations are organized by feature. Each feature section opens with a Related mapping documentation line linking that feature's mapping documentation so you can go straight from a limitation to the collection it concerns. One behavior — how updates are written back to BigCommerce — applies across every collection that writes to BigCommerce, so it is described first. A consolidated Placeholder Values to Replace Before Go-Live checklist appears at the end of this article: the single pre-launch list of example values each subscriber must replace.

Except where a specific date is stated, every limitation below describes the integration's behavior at the time this documentation was written.

This behavior applies to every collection that writes to BigCommerce (the FROM iPaaS.com collections — products, variants, inventory, categories, gift cards, shipments, B2B companies and users, and transactions).

When the integration updates a record in BigCommerce, it writes the full record, not just the fields that changed. Any field you do not map is written as empty and can overwrite a value that already exists in BigCommerce on each transfer. iPaaS.com is therefore the source of truth for every field on a record it writes.

What this means for you: map every field you want preserved on the records the integration writes to BigCommerce. For fields you do not source from iPaaS.com but still want to keep, use a DestinationValue approach so the existing BigCommerce value is carried forward instead of being blanked. Validate an update round trip in a staging environment before go-live to confirm nothing you rely on is being cleared. This behavior is accurate at the time this documentation was written.

Related mapping documentation: BigCommerce Order Mapping Documentation and BigCommerce Transaction (write-back) Mapping Documentation. The field-level requirements for each collection are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

An order transfers to iPaaS.com only when it is in an eligible state: it is not Incomplete, Pending, or Manual Verification Required; it is not a refund; it is not a deposit-ticket or gift-card-ticket clone (the -D and -GC order-ID suffixes); and it is not a quote-originated order. Orders that do not meet these conditions are handled by their own collections (refunds, tickets, and B2B quotes) or are skipped until they reach an eligible status.

What this means for you: an order you expect to see in iPaaS.com may not have transferred because it is still in a pre-completion status or because it is a refund, ticket, or quote that another collection owns. Review each collection's filter against your business rules, and coordinate the filters so a given order state is claimed by exactly one collection — enabling overlapping collections without coordinated filters can create duplicate or conflicting records. This behavior is accurate at the time this documentation was written.

Orders paid with the Clover Payment method are not processed by the standard Update BigCommerce Order TO iPaaS.com collection.

What this means for you: if you take Clover payments and need those order updates in iPaaS.com, review this exclusion with your implementation partner or MiSP before relying on the standard order-update flow. The Clover Payment label used in the filter is an example value — see the placeholder checklist. This behavior is accurate at the time this documentation was written.

The order shipping-address collection captures one shipping address per order.

What this means for you: if your store ships a single order to multiple destinations, validate the behavior in a staging environment before relying on this collection in production, and discuss multi-destination handling with your implementation partner or MiSP. This behavior is accurate at the time this documentation was written.

BigCommerce holds a single staff note per order, so the staff-note collection maps one note record with a fixed sequence number; customer and staff notes are handled by separate collections. Notes captured from an order are readable by anyone with iPaaS.com access.

What this means for you: expect at most one staff note per order to carry across, and be aware of note visibility before mapping notes that contain sensitive content. This behavior is accurate at the time this documentation was written.

Automatic (non-coupon) promotions do not carry a coupon code, so the CouponCode field can be empty on discounts that originate from an automatic promotion rather than from a coupon.

What this means for you: treat an empty coupon code on an automatic-promotion discount as expected, not as missing data. This behavior is accurate at the time this documentation was written.

The transaction write-back collections (Transaction Add / Update FROM iPaaS.com, and their billing-address and line children) send iPaaS.com order data back to BigCommerce. As delivered, their mapping filter is pinned to an always-false condition, so they process no records until the filter is updated. In addition, importing or updating shipping addresses and shipping methods on BigCommerce is not supported by these collections; only the billing address is written.

What this means for you: if you want iPaaS.com to create or update BigCommerce orders, update the filter on the transaction write-back collections to select the records you intend to send, and plan around the fact that shipping addresses and methods are not written. Because these are BigCommerce writes, the Unmapped Field Overwrite Risk described above applies — map every field you want preserved. Validate the flow in a staging environment before relying on it in production. This behavior is accurate at the time this documentation was written.

Related mapping documentation: BigCommerce Order Payment Mapping Documentation, BigCommerce Refund Mapping Documentation, and BigCommerce Deposit Ticket and Gift Card Ticket Mapping Documentation. The field-level requirements for each collection are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

The data BigCommerce returns differs by payment type, so order, refund, and ticket payments are split across gateway-specific child collections — for orders and tickets: Credit Card / Apple Pay, PayPal, Gift Card, Check, and Test Payment Gateway; for refunds: Credit Card, PayPal, Check, and Test Payment Gateway. If a transaction uses a payment type not covered by the supplied collections, an additional payment sub-collection may be needed.

What this means for you: if you accept a payment type that is not one of the ones listed above, review it with your implementation partner or MiSP to confirm whether a separate payment sub-collection is required before you rely on that payment data in production. This behavior is accurate at the time this documentation was written.

Payments taken through the test payment gateway are recorded with a payment method of Other rather than a specific payment brand.

What this means for you: if you need a more specific method recorded for test-gateway payments, customize the mapping and validate it in a staging environment. This is a design choice for the shipped mapping, not a defect, and is accurate at the time this documentation was written.

When an order includes gift-card sales, the gift-card portion is recorded on a separate gift-card ticket and is deducted from the order's other payment amounts and from deposit-ticket subtotals and totals.

What this means for you: expect the gift-card portion of a mixed order to appear on the gift-card ticket rather than on the order's other payment records. This keeps the ticket totals consistent with how your accounting system consumes them. This behavior is accurate at the time this documentation was written.

Deposit tickets and gift-card tickets are cloned order records (the -D and -GC order-ID suffixes) designed to be sent onward to an ERP or accounting system. If your destination system does not use tickets, or your business does not sell gift cards in BigCommerce, these collections and their children can be removed.

What this means for you: keep the ticket collections only if a downstream accounting system consumes them; otherwise remove them to avoid processing records you do not need. Several ticket mappings should be reviewed to confirm they are configured for your B2B and/or B2C order flows before you rely on them in production. This behavior is accurate at the time this documentation was written.

The gift-card-ticket Credit Card, Check, and Test Payment Gateway payment collections create the payment record but do not update an existing payment.

What this means for you: treat these payment records as created once with the ticket; later changes to the payment are not re-written by these collections. This behavior is accurate at the time this documentation was written.

Related mapping documentation: BigCommerce Product Mapping Documentation, BigCommerce Product Variant Mapping Documentation, and BigCommerce Inventory Mapping Documentation. The field-level requirements for each collection are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

Product and variant kits are not supported by the BigCommerce integration.

What this means for you: if your catalog uses kits, discuss how to represent them with your implementation partner or MiSP; they will not transfer as kits through the product and variant collections. This behavior is accurate at the time this documentation was written.

The integration writes BigCommerce inventory from one iPaaS.com location. The inventory collections filter on a location name, and inventory records for any other location are skipped.

What this means for you: choose the single iPaaS.com location that holds the inventory you send to BigCommerce and set it in the inventory collections' filters (the shipped example name is MAIN — see the placeholder checklist). If you need inventory from more than one location, contact your implementation partner or MiSP. This behavior is accurate at the time this documentation was written.

BigCommerce rejects inventory levels below zero. The default inventory mappings guard against this — a negative source quantity is sent as 0, using the Larger(QtyAvailable, 0) function in the mapping.

What this means for you: if your source stock can go below zero, keep the guard in place (or add one) so the integration never sends a negative number, which BigCommerce would reject. This behavior is accurate at the time this documentation was written.

For a newly added product, inventory external IDs are not linked until a full product update is performed.

What this means for you: if you rely on the inventory external-ID link, expect it to be established after the first full product update rather than at initial creation. This behavior is accurate at the time this documentation was written.

The product and variant channel-assignment mappings ship as example logic that assigns records to channel 1 (your first store). If no channel is specified in a mapping, BigCommerce defaults the record to channel 1.

What this means for you: replace the example channel logic with your own channel-selection rules before relying on channel assignments. Stores set up with BigCommerce Multi-Store Fulfillment require the correct channel IDs — contact your implementation partner or MiSP for guidance. This behavior is accurate at the time this documentation was written.

The Delete BigCommerce Product TO iPaaS.com and Delete BigCommerce Product Variant FROM iPaaS.com collections let deletions in one system remove the record in the other. Delete collections carry no field mappings by design.

What this means for you: decide which system is your source of truth for products and variants, and enable a delete collection (and its corresponding webhook) only when you want deletions to propagate. Do not add field mappings to a delete collection. This behavior is accurate at the time this documentation was written.

Related mapping documentation: BigCommerce Product Category Mapping Documentation. The field-level requirements for each collection are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

The BigCommerce default mappings in iPaaS.com are built around a single category tree.

What this means for you: if you want to build out multiple category trees in BigCommerce, contact your implementation partner or MiSP for the additional configuration. This behavior is accurate at the time this documentation was written.

The integration does not delete BigCommerce categories in response to an iPaaS.com category delete. Removing a category in iPaaS.com does not remove it in BigCommerce; category cleanup in BigCommerce is a manual store operation.

What this means for you: plan to remove unwanted BigCommerce categories manually in the store — deleting them in iPaaS.com will not do it. This is a deliberate safeguard against unintended catalog changes. This behavior is accurate at the time this documentation was written.

Subscribing to the iPaaS.com product-category-updated event for the category-assignment flow can create transfers that run but usually perform no action, because the product is already assigned to the same category.

What this means for you: subscribe selectively to category-update events for the assignment flow to avoid redundant transfers. This behavior is accurate at the time this documentation was written.

Related mapping documentation: BigCommerce Customer Mapping Documentation. The field-level requirements for each collection are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

Standard (non-B2B) customer collections bring BigCommerce customers and their addresses into iPaaS.com. Writing customers and their addresses back to BigCommerce from iPaaS.com is not active at this time — the outbound customer and address collections capture data in one direction only.

What this means for you: treat the standard customer relationship as BigCommerce-to-iPaaS.com. If your workflow needs iPaaS.com to write customers back to BigCommerce, submit a feature request through your iPaaS.com partner channel describing the requirement so it can inform a future release, and validate any outbound customer behavior in a staging environment before relying on it. This behavior is accurate at the time this documentation was written.

Related mapping documentation: BigCommerce B2B Company Mapping Documentation, BigCommerce B2B Customer Mapping Documentation, and BigCommerce B2B Quote Mapping Documentation. The field-level requirements for each collection are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

The B2B Company, B2B Customer, and their address and relationship collections apply only to stores using BigCommerce B2B Edition.

What this means for you: if you are not using BigCommerce B2B Edition, delete the B2B collections — they have nothing to process. This behavior is accurate at the time this documentation was written.

A B2B relationship's Type is derived from the BigCommerce B2B role, and only the four BigCommerce B2B roles are represented: Super Admin, Admin, Senior Buyer, and Junior Buyer.

What this means for you: expect B2B relationships to resolve to one of those four roles. If your workflow needs a role concept BigCommerce does not define, discuss it with your implementation partner or MiSP. This behavior is accurate at the time this documentation was written.

Creating and updating BigCommerce B2B quotes is not implemented at the time this documentation was written. The B2B Quote collections (header, line, addresses, notes, and legal terms) are provided for completeness, but no quote is written to BigCommerce.

What this means for you: do not rely on the B2B Quote collections to create or update quotes in BigCommerce yet. If B2B quote write-back is important to your workflow, submit a feature request through your iPaaS.com partner channel, and validate quote behavior in a staging environment before relying on it in production. This behavior is accurate at the time this documentation was written.

Related mapping documentation: BigCommerce Gift Card Mapping Documentation. The field-level requirements for each collection are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

The gift-card activity collection records the initial issuance of a gift card. Later balance movements — redemptions and adjustments — are not recorded by this collection.

What this means for you: use the activity collection for issuance tracking; if you need ongoing balance history, discuss the approach with your implementation partner or MiSP. This behavior is accurate at the time this documentation was written.

When an order contains gift-certificate line items, the corresponding gift cards are created automatically during order preprocessing. This can be turned off with the Disable Gift Card Auto-Creation During Order To iPaaS Preprocessing subscription setting.

What this means for you: if you do not want gift cards created automatically as part of order transfers, enable that subscription setting. This behavior is accurate at the time this documentation was written.

Removing a gift card in BigCommerce can propagate the delete to the linked iPaaS.com record.

What this means for you: confirm the delete behavior against your business rules in a staging environment before relying on it in production. This behavior is accurate at the time this documentation was written.

Related mapping documentation: BigCommerce Shipment Mapping Documentation. The field-level requirements for each collection are in the corresponding collection descriptions in the iPaaS.com mapping configuration.

The Shipment FROM iPaaS.com collection writes shipment data to orders that already exist in BigCommerce (it does not create orders). As delivered, its mapping filter is pinned to an always-false condition, so it processes no records until the filter is updated.

What this means for you: if you want iPaaS.com shipments written to BigCommerce, review and update the filter on the shipment collection to select the records you intend to send. Because this is a BigCommerce write, the Unmapped Field Overwrite Risk applies — map every field you want preserved. This behavior is accurate at the time this documentation was written.

The integration's templates ship with example / environment-specific values that each subscriber must replace before enabling the affected collection. This is the consolidated pre-launch checklist; the full context for each item is in the feature sections above and in the linked mapping documentation.

Several of these values are test scaffolding carried over from the integration's build environment. They will not work in your store and must be replaced — the guest email domains and the customer-group filter value in particular.

For the field-level detail behind any limitation or checklist item, follow the Related mapping documentation links in each feature section above and the corresponding collection descriptions in the iPaaS.com mapping configuration.

This article covers the known limitations across the BigCommerce integration's order, payment, product, inventory, category, customer, B2B, gift-card, and shipment features, plus the pre-launch placeholder checklist. For detailed, field-level technical documentation, see the mapping collection descriptions in the iPaaS.com mapping configuration and the related mapping documentation linked in each section above.