Contents
Summary
This document covers the collections that write orders, shipments, and tracking from iPaaS.com to BigCommerce, plus the one collection that captures BigCommerce payment methods into iPaaS.com. The transaction write-back collections let orders created in another system be represented as BigCommerce orders, and the shipment collections push tracking numbers and shipped items back onto an existing BigCommerce order. The write-back collections ship Disabled by default behind an always-false guard — an intentional safeguard so no orders are written until you review and enable them. The Payment Method collection runs in the opposite direction, bringing BigCommerce payment gateways into iPaaS.com so the order transfers can reference how each order was paid.
ID Format
Manual Sync ID Format
The direction determines which ID you enter on the Manual Sync page:
Transaction Add / Update FROM iPaaS.com and Shipment FROM iPaaS.com: enter the iPaaS.com Transaction ID — the numeric identifier iPaaS.com assigns to the transaction (release ticket). Example: 512348. Transferring a transaction this way also transfers its lines, billing address, and shipment tracking, because those child collections have no independent Manual Sync entry point.
Payment Method To iPaaS.com: enter the BigCommerce payment-method code — the short identifier BigCommerce uses for the gateway. Example: braintree.
External ID Format (saved after sync)
Transaction / Shipment writes (FROM iPaaS.com). After a successful transaction write, iPaaS.com records the BigCommerce order identifier as the external ID on a dedicated external-ID record. That record is the primary match that routes a later change of the same transaction to an update rather than creating a duplicate order. The shipment and update collections locate the BigCommerce order through this same external-ID link, so it must already exist before they can write.
Payment Method (TO iPaaS.com). After a successful capture, iPaaS.com records the BigCommerce payment-method code as the external ID on a dedicated external-ID record, which routes a later capture of the same method to an update. The code is also written into the iPaaS.com Name field, which provides visibility on the record and serves as a fallback match key when no external-ID record yet exists.
Deleted Record Support
None of the collections in this document delete records. The transaction and shipment collections write orders, order content, and shipments to BigCommerce; the Payment Method collection creates or updates payment-method records in iPaaS.com. Deletions are not propagated in either direction by these collections.
Custom Field Support
The transaction write-back collections read BigCommerce and iPaaS.com custom fields to drive several behaviors:
Line items use a SellingUnit custom field. When a line carries a selling-unit value, it is appended to the SKU with a caret (
^) separator so BigCommerce resolves the correct sellable unit. The same value feeds product-option resolution on the line.Shipment tracking reads a Shipment Line No custom field on the tracking record to determine which of the order's lines were shipped.
Product Modifiers on line items let shopper-entered values travel with a sold line item. To use them, create the modifier in BigCommerce, add a matching BigCommerce custom field in the subscription (module BC Order Product; the custom-field name becomes the modifier's display name), then map it on the Transaction Line collections. See the BigCommerce Products documentation for how the corresponding modifiers are created on the product.
BigCommerce custom fields are configured in the subscription under Subscription Management → Subscriptions → BigCommerce → Custom Fields.
Payment methods carry no custom fields. BigCommerce does not expose custom fields on payment methods, so none can be brought into iPaaS.com, and no iPaaS.com custom fields are created by default for the Payment Method collection.
Mapping Collection Status
Status depends on the collection:
Transaction Add FROM iPaaS.com, Transaction Update FROM iPaaS.com, and Shipment FROM iPaaS.com are Disabled by default. Each parent's mapping filter is pinned to an always-false (
1 == 0) condition, so no records are processed as shipped. This is an intentional safeguard — the collections do not write anything to BigCommerce until you review the mappings and activate them. See the per-collection Mapping Filter blocks in the Mappings section for the exact filter and the activation instructions.The child collections (Transaction Line, Transaction Billing Address, Shipment Tracking) are Enabled, but they transfer only as part of their parent — so the parent's always-false guard effectively gates them too until it is removed.
Payment Method To iPaaS.com is Enabled. It has no mapping filter, so every payment method captured through initialization or order preprocessing is processed.
Trigger Events.
FROM iPaaS.com collections are triggered by iPaaS.com Outbound Data Flows — the transaction created, transaction updated, transaction tracking created, and transaction tracking updated events. Lines and billing addresses transfer as part of their parent transaction and have no independent trigger. (No records transfer until each parent's always-false guard is removed.)
Payment Method To iPaaS.com has no webhook trigger. BigCommerce does not emit a payment-method change event. Payment methods are captured only through the integration's initialization step or automatically during order preprocessing.
Duplicate or Conflicting Mappings
Review each collection's direction and activation state before enabling:
Transaction Add vs. Transaction Update: the Add collection creates new BigCommerce orders; the Update collection changes the status of an existing order. The external-ID link routes each transaction to the right one. Review both collections' Add/Update settings so a new order is created once and subsequent changes are routed to the update collection.
Transaction writes vs. Shipment writes: the transaction collections create and update the order; the shipment collections add tracking to an order that already exists. The shipment collections rely on the order's external-ID link already being present.
Payment Method capture vs. the order/transaction transfers: the Payment Method collection is itself a prerequisite of the order transfers, which reference the captured payment method when recording how an order was paid.
Overwrite Risk (full-replace writes)
Every FROM iPaaS.com collection in this document writes the full record to BigCommerce on each transfer. Fields you leave unmapped can be overwritten — reset to empty or default — each time the record transfers. To protect a field you do not source from iPaaS.com, either map it explicitly or use a DestinationValue approach so the current BigCommerce value is written back unchanged. This behavior is accurate at the time this documentation was written.
Supported Child Collections
The transaction and shipment parents drive child collections that transfer as part of the parent write:
Transaction Add FROM iPaaS.com (parent)
Transaction Line Add FROM iPaaS.com
Transaction Billing Address Add FROM iPaaS.com
Transaction Update FROM iPaaS.com (parent)
Transaction Line Update FROM iPaaS.com
Transaction Billing Address Update FROM iPaaS.com
Shipment FROM iPaaS.com (parent)
Shipment Tracking FROM iPaaS.com
Payment Method To iPaaS.com is a standalone collection with no children.
System Caveats
BigCommerce Caveats
Order must already exist for updates and shipments. The Transaction Update and Shipment collections write to a BigCommerce order located via the transaction's external-ID link. If no linked order exists, there is nothing to update and no order to attach a shipment to.
Products resolve by SKU. Each order line resolves its BigCommerce product and variant by SKU. A line whose SKU does not match an existing BigCommerce product cannot be written to the order.
Product options require product setup. Order-line product options are built from the line's custom fields; the corresponding options must exist on the BigCommerce product for them to apply.
Shipments live on the order. BigCommerce stores tracking on a Shipment attached to the order — a single tracking number and its own list of line items — not on the order header directly. The integration creates that shipment from the iPaaS.com tracking data through the child collection.
Region format. BigCommerce expects the billing region (state/province) in a form it recognizes for the given country. Ensure the iPaaS.com region value matches what BigCommerce accepts.
Payment-method label required. BigCommerce requires a payment-method label on the order. The shipped mapping sets a specific placeholder label (see the Mappings section); review it against how orders originating in your source system were actually paid.
No payment-method change events. BigCommerce does not emit a payment-method change webhook, so payment methods are captured only through initialization or during order preprocessing.
No matching scheme for payment methods. BigCommerce does not provide a match key for payment methods beyond the code itself, which the integration uses for the external-ID link.
Rate limiting. When BigCommerce rate-limits requests, the transfer is automatically rescheduled to resume after the limit window resets — no subscriber action is required.
iPaaS.com Caveats
Buyer link resolves when present. On a new order, the BigCommerce customer link is populated only when the iPaaS.com customer already exists and is linked in BigCommerce; otherwise it is left unset.
External-ID link required for updates and shipments. The Transaction Update and Shipment collections target the BigCommerce order recorded on the transaction's external-ID record. Without that link the update cannot locate an order and the shipment has nowhere to write.
Selling-unit qualifier. When a line carries a selling-unit custom-field value, it is appended to the SKU (using a caret separator) so the correct sellable unit is resolved in BigCommerce. Ensure the SKU and selling-unit values on the transaction line correspond to how the product is set up in BigCommerce.
Billing email from the transaction. The billing email is taken from the parent transaction's email address rather than from the address record itself.
Integration-Specific Caveats
Shipping addresses and methods are not supported. The transaction write-back collections write only the billing address. Importing or updating shipping addresses and shipping methods to BigCommerce is not supported by these collections at this time.
Payment type normalization. The Payment Method collection derives an iPaaS.com PaymentType from the BigCommerce code into a small set of values. Review the produced value against how your downstream systems classify payments (see the Mappings section).
Payment methods flow onward. Payment methods often need to flow to other connected systems. Confirm during implementation that any downstream system expecting payment methods is configured to receive them.
Setup Requirements
iPaaS.com Configuration
For the transaction and shipment writes, enable the relevant record-change events under Outbound Data Flows in the subscription configuration so transfers run automatically:
Transaction created (drives the Transaction Add collection and its children).
Transaction updated (drives the Transaction Update collection and its children).
Transaction tracking created and transaction tracking updated (drive the Shipment collections).
Then remove the always-false guard on each write-back parent's mapping filter to activate it (see the per-collection Mapping Filter blocks). Until both the outbound triggers are enabled and the always-false guard is removed, no transaction or shipment writes occur.
For the Payment Method collection, no webhook or Outbound Data Flow event is required — BigCommerce does not emit a payment-method change event. Payment methods are captured through the integration's initialization step, or automatically the first time an order using a new method transfers.
BigCommerce Configuration
Configure any BigCommerce custom fields you intend to map on order lines (for example, product-modifier fields) under Subscription Management → Subscriptions → BigCommerce → Custom Fields (module BC Order Product).
Confirm the payment-method label(s) recorded on written orders match how your business records these orders (see the placeholder flag in the Mappings section).
See the BigCommerce Installation Instructions for the full webhook and data-flow setup steps.
Integration Flow
Writing a new order (Transaction Add). When a transaction is transferred FROM iPaaS.com (after the always-false guard is removed):
The order header is written to BigCommerce from the mapped fields — buyer link, status, subtotals and totals with and without tax, shipping cost, item count, payment-method label, and an order comment.
The child Transaction Line collection writes the order's line items, resolving each product and variant by SKU.
The child Transaction Billing Address collection writes the primary billing address.
Updating an order (Transaction Update). The update targets the existing BigCommerce order located via the transaction's external-ID link:
The order status is updated on the BigCommerce order.
The child Transaction Line and Transaction Billing Address collections refresh the order's lines and billing address.
Writing a shipment (Shipment). The shipment targets the existing BigCommerce order:
The parent transfer flags the iPaaS.com transaction as a shipment update, so the integration writes shipment data to the already-existing order rather than creating a new one.
The child Shipment Tracking collection resolves the BigCommerce order from the transaction's external-ID link, determines the shipment address, records the tracking number, and writes the matched shipped line items as a BigCommerce shipment.
Capturing a payment method (Payment Method). When an order transfers and its payment gateway does not yet exist in iPaaS.com, the payment method is created automatically during order preprocessing; the full set can also be brought in by running initialization. A failed payment-method prerequisite blocks the order that depends on it.
Mappings
Each collection below lists its iPaaS.com data type in plain terms, a Mapping Filter block where the live collection carries a filter, and its field mapping table. Near-identical Add and Update collections are combined into one subsection with any deltas noted. In the tables, the Source Field (iPaaS.com) column shows the actual field name, static value, or dynamic-formula body from the live mapping; for the Payment Method collection the source column shows the BigCommerce field or formula.
Transaction Add FROM iPaaS.com
iPaaS.com data type: Transaction
This is the parent Add collection. It writes a new BigCommerce order from an iPaaS.com transaction and drives its line and billing-address children.
Mapping Filter
1 == 0 && !TransactionNumber.EndsWith("-D") && !TransactionNumber.EndsWith("-GC") && Type != "Validated Return" && Type != "Invoice"Filter Description. The filter is pinned to an always-false (1 == 0) condition combined with checks that the transaction number does not end in -D (deposit tickets) or -GC (gift-card tickets) and that the Type is neither Validated Return nor Invoice. Because of the 1 == 0 condition, no record passes the filter and the collection writes nothing — this is the intentional Disabled-by-default safeguard, not a placeholder value. To activate the collection, remove the 1 == 0 && guard so the remaining conditions apply, then confirm the change in a staging environment before relying on it in production. Once activated, only non-ticket transactions that are not returns or invoices are written to BigCommerce.
Mapping Type | Source Field (iPaaS.com) | Destination Field (BigCommerce) | Description |
Dynamic Formula |
| CustomerId | Recommended. Links the new order to an existing BigCommerce customer resolved from the iPaaS.com customer's external-ID link. When no linked customer exists, it is left unset. |
Static |
| StatusId | Required. Sets the BigCommerce order status to the status whose id is |
Field |
| SubtotalExTax | Recommended. The order subtotal excluding tax. |
Dynamic Formula |
| SubtotalIncTax | Recommended. The subtotal including tax, computed by adding the transaction's tax amount to its subtotal. |
Field |
| ShippingCostExTax | Recommended. The order shipping cost excluding tax. |
Field |
| ShippingCostIncTax | Recommended. The shipping cost including tax; uses the same iPaaS.com shipping amount as the excluding-tax field. |
Dynamic Formula |
| TotalExTax | Recommended. The order total excluding tax, computed by subtracting the transaction's tax amount from its total. |
Field |
| TotalIncTax | Recommended. The order grand total including tax. |
Field |
| ItemsTotal | Recommended. The total item quantity on the order. |
Static |
| PaymentMethod | Required. The payment-method label recorded on the order; BigCommerce requires a label. Placeholder value — replace during implementation: |
Dynamic Formula |
| CustomerMessage | Recommended. An order comment composed from a fixed prefix and the transaction number. Placeholder value — replace during implementation: the |
Transaction Update FROM iPaaS.com
iPaaS.com data type: Transaction
This is the parent Update collection. It updates the status of an existing BigCommerce order (located via the transaction's external-ID link) and drives its line and billing-address children to refresh the order's content. It maps only the order status; the line and address detail come from the child collections.
Mapping Filter
1==0 && Status == "Complete" && !TransactionNumber.EndsWith("-D") && !TransactionNumber.EndsWith("-GC") && Type != "Validated Return" && Type != "Invoice"Filter Description. The filter is pinned to an always-false (1==0) condition combined with checks that the transaction Status is Complete, the transaction number does not end in -D or -GC, and the Type is neither Validated Return nor Invoice. Because of the 1==0 condition, no record passes the filter — this is the intentional Disabled-by-default safeguard, not a placeholder value. To activate the collection, remove the 1==0 && guard so the remaining conditions apply, then confirm the change in a staging environment before relying on it in production. Once activated, only completed, non-ticket transactions that are not returns or invoices update their BigCommerce order.
Mapping Type | Source Field (iPaaS.com) | Destination Field (BigCommerce) | Description |
Static |
| StatusId | Required. Sets the BigCommerce order status to the status whose id is |
Transaction Line Add / Update FROM iPaaS.com
iPaaS.com data type: Transaction Line
Child of the Transaction collections. Writes the order's line items, resolving each product and variant by SKU. The Add and Update child collections map identical fields; the table below covers both. Neither carries a mapping filter — every line of a transferring parent transaction is processed.
Mapping Type | Source Field (iPaaS.com) | Destination Field (BigCommerce) | Description |
Dynamic Formula |
| VariantId | Recommended. Resolves the BigCommerce variant for the line from its SKU, taking any selling-unit value into account; used when the product has variants. |
Dynamic Formula |
| ProductId | Required. Resolves the BigCommerce product for the line from its SKU. A line with no matching BigCommerce product cannot be written. |
Field |
| Name | Recommended. The line item name, from the transaction line's description. |
Dynamic Formula | (see SKU formula below the table) | Sku | Required. Computes the SKU used for the line — appending the selling-unit value with a |
Field |
| PriceExTax | Recommended. The line's extended price excluding tax. |
Dynamic Formula | (see price-with-tax formula below the table) | PriceIncTax | Recommended. The line's unit price including tax. When an estimated tax amount and a positive quantity are present, it adds the per-unit tax to the unit price; otherwise it adds the estimated tax amount to the unit price. |
Field |
| Quantity | Recommended. The line quantity. |
Dynamic Formula |
| ProductOptions | Recommended. Builds the BigCommerce product options for the line from its custom fields, resolved against the SKU and any selling-unit value; applies when the product uses options. |
SKU formula (Add / Update):
var sellingUnit = GetCustomFieldValue(CustomFields, "SellingUnit");var finalSku = (sellingUnit != null && !string.IsNullOrWhiteSpace(sellingUnit.ToString()) && !string.IsNullOrEmpty(sellingUnit.ToString()))? Sku + "^" + sellingUnit: Sku;return finalSku;
Price-with-tax formula (Add / Update):
if (EstimatedTaxAmount != null && Qty > 0) { return UnitPrice + (EstimatedTaxAmount / Qty);} else { return UnitPrice + EstimatedTaxAmount;} return UnitPrice;Transaction Billing Address Add / Update FROM iPaaS.com
iPaaS.com data type: Transaction Address
Child of the Transaction collections. Writes the primary billing address to the order. The Add and Update child collections map identical fields; the table below covers both. Each carries a filter that selects only the primary billing address.
Mapping Filter
IsPrimaryBilling = true
(The Update child uses the equivalent comparison form IsPrimaryBilling == true.)
Filter Description. The filter selects the transaction address flagged as the primary billing address, so only that address is written as the order's billing address. Other addresses are skipped. No value in this filter is environment-specific, so no placeholder substitution is required.
Mapping Type | Source Field (iPaaS.com) | Destination Field (BigCommerce) | Description |
Dynamic Formula |
| IsBilling | Required. Marks the address as the billing address; a fixed value for this collection. |
Field |
| FirstName | Recommended. The billing contact's first name. |
Field |
| LastName | Recommended. The billing contact's last name. |
Field |
| Company | Recommended. The billing company name. |
Field |
| Street1 | Recommended. The first billing street line, for a deliverable billing address. |
Field |
| Street2 | Recommended. The second billing street line. |
Field |
| City | Recommended. The billing city. |
Field |
| Zip | Recommended. The billing postal code. |
Field |
| Country | Recommended. The billing country. |
Field |
| State | Recommended. The billing region (state/province). Ensure the value matches a region BigCommerce recognizes for the country. |
Dynamic Formula |
| Recommended. The billing email, taken from the parent transaction's email address rather than from the address record. |
Shipment FROM iPaaS.com
iPaaS.com data type: Transaction
Parent shipment collection. It flags the iPaaS.com transaction as a shipment update so the integration writes shipment data to an already-existing BigCommerce order rather than creating a new one; its child collection writes the tracking number and shipped items.
Mapping Filter
1 == 0 && Tracking != null && Tracking.Count > 0
Filter Description. The filter is pinned to an always-false (1 == 0) condition combined with a check that the transaction has at least one tracking number. Because of the 1 == 0 condition, no record passes the filter — this is the intentional Disabled-by-default safeguard, not a placeholder value. To activate the collection, remove the 1 == 0 && guard so the remaining condition applies, then confirm the change in a staging environment before relying on it in production. Once activated, the filter processes a transaction only when it has one or more tracking numbers.
Mapping Type | Source Field (iPaaS.com) | Destination Field (BigCommerce) | Description |
Static |
| IsShipmentUpdate | Required. Flags the transfer as a shipment update so the integration writes to the existing BigCommerce order rather than creating a new one. A fixed control value for this collection, not a placeholder. |
Shipment Tracking FROM iPaaS.com
iPaaS.com data type: Transaction Tracking Number
Child of the Shipment collection. Resolves the BigCommerce order from the parent transaction's external-ID link and writes the tracking number and matched shipped line items as a BigCommerce shipment.
Mapping Filter
var parent = Parent.Id.ToString();if (Parent.ParentId != null && Parent.ParentId >0 ){parent = Parent.ParentId.ToString()}var external = await GetExternalIdAsync(parent, "Transaction", SpaceportSystemId);if(external != null && external.ToString() != "") return true;return false;Filter Description. The filter resolves the parent transaction's external-ID link to a BigCommerce order — using the parent order's id (Parent.ParentId) when the transaction is itself a child — and processes the tracking record only when that link (external) exists and is non-empty. Tracking records whose transaction has no linked BigCommerce order are skipped. No value in this filter is environment-specific, so no placeholder substitution is required. (Note: this child is Enabled, but it only transfers as part of its parent, which is Disabled by default until its own always-false guard is removed.)
Mapping Type | Source Field (iPaaS.com) | Destination Field (BigCommerce) | Description |
Dynamic Formula | (see OrderId formula below the table) | OrderId | Required. Resolves the BigCommerce order the shipment is written to, from the transaction's external-ID link. Without a resolved order there is no shipment target. |
Dynamic Formula | (see OrderAddressId formula below the table) | OrderAddressId | Recommended. Identifies the shipment address on the resolved BigCommerce order by reading its first shipment id. |
Field |
| TrackingNumber | Required. The tracking number recorded on the BigCommerce shipment — the primary purpose of the shipment write. |
Dynamic Formula | (see Items formula below the table) | Items | Recommended. Builds the list of shipped line items by matching the shipped SKUs recorded on the tracking record's Shipment Line No custom field against the parent transaction's lines. |
OrderId formula:
var parent = Parent.Id.ToString();if (Parent.ParentId != null && Parent.ParentId >0 ){parent = Parent.ParentId.ToString()}return await GetExternalIdAsync(parent, "Transaction", SpaceportSystemId);
OrderAddressId formula:
var parent = Parent.Id.ToString();if (Parent.ParentId != null && Parent.ParentId >0 ){parent = Parent.ParentId.ToString()}var external = await GetExternalIdAsync(parent, "Transaction", SpaceportSystemId);return await BigCommerceFirstShipmentIdAsync(external);
Items formula:
var shipmentLines = GetCustomFieldValue(CustomFields, "Shipment Line No");if (shipmentLines != null && !string.IsNullOrWhiteSpace(shipmentLines.ToString())){var parent = Parent.Id.ToString();if (Parent.ParentId != null && Parent.ParentId >0 ){parent = Parent.ParentId.ToString()}var shipmentLineSkus = shipmentLines.Split(",").Select(s => s.Trim()).ToList();var parentLines = Parent.Lines? .Where(line => { if (line == null || line.Qty <= 0 || string.IsNullOrWhiteSpace(line.Sku)) return false; var sellingUnitField = line.CustomFields?.Find(x => x.CustomFieldName == "SellingUnit"); var finalSku = (sellingUnitField != null && !string.IsNullOrWhiteSpace(sellingUnitField.Value) && !string.IsNullOrEmpty(sellingUnitField.Value)) ? line.Sku + "^" + sellingUnitField.Value : line.Sku; return shipmentLineSkus.Contains(finalSku); }) .ToList() ?? null;if (parentLines != null && parentLines.Count > 0 && parent != null && parent.ToString() != ""){var external = await GetExternalIdAsync(parent, "Transaction", SpaceportSystemId);return await BigCommerceShipmentItemsAsync(external, parentLines, "SellingUnit");}}Payment Method To iPaaS.com
iPaaS.com data type: Payment Method
This collection runs in the opposite direction from the rest of this document: it captures a BigCommerce payment method into iPaaS.com so the order and transaction transfers can reference how each order was paid. It has no mapping filter — every payment method captured through initialization or order preprocessing is processed.
In the table below, the Source Field column shows the BigCommerce payment-method field or formula, and the Destination Field column shows the iPaaS.com Payment Method field.
Mapping Type | Source Field (BigCommerce) | Destination Field (iPaaS.com) | Description |
Field |
| Name | Required. Stores the BigCommerce payment-method code on the iPaaS.com Payment Method. Provides visibility and acts as a fallback match key when no external-ID link yet exists. |
Field |
| Description | Recommended. The human-readable BigCommerce payment-method name, stored as the description for display and reporting. |
Dynamic Formula |
| PaymentType | Required. Normalizes the BigCommerce code into an iPaaS.com payment type: |
Testing & Validation
Test Scenarios
Before activating, confirm the write-back collections are inert: with the always-false guard in place, transfer a transaction and confirm no order, shipment, or update is written to BigCommerce.
Remove the always-false guard on the Transaction Add collection in a staging environment, transfer a non-ticket transaction, and confirm the order, its line items, and its billing address appear in BigCommerce with the correct status, totals, and payment-method label.
Confirm the
StatusIdandPaymentMethodplaceholders have been replaced with your store's real values, and that the written order reflects them.Update a completed transaction and confirm the Transaction Update collection updates the existing BigCommerce order's status (and refreshes lines/billing address) rather than creating a duplicate.
Activate the Shipment collection, transfer a transaction that carries a tracking number, and confirm a BigCommerce shipment is created on the existing order with the correct tracking number and shipped items.
Confirm a line whose SKU does not exist in BigCommerce is not written, and that lines with a selling-unit value resolve to the correct sellable unit.
Run initialization for payment methods (or transfer an order using a new gateway) and confirm the BigCommerce payment method is captured into iPaaS.com with the expected normalized payment type.
Confirm unmapped fields are not unexpectedly cleared on a re-transfer, given the full-replace write behavior.
Validation Checklist
The always-false (
1 == 0) guard has been removed from each write-back parent filter you intend to enable, and the change was validated in staging first.The Transaction
StatusIdplaceholder ("10") has been confirmed or replaced with your store's intended order-status id, on both the Add and Update collections.The
PaymentMethodlabel ("Clover Payment") and theCustomerMessageprefix ("Clover Transaction #") have been replaced with values that match how your business records these orders.The Payment Method
PaymentTypenormalization has been reviewed against how your downstream systems classify payments.The correct Outbound Data Flow events (transaction created/updated, transaction tracking created/updated) are enabled for the write-back collections.
Every field you want preserved in BigCommerce is mapped, given the full-replace write behavior.
Additional Notes
Shipping addresses and methods are out of scope. The transaction write-back collections do not import or update BigCommerce shipping addresses or shipping methods. Only the billing address is written.
Payment methods have no webhook. Because BigCommerce emits no payment-method change event, the Payment Method collection is captured only via initialization or order preprocessing. If a new payment method is added in BigCommerce later, capture it by running initialization again, or let it be auto-created the first time an order using it transfers.
The always-false guard is a safeguard, not a defect. The
1 == 0condition on the transaction and shipment parents ships intentionally so no orders are written until an implementer reviews the mappings, replaces the placeholder values, and enables the collections deliberately.