Contents
Summary
iPaaS.com transactions can be created and updated from commercetools orders through polling and Manual Sync. Each commercetools order becomes one iPaaS.com transaction carrying the order identifier, status, purchaser email address and monetary totals, together with its line items, shipping and billing addresses, an order-level tax record and its payments. The purpose is to deliver storefront commerce activity to the downstream systems a subscriber has connected to iPaaS.com — an ERP, an accounting package or a fulfilment provider — without a second lookup against commercetools.
ID Format
Manual Sync ID Format
Enter the commercetools order identifier — the identifier commercetools assigns automatically when the order is created, visible on the order record in the commercetools Merchant Center. commercetools issues record identifiers as 36-character GUIDs (UUIDs).
Pattern: eight hexadecimal characters, then three groups of four, then twelve, separated by hyphens.
Example: f0441ff6-969d-4b14-8417-0e299c77218b
This is not the human-readable order number a merchant may separately have configured. The same value is what the TransactionNumber mapping writes into iPaaS.com.
None of the six child collections has an independent Manual Sync entry point. A subscriber transfers an order — with its lines, addresses, tax record and payments — by running Manual Sync against Add/Update commercetools Order TO iPaaS.com with the order identifier above.
External ID Format
After a successful transfer, iPaaS.com saves the commercetools order identifier — the same 36-character GUID, for example f0441ff6-969d-4b14-8417-0e299c77218b — as the external ID on a record that links the commercetools order to the iPaaS.com transaction. That link is the primary match used when the same order is transferred again.
TransactionNumber is the fallback match key used when no external ID link exists yet. Child records carry no external ID of their own; a line, address, tax record or payment is tracked through the transaction it belongs to.
Subscribers or their MiSP who intend to re-transfer historical orders should expect matching to occur on the external ID link first, and on TransactionNumber only where no link has yet been created.
Deleted Record Support
Outbound delete is not supported by this integration for any record, in either direction. Delete mappings are not included in the default templates for the order family, and a deletion in commercetools does not propagate to iPaaS.com.
The practical consequences are:
An order cancelled or deleted in commercetools leaves its iPaaS.com transaction in place. Cancellation reaches iPaaS.com only as an order state change through the Status mapping, and only if the order is transferred again after the state changes.
Removing a line item, an address, a payment or a tax record in commercetools does not remove the corresponding child record from the iPaaS.com transaction.
A delete request issued against any collection in this family fails without a descriptive message.
Subscribers or their MiSP who need removals reflected downstream must handle them in the downstream system directly.
Custom Field Support
This integration has no custom-field implementation for orders. No conversion function is available to read a commercetools custom field or custom type into an iPaaS.com transaction, line, address, tax record or payment, and no order-family mapping in the shipped configuration references one.
Any commercetools data a subscriber needs that is not covered by the mappings documented below must be brought across by editing an existing mapping to read the value from the order record, rather than by a custom-field mechanism.
Mapping Collection Status
Mapping Collection | Status |
Add/Update commercetools Order TO iPaaS.com | Enabled |
Add/Update commercetools Order Line Item TO iPaaS.com | Enabled |
Add/Update commercetools Order Ship Address TO iPaaS.com | Enabled |
Add/Update commercetools Order Bill Address TO iPaaS.com | Enabled |
Add/Update commercetools Order Tax Line TO iPaaS.com | Enabled |
Add/Update commercetools Order Payment TO iPaaS.com | Enabled |
Add/Update commercetools Order Payment Placeholder TO iPaaS.com | Disabled — permanently, by its mapping filter |
Trigger Events
Order intake from commercetools is polling-based only. This integration registers no webhook subscription with commercetools, so no event-driven or real-time order delivery occurs. Two events cause an order to transfer:
Poll. A scheduled poll retrieves commercetools orders modified since the last successful poll. Read the poll caveat under System Caveats before relying on this path for volume.
Manual Sync. A subscriber or their MiSP transfers a specific order on demand by supplying its identifier on the parent collection. Manual Sync is a platform-level feature and is available regardless of polling configuration.
Both events transfer the order header and then all of its child records in the same run. No child collection can be triggered on its own.
The Payment Placeholder Collection Is Permanently Disabled
Add/Update commercetools Order Payment Placeholder TO iPaaS.com carries the mapping filter 1==0 && SourceTypeName == "ParentOnly". The first condition asks whether one equals zero, which is false in every case, and the two conditions are joined by a logical AND — so the filter as a whole is false for every record that will ever be evaluated against it. This collection creates nothing today and can never create anything while that filter is in place. It is not "usually inactive" or "inactive under normal conditions"; it is unreachable.
The parent order transfer runs normally and the other five child collections are unaffected. This one simply contributes no record.
Two things must change before it produces anything, and both are required:
Edit the mapping filter and remove the
1==0 &&portion, leavingSourceTypeName == "ParentOnly". That remaining condition is the one that does meaningful work — it restricts the collection to the order-derived payment candidate.Satisfy the
CHECKpayment-method prerequisite. The Method mapping ships as a Static value ofCHECK, and Placeholder value — replace during implementation: an iPaaS.com Payment Method named exactlyCHECK, in that spelling and case, must exist in the subscriber's tenant — or the mapping's static value must be changed to the name of a Payment Method that already exists. One of the two must be done. If neither is done, every payment record this collection creates is rejected the moment the collection is enabled, and the payment does not reach the transaction. This mapping applies no Lookup Translation, so nothing corrects the value in transit.
Subscribers or their MiSP should also confirm the outcome is the one they want before enabling it. With both payment collections active, an order that carries real payment records produces those records and an additional whole-order stand-in record, which overstates the amount paid on that transaction. Enable it only where orders are not expected to carry payment records of their own, and validate the result in a staging environment first.
The reason the collection ships disabled is not documented. Subscribers should treat the configuration as intentional unless iPaaS.com Support advises otherwise.
Duplicate or Conflicting Mappings
No other mapping collection in this integration brings commercetools orders into iPaaS.com, so there is no duplicate at the order-header level. Two overlaps do exist among the children, and both are managed by mapping filters rather than by any conflict-resolution mechanism.
Collision Handling Is Not Available
This integration implements no collision-resolution behavior on any collection. No collision method can be selected on any of the seven collections in this family, and none is configured. Duplicate prevention rests entirely on the external ID link described under ID Format, which is a different mechanism: it matches a re-transferred order to the transaction it created previously. It does not resolve a conflict between two collections writing similar records.
The Two Address Collections Both Write Transaction Address
Add/Update commercetools Order Ship Address TO iPaaS.com and Add/Update commercetools Order Bill Address TO iPaaS.com write to the same iPaaS.com Transaction Address destination on the same transaction, and both carry the same mapping filter. They are separated by their Static flag mappings rather than by their filters: the shipping collection sets IsPrimaryShipping to true, the billing collection sets IsPrimaryBilling to true.
This matters most when a shopper bills and ships to the same place, because the transaction then holds two address records with identical content that can be told apart only by those flags. Clearing or removing either Static mapping would leave the transaction with two indistinguishable addresses. Neither should be changed.
The Two Payment Collections Both Write Transaction Payment
Add/Update commercetools Order Payment TO iPaaS.com and Add/Update commercetools Order Payment Placeholder TO iPaaS.com write to the same iPaaS.com Transaction Payment destination and hang off the same parent. They are separated by complementary mapping filters: the first admits records whose source type is not ParentOnly, the second is written to admit only records whose source type is ParentOnly. A given payment candidate can therefore satisfy at most one of the two, even if the Placeholder collection is enabled.
They can nevertheless both contribute records to the same transaction. On an order that carries real payments, the first collection writes one record per payment while the second would add a further record covering the whole order total — overstating the amount paid. Subscribers or their MiSP who edit either filter should preserve the complementary relationship; relaxing the first collection's filter so that it also admits the order-derived candidate produces the same overstatement.
Supported Child Collections
Parent Collection: Add/Update commercetools Order TO iPaaS.com — the order header, written as an iPaaS.com transaction.
Child Collection | Purpose |
Add/Update commercetools Order Line Item TO iPaaS.com | One transaction line per commercetools line item, carrying SKU, quantity, prices and line tax. |
Add/Update commercetools Order Ship Address TO iPaaS.com | The order's delivery address, plus the shipping method and shipping charge. |
Add/Update commercetools Order Bill Address TO iPaaS.com | The order's billing address. |
Add/Update commercetools Order Tax Line TO iPaaS.com | A single order-level tax record carrying the order's total tax and a representative rate. |
Add/Update commercetools Order Payment TO iPaaS.com | One payment record per payment attached to the commercetools order. |
Add/Update commercetools Order Payment Placeholder TO iPaaS.com | A single stand-in payment record derived from the order total. Permanently disabled as shipped. |
Each child is invoked only as part of the parent order transfer and cannot be scheduled, filtered or triggered independently of it. If the order header fails, no child records are written for that order.
System Caveats
commercetools Caveats
Monetary values are stored in minor currency units, and every amount mapping in this family divides by 100. That divisor is correct only for a two-decimal currency such as USD or EUR. It affects the order totals, every line price, the line and order tax amounts, the shipping charge and both payment amounts. Subscribers or their MiSP trading in a currency that does not use two decimal places should validate the resulting figures in a staging environment before relying on them in production, and adjust the divisor in each affected formula to match the currency in use.
commercetools includes the shipping charge in the order total. The Subtotal mapping compensates by subtracting shipping. Where an order carries no taxed shipping price, no subtraction occurs and the subtotal equals the order total.
The taxed price fields are not present on every order. The order Total, TaxAmount and ShippingAmount mappings, the line ExtendedPrice and EstimatedTaxAmount mappings, and the whole tax-line collection all read from the order's or line's taxed price. commercetools populates those only once tax has been calculated. Where they are absent, the affected mappings write no value rather than writing zero, so an order that has not yet had tax calculated arrives with empty totals even though its order total price is populated.
Tax mode governs whether tax figures exist at all. commercetools documents that under the ExternalAmount tax mode the taxed shipping price "is always empty in this tax mode", and that under the Disabled tax mode "No taxes are added to the Cart". Under either mode no tax or shipping figure is carried into iPaaS.com.
Line item names are localised, and the description mapping reads one locale only. It reads the English (United States) translation. A storefront operating in another locale receives empty line descriptions unless an English (United States) name is maintained on every product.
Custom line items are not supported. commercetools custom line items — order lines not backed by a catalogue product — carry no variant and therefore no SKU, so they fail the line collection's product-resolution requirement. They are also excluded from the order's TotalQty count.
Addresses are almost entirely optional in commercetools. Country is the one component commercetools requires, and only when an address is present at all. commercetools does not require an order to carry a shipping address, a billing address or shipping details.
commercetools applies request limits and per-project quotas to its API, published at
https://docs.commercetools.com/api/limits(retrieved 2026-07-20). Most are configurable per project; a few are hard limits. This documentation makes no claim that a request declined for a limit is retried or resumed on the subscriber's behalf. Treat a declined request as a failed transfer: monitor Dashboard / Integration Monitoring / Error Logs, re-run affected orders with Manual Sync, and validate expected throughput in a staging environment before relying on it in production.
iPaaS.com Caveats
The transaction Type and Status fields accept only fixed value lists. Type accepts Order, Shipment, Invoice, Hold, Quote, Ticket, Return, Validated Return and Job. Status accepts Pending, Complete, Cancelled, Shipped, Backorder, Refunded, Partially Refunded, Partially Shipped, Awaiting Pickup, Awaiting Payment, On Hold, Processing, Returned and Draft. A value outside the list is rejected when the order is written, and a missing value fails the field's requirement.
The transaction line Type field accepts only Product and Giftcard, and the line Status field accepts the same list as the transaction status.
A transaction must be tied to a customer, a company or an email address. This family satisfies that requirement through EmailAddress alone; no customer or company identifier is mapped. Orders therefore attach to a customer by email match, and two iPaaS.com customers sharing an email address cannot be distinguished. An order whose commercetools record carries no customer email is rejected.
SystemId is applied when the transaction is first created and is ignored on later updates. Re-syncing an order does not move it to a different system.
A line typed Product must resolve to an existing product or variant in iPaaS.com, matched on the line's SKU. This is the reference-data prerequisite most likely to cause a runtime failure — see Setup Requirements.
Shipping methods and payment methods must be pre-configured by name, and neither is translated. The ShippingMethod and payment Method mappings pass their commercetools values straight through with no Lookup Translation, so the names must line up exactly, including case.
iPaaS.com requires additional gift card identification alongside a payment whose method resolves to a gift card. No such field is mapped, so a payment resolving to a gift card method is rejected. Likewise, gift card lines arrive typed Product and are not distinguished from merchandise.
iPaaS.com publishes no accepted-value list for the status on a payment record, unlike the status on a transaction or a transaction line. There is therefore no published basis for confirming how any given payment status value is handled. Subscribers or their MiSP should validate payment status handling in a staging environment before relying on it in production.
No field on a tax record is marked required by iPaaS.com, so the tax collection cannot fail a required-field check.
Rejected records are reported under Dashboard / Integration Monitoring / Error Logs.
Integration-Specific Caveats
The poll silently drops orders past the platform's default page, and advances its watermark anyway. The order poll requests orders modified since the last poll without specifying a page size, so commercetools returns its default page of results — 20 records unless the project's default differs (
https://docs.commercetools.com/api/general-concepts, retrieved 2026-07-20); the integration then advances the poll watermark unconditionally. If more commercetools orders are created or modified between two poll cycles than a single default page carries, only that first page transfers and the remainder are skipped permanently — the watermark has already moved past them. This is data loss, not a delay, and it raises no error. Manual Sync against the specific order identifiers is the only recovery. Subscribers or their MiSP running volumes above that rate should poll frequently enough that fewer orders change per cycle than a single default page carries, reconcile order counts between commercetools and iPaaS.com on a schedule, and treat any shortfall as missing orders to be recovered by Manual Sync.No automatic dependency transfer occurs. Transferring an order does not cause the related customer, product or catalogue records to be transferred first. Records an order depends on must already exist in iPaaS.com, or the order attaches only by the values it carries.
Initialization is not supported. Existing commercetools order history is not backfilled automatically.
Order-level tax and line-level tax are calculated independently. The order TaxAmount and the tax record's Amount both read the order's own taxed price; the line EstimatedTaxAmount reads each line's taxed price. Neither is summed from the other, so the two figures should be reconciled in a staging environment before being relied on.
The order Subtotal subtracts the net shipping amount while the order Total is taken from the gross taxed total. Subtotal, tax and shipping will therefore not always sum exactly to the total on tax-inclusive orders.
There is no de-duplication guard on the child collections. Repeated transfers of the same order re-present the same lines, addresses, tax candidate and payments to their collections.
Setup Requirements
commercetools Configuration
A configured and authorized connection to commercetools, using the credentials described in Connections and Settings. The full setup walkthrough is in the Installation Instructions.
Every product variant sold through the storefront must carry a SKU. A variant with no SKU is the root cause of the most common line-level failure in this family.
An inventory of the shipping method names the storefront produces, and of the payment method values the project records on order payments. Both are needed for the iPaaS.com configuration below.
A decision on the order Type mapping, confirmed against real order data, before the first production transfer.
iPaaS.com Configuration
The iPaaS.com system referenced by the SystemId mapping must exist.
The products the order's SKUs refer to must already exist in the iPaaS.com catalogue. This integration performs no automatic dependency transfer, so a SKU present on the order but absent from iPaaS.com will not resolve and the line is rejected.
An iPaaS.com Shipping Method must exist with a name exactly matching each commercetools shipping method name in use. Repeat this whenever a new shipping method is added in commercetools. The alternative is to add a Lookup Translation to the ShippingMethod mapping.
An iPaaS.com Payment Method must exist with a name exactly matching each commercetools payment method value in use, including case. The alternative is to add a Lookup Translation to the payment Method mapping. Doing neither leaves payment intake exposed to rejection.
A Lookup Translation row must exist for every commercetools order state the storefront produces, including Confirmed, which the shipped table does not cover. See the Lookup Translation Tables under Mappings.
If the Payment Placeholder collection is to be enabled, complete both steps under Mapping Collection Status first, including the
CHECKpayment-method prerequisite.
Authentication and Security
No subscriber-facing webhook setup is required or possible for this family — commercetools order intake is poll-only and no webhook receiver is registered. Polling frequency and connection credentials are configured on the subscription; the field-by-field reference is in Connections and Settings, and the endpoints the integration calls are listed in API Endpoints.
Integration Flow
The order is selected. Either a scheduled poll requests commercetools orders modified since the last successful poll, or a subscriber runs Manual Sync against Add/Update commercetools Order TO iPaaS.com with a specific order identifier. On the poll path, commercetools returns its default page of 20 orders and the poll watermark advances regardless of how many orders actually changed — see the poll caveat under System Caveats before relying on this path for volume.
The transaction is matched or created. iPaaS.com looks for an existing external ID link carrying the commercetools order identifier. Where one exists, that transaction is updated; otherwise TransactionNumber is used as the fallback match key, and where neither matches a new transaction is created and the link is written.
The order header is written from the eleven mappings on the parent collection — identifiers, type, status, email address and the monetary totals. SystemId is applied only on creation. If the header fails, the run stops for that order and no child records are written.
Line items are written through Add/Update commercetools Order Line Item TO iPaaS.com, one transaction line per commercetools line item. This collection has no mapping filter, so every line is processed. Each line is fixed to type Product and must resolve to an existing iPaaS.com product or variant on its SKU; a line that cannot resolve is rejected and the order arrives without it.
The shipping address is written through Add/Update commercetools Order Ship Address TO iPaaS.com, together with the shipping method name and the net shipping charge. Its filter admits only the single order-derived row, so exactly one shipping address is produced per order. A shipping method name with no matching iPaaS.com Shipping Method should be validated in a staging environment before go-live.
The billing address is written through Add/Update commercetools Order Bill Address TO iPaaS.com, under the same filter and therefore also exactly one record per order. It is distinguished from the shipping address only by its IsPrimaryBilling flag.
The order-level tax record is written through Add/Update commercetools Order Tax Line TO iPaaS.com. Its filter admits only the single order-derived row, so one tax record is produced per order carrying the order's total tax — not one record per taxing jurisdiction.
Payments are written through Add/Update commercetools Order Payment TO iPaaS.com, one record per payment attached to the commercetools order. Its filter excludes the order-derived candidate. An order with three payments produces three payment records; an order with no payments produces none, which is not an error.
The payment placeholder collection is evaluated and produces nothing. Its filter can never be true. Nothing is written and no error is raised.
Results are reported. Successfully transferred records appear on the iPaaS.com transaction. Rejections are reported under Dashboard / Integration Monitoring / Error Logs. A child rejection does not roll back the header or the other children already written, so a partially populated transaction is a possible outcome.
Mappings
Add/Update commercetools Order TO iPaaS.com
iPaaS.com data type: Transaction
This collection has no mapping filter, so every order returned by a poll or requested through Manual Sync is processed. It also has no error filter, so no order is rejected before its mappings are evaluated.
Description: Writes the commercetools order header to an iPaaS.com transaction — identifier, type, status, purchaser email address and the order's monetary totals.
Mapping Type | Source Field (commercetools) | Destination Field (iPaaS.com) | Description |
Dynamic Formula |
| SystemId | Required. Identifies the iPaaS.com system the transaction belongs to, resolved from the commercetools connection the order was transferred from, so orders are attributed to the correct system without subscriber configuration. Applied when the transaction is first created; not updatable and ignored on later transfers of the same order. |
Field |
| TransactionNumber | Required. The commercetools order identifier, a 36-character GUID. This is also the value supplied through Manual Sync, and the fallback match key when no external ID link yet exists. Subscribers who prefer the human-readable order number here must change this mapping. |
Field |
| Type | Required. The iPaaS.com transaction type, which accepts only the nine values listed under iPaaS.com Caveats. The commercetools value is passed straight through with no Lookup Translation — see the note on controlled value domains after this table. |
Lookup | Lookup Translation: Order State To iPaaS (source field | Status | Required. Converts the commercetools order state into an iPaaS.com transaction status, which accepts only the fourteen values listed under iPaaS.com Caveats. The shipped value pairs are given under Lookup Translation Tables below; the Confirmed order state has no row. |
Field |
| EmailAddress | Required. The purchaser's email address. Every iPaaS.com transaction must be tied to a customer, a company or an email address, and this collection maps only the email address — so an order with no customer email is rejected, and orders attach to a customer by email match alone. |
Dynamic Formula | (gross taxed total, divided by 100 — formula below) | Total | Recommended. The grand total of the order, taken from the taxed gross total, which includes tax. Where the order carries no taxed price the mapping writes no value rather than zero, so an order that has not had tax calculated arrives with an empty total. |
Dynamic Formula | (order total less net shipping, divided by 100 — formula below) | Subtotal | Recommended. The order total less the shipping charge, because commercetools includes shipping in the order total. Where the order carries no total price the mapping writes no value. The subtraction uses the net shipping amount while Total is the gross taxed total, so subtotal, tax and shipping will not always sum exactly to the total. |
Dynamic Formula | (total tax, divided by 100 — formula below) | TaxAmount | Recommended. The total tax on the order, taken from the order's taxed price. Where the order carries no taxed price the mapping writes no value rather than zero. |
Dynamic Formula | (net shipping total, divided by 100 — formula below) | ShippingAmount | Optional. The net shipping charge, before tax on shipping. Where the order carries no taxed shipping price the mapping writes no value rather than zero. |
Dynamic Formula | (sum of line discounts, divided by 100 — formula below) | DiscountAmount | Optional. The combined value of item-level and cart-level discounts across all lines. Where the order has no discounts the mapping writes zero rather than no value. Discounts recorded only at the order level, outside the line items, are not included. |
Dynamic Formula | (sum of line quantities — formula below) | TotalQty | Optional. The sum of the quantities of every line on the order. Where the order has no line items the mapping writes zero. The count covers ordinary line items only; custom line items are excluded. |
The Total formula:
int? amount = taxedPrice?.totalGross?.centAmount;if (amount != null) {//iPaaS saves in dollars, not centsdouble dollarAmount = (double)amount / 100;return dollarAmount;} else return null;The Subtotal formula:
int shippingAmount = 0;int? foundShipping = taxedShippingPrice?.totalNet?.centAmount;if (foundShipping != null) { shippingAmount = foundShipping; }int? amount = totalPrice?.centAmount;if (amount != null) {//Commmercetools includes shipping in its subtotal, so remove itamount = amount - shippingAmount;//iPaaS saves in dollars, not centsdouble dollarAmount = (double)amount / 100;return dollarAmount;} else return null;The TaxAmount formula:
int? amount = taxedPrice?.totalTax?.centAmount;if (amount != null) {//iPaaS saves in dollars, not centsdouble dollarAmount = (double)amount / 100;return dollarAmount;} else return null;The ShippingAmount formula:
int? amount = taxedShippingPrice?.totalNet?.centAmount;if (amount != null) {//iPaaS saves in dollars, not centsdouble dollarAmount = (double)amount / 100;return dollarAmount;} elsereturn null;The DiscountAmount formula:
int totalDiscountCents = 0;double totalDiscount = 0;if (lineItems != null){ foreach (var lineItem in lineItems) { int totalLineDiscountCents = 0; //Scenario 1: Product only discount must be calculated by comparing full price vs final price var originalItemPrice = lineItem.price.value.centAmount; if (lineItem.price.discounted != null) { var discountedItemPrice = lineItem.price.discounted.value.centAmount; var itemDiscountAmount = originalItemPrice - discountedItemPrice; itemDiscountAmount = itemDiscountAmount * lineItem.quantity; totalLineDiscountCents += itemDiscountAmount; } //Scenario 2: Cart level discounts are found in a different object if (lineItem.discountedPricePerQuantity != null) { foreach (var cartDiscount in lineItem.discountedPricePerQuantity) { if (cartDiscount.discountedPrice.includedDiscounts != null) { foreach (var nestedDiscount in cartDiscount.discountedPrice.includedDiscounts) { var cartDiscountAmount = nestedDiscount.discountedAmount.centAmount; cartDiscountAmount = cartDiscountAmount * cartDiscount.quantity; totalLineDiscountCents += cartDiscountAmount; } } } } //Add both types of line discount totals to the header total totalDiscountCents += totalLineDiscountCents; }}//Convert cents to dollarsif (totalDiscountCents != 0) totalDiscount = (double)totalDiscountCents / 100;return totalDiscount ;The TotalQty formula:
double totalQty = 0;if (lineItems != null){ foreach (var lineItem in lineItems) { totalQty += (double)lineItem.quantity ; }}return totalQty ;Controlled Value Domains on This Collection
Two fields on this collection write into iPaaS.com fields that accept only a fixed list of values, and they are configured differently.
Status is handled correctly. It uses the Order State To iPaaS Lookup Translation, which converts each commercetools order state into a value iPaaS.com accepts.
Type is not. It maps the commercetools order record's type value straight through with no Lookup Translation, into a field that accepts only the nine values listed under iPaaS.com Caveats. Any value outside that list is rejected at intake, and a missing value fails the field's requirement. Because commercetools does not document a type field on the order resource itself, subscribers or their MiSP should confirm in a staging environment what value actually arrives before relying on this mapping in production. If the transferred value is not one of the nine accepted values, change Type to a Static value of Order, or add a Lookup Translation that maps the incoming value onto an accepted one.
Lookup Translation Tables
Order State To iPaaS — used by the Status mapping.
Source Value | Destination Value | Notes |
Open | Pending | The state a newly placed order carries. |
Complete | Complete | Direct one-to-one match. |
Cancelled | Cancelled | Direct one-to-one match. Reaches iPaaS.com only if the order is transferred again after it is cancelled — cancellation itself does not propagate. |
Pending | Complete | Pending is not one of the four documented commercetools order states. This row has no effect unless a subscriber's configuration produces such a value. |
These are designed constants, not environment-specific values, and do not need to be replaced during implementation. Two points do need subscriber attention.
commercetools documents four order states: Open, Confirmed, Complete and Cancelled. The shipped table covers three of them. Confirmed has no row, so an order in that state produces no status and fails the required-field check on Status. Subscribers or their MiSP whose storefront uses Confirmed must add a row for it, choosing the iPaaS.com status that matches their downstream process.
The table also carries a row for a source value of Pending, which is not a documented commercetools order state, as noted above.
Add/Update commercetools Order Line Item TO iPaaS.com
iPaaS.com data type: Transaction Line
This collection has no mapping filter, so every line item on the order is processed. It also has no error filter.
Description: Writes one iPaaS.com transaction line per commercetools order line item, carrying the SKU, the ordered quantity, the unit and extended prices, and the line's tax.
Mapping Type | Source Field (commercetools) | Destination Field (iPaaS.com) | Description |
Static |
| Type | Required (designed constant). iPaaS.com accepts only Product and Giftcard on a transaction line. The collection transfers ordinary merchandise lines. Fixing the type to Product is what makes Sku effectively required — see the note after this table. Gift card lines also arrive typed Product and are not distinguished. |
Static |
| Status | Required (designed constant). commercetools tracks status at the order level rather than the line level, so there is no per-line source value and a fixed starting status is used. Every line arrives Pending regardless of the parent order's status, so a cancelled or completed order arrives with its lines still Pending. Subscribers whose downstream process reads line status should account for this or replace the Static value with a mapping derived from the order state. |
Dynamic Formula | (variant SKU — formula below) | Sku | Conditional — and the condition is always met on this collection. Reads the SKU from the product variant recorded on the line. Because Type fixes every line to Product, iPaaS.com requires the line to resolve to an existing product or variant matched on this SKU. A line arriving with no SKU cannot resolve and is rejected, and the order arrives without that line. This is the most likely runtime failure in the shipped configuration. |
Field |
| Qty | Recommended. The quantity ordered. This is the ordered quantity, not a shipped or remaining quantity; this collection does not map shipped quantity. |
Dynamic Formula | (English (United States) line name — formula below) | Description | Recommended. The English (United States) translation of the commercetools line item name. commercetools line names are localised and this mapping reads one locale only, so a storefront operating in another locale receives empty descriptions unless an English (United States) name is maintained on every product. |
Dynamic Formula | (first available discounted or list price, divided by 100 — formula below) | UnitPrice | Recommended. The price actually charged per unit, after any discount. commercetools records a discounted line price in more than one location depending on how the discount was applied, so the formula checks three sources in order and returns the first present. Where none is present the mapping writes no value. |
Dynamic Formula | (item price, divided by 100 — formula below) | OriginalUnitPrice | Optional. The undiscounted list price per unit. Comparing it with UnitPrice shows the per-unit discount applied; on an undiscounted line the two are the same. Where the line carries no item price the mapping writes no value. |
Dynamic Formula | (line net total, divided by 100 — formula below) | ExtendedPrice | Optional. The net total for the line, before tax. Where the line carries no taxed price the mapping writes no value rather than zero, so lines on orders that have not had tax calculated arrive with an empty extended price even though a unit price and quantity are present. |
Dynamic Formula | (line total tax, divided by 100 — formula below) | EstimatedTaxAmount | Optional. The tax total for the line. Where the line carries no taxed price the mapping writes no value rather than zero. The order-level tax total is taken from the order's own taxed price rather than summed from these line values, so the two are calculated independently and should be reconciled in a staging environment. |
The Sku formula:
var value = variant?.sku;if (value != null) { return value ;} else return null;The Description formula:
var value = name?.enUS;if (value != null) { return value ;} else return null;The UnitPrice formula:
//Check for a discounted priceint? discountedAmount = discountedPrice?.value?.centAmount;if (discountedAmount != null) { //iPaaS saves in dollars, not cents double discountedDollarAmount = (double)discountedAmount / 100; return discountedDollarAmount;}//Check for a discounted price in another locationint? discountedAmount2 = price?.discounted?.value?.centAmount;if (discountedAmount2 != null) { //iPaaS saves in dollars, not cents double discountedDollarAmount2 = (double)discountedAmount2/ 100; return discountedDollarAmount2;}//Check for a normal priceint? amount = price?.value?.centAmount;if (amount != null) { //iPaaS saves in dollars, not cents double dollarAmount = (double)amount / 100; return dollarAmount;}else {return null;}The OriginalUnitPrice formula:
int? amount = price?.value?.centAmount;if (amount != null) {//iPaaS saves in dollars, not centsdouble dollarAmount = (double)amount / 100;return dollarAmount;} else {return null;}The ExtendedPrice formula:
int? amount = taxedPrice?.totalNet?.centAmount;if (amount != null) {//iPaaS saves in dollars, not centsdouble dollarAmount = (double)amount / 100;return dollarAmount;} else {return null;}The EstimatedTaxAmount formula:
int? amount = taxedPrice?.totalTax?.centAmount;if (amount != null) {//iPaaS saves in dollars, not centsdouble dollarAmount = (double)amount / 100;return dollarAmount;} else {return null;}Missing SKUs Are the Most Likely Line Failure
A line arriving with no SKU is a data condition rather than a configuration error, and it is the failure subscribers should plan for first. Subscribers or their MiSP should:
Confirm that every commercetools product variant sold through the storefront carries a SKU. A variant with no SKU is the root cause.
Confirm that the products those SKUs refer to already exist in iPaaS.com. This integration performs no automatic dependency transfer, so a SKU present on the order but absent from the iPaaS.com catalogue will not resolve.
Validate both conditions against real order data in a staging environment before relying on this collection in production.
commercetools custom line items, which are order lines not backed by a catalogue product, have no variant at all and will always fail this condition.
Add/Update commercetools Order Ship Address TO iPaaS.com
iPaaS.com data type: Transaction Address
Mapping Filter
SourceTypeName == "ParentOnly"
Filter Description. The filter admits only rows whose source is the parent order record itself. It checks the source type of each candidate row and includes the row when that source type is ParentOnly; every other source type is skipped. There are two branches:
Passes — the single row the integration supplies for each order, sourced directly from the order record and carrying the source type
ParentOnly. This is how the collection is invoked in the shipped configuration, so the shipping address transfers for every order.Skipped — any row whose source type is something other than
ParentOnly, such as an element of a list on the order. No such row is produced today. The filter exists so that if a future configuration were to supply address rows from a list, those rows would not be written as the order's shipping address alongside the one this collection is designed to produce.
The filter pins no environment-specific value and needs no substitution during implementation. Subscribers should not remove it: without it, a configuration that supplied more than one address row would write multiple shipping addresses to the same transaction.
Description: Writes the order's delivery address to the iPaaS.com transaction, together with the shipping method name and the net shipping charge.
Mapping Type | Source Field (commercetools) | Destination Field (iPaaS.com) | Description |
Static |
| IsPrimaryShipping | Optional (designed constant). Marks this address as the order's primary shipping address. It is what distinguishes this record from the billing address written by Add/Update commercetools Order Bill Address TO iPaaS.com. Clearing or removing this mapping would leave the transaction with two indistinguishable addresses, so it should be left as it is. |
Dynamic Formula |
| Address1 | Recommended. Joins the street number and street name with a single space. commercetools treats both as optional, so where only one is present the line carries a leading or trailing space, and where neither is present the line is just a space. Where the order has no shipping address at all this field is empty. |
Dynamic Formula |
| City | Recommended. The city of the shipping address. commercetools treats the city as optional, so it can arrive empty; where it does, the field is left unset rather than written as an empty value. |
Dynamic Formula |
| PostalCode | Recommended. The postal code, on which downstream shipping and tax systems commonly depend. Optional in commercetools, so it can arrive empty. The value is passed through exactly as commercetools recorded it, with no formatting or validation. |
Dynamic Formula |
| Country | Recommended. The country. This is the one address component commercetools requires, so whenever the order carries a shipping address the value is present. commercetools records it as a country code rather than a name, and the value passes through with no translation — add a Lookup Translation if a downstream system expects a name. |
Dynamic Formula |
| FirstName | Recommended. The recipient's first name. Optional in commercetools, so it can arrive empty even on an order with a complete street address; where it does, the field is left unset. |
Dynamic Formula |
| LastName | Recommended. The recipient's last name. Optional in commercetools, so it can arrive empty; where it does, the field is left unset. |
Dynamic Formula |
| Company | Optional. The company name on the shipping address, most often populated on business-to-business orders and empty on consumer orders. Where commercetools has no company, the field is left unset. |
Dynamic Formula |
| ShippingMethod | Recommended. The value must match an existing iPaaS.com Shipping Method by name. iPaaS.com constrains this field to the shipping methods configured in the subscription, and this mapping passes the commercetools name through with no Lookup Translation. Subscribers should validate in a staging environment how an unmatched shipping method name behaves before relying on this mapping in production. Where the order carries no shipping details the field is left unset. |
Dynamic Formula | (net shipping total, divided by 100 — formula below) | ShippingAmount | Optional. The net shipping charge on the order's shipping address. Where commercetools has not calculated a taxed shipping price the field is left unset rather than written as zero. Under the ExternalAmount and Disabled tax modes no shipping charge is carried at all. |
The ShippingAmount formula:
int? amount = Parent.taxedShippingPrice?.totalNet?.centAmount;if (amount != null) {//iPaaS saves in dollars, not centsdouble dollarAmount = (double)amount / 100;return dollarAmount;} else return null;Subscribers or their MiSP should inventory the shipping method names in use in commercetools and create an iPaaS.com Shipping Method with an exactly matching name for each, before the first production transfer, repeating that step whenever a new shipping method is added. The alternative is to add a Lookup Translation on the ShippingMethod mapping.
Add/Update commercetools Order Bill Address TO iPaaS.com
iPaaS.com data type: Transaction Address
Mapping Filter
SourceTypeName == "ParentOnly"
Filter Description. The filter admits only rows whose source is the parent order record itself, checking the source type of each candidate row and including the row when that source type is ParentOnly. There are two branches:
Passes — the single row the integration supplies for each order, sourced directly from the order record. This is how the collection is invoked in the shipped configuration, so the billing address transfers for every order.
Skipped — any row whose source type is something other than
ParentOnly, such as an element of a list on the order. No such row is produced today. The filter exists so that if a future configuration were to supply address rows from a list, those rows would not be written as the order's billing address alongside the one this collection is designed to produce.
The filter pins no environment-specific value and needs no substitution during implementation. Subscribers should not remove it: without it, a configuration that supplied more than one address row would write multiple billing addresses to the same transaction.
Description: Writes the order's billing address to the iPaaS.com transaction.
Mapping Type | Source Field (commercetools) | Destination Field (iPaaS.com) | Description |
Static |
| IsPrimaryBilling | Optional (designed constant). Marks this address as the address the order was billed to, and is what distinguishes it from the shipping address. This matters most when a shopper bills and ships to the same place, because the transaction then holds two address records with identical content that can be told apart only by these flags. It should be left as it is. |
Dynamic Formula |
| Address1 | Recommended. Joins the street number and street name with a single space. Both are optional in commercetools, so where only one is present the line carries a leading or trailing space, and where neither is present the line is just a space. Where the order has no billing address at all this field is empty. |
Dynamic Formula |
| City | Recommended. The city of the billing address. Optional in commercetools, so it can arrive empty; where it does, the field is left unset rather than written as an empty value. |
Dynamic Formula |
| PostalCode | Recommended. The postal code, on which downstream invoicing and tax-reporting systems commonly depend. Optional in commercetools, so it can arrive empty. Passed through exactly as commercetools recorded it, with no formatting or validation. |
Dynamic Formula |
| Country | Recommended. The country. This is the one address component commercetools requires, so whenever the order carries a billing address the value is present. Recorded as a country code rather than a name and passed through with no translation — add a Lookup Translation if a downstream system expects a name. |
Dynamic Formula |
| FirstName | Recommended. The first name of the bill-to party. Optional in commercetools, so it can arrive empty even on an order with a complete street address; where it does, the field is left unset. |
Dynamic Formula |
| LastName | Recommended. The last name of the bill-to party. Optional in commercetools, so it can arrive empty; where it does, the field is left unset. |
Dynamic Formula |
| Company | Optional at the platform level, but the field most likely to matter on business-to-business orders, where the invoice is issued to a company rather than an individual. Subscribers who invoice companies should confirm their storefront captures the company on the billing address. Where commercetools has no company, the field is left unset. |
Add/Update commercetools Order Tax Line TO iPaaS.com
iPaaS.com data type: Transaction Tax
Mapping Filter
SourceTypeName == "ParentOnly"
Filter Description. The filter admits only rows whose source is the parent order record itself, including the row when its source type is ParentOnly and skipping every other source type. There are two branches:
Passes — the single row the integration supplies for each order, sourced directly from the order record. This is how the collection is invoked in the shipped configuration, so one tax record transfers for every order.
Skipped — any row whose source type is something other than
ParentOnly, such as an individual tax entry drawn from a list of tax entries on the order. No such row is produced today.
This filter is what keeps the collection to a single order-level tax record. It does not select among several tax entries; it admits only the one row sourced from the order itself. It pins no environment-specific value and needs no substitution during implementation. Subscribers should not remove it: without it, a configuration that supplied per-jurisdiction tax rows would write several tax records to the same transaction alongside the order-level total, double-counting the tax.
Description: Writes a single order-level tax record to the iPaaS.com transaction, carrying the order's total tax and a representative rate.
Mapping Type | Source Field (commercetools) | Destination Field (iPaaS.com) | Description |
Dynamic Formula | (order total tax, divided by 100 — formula below) | Amount | Recommended. The tax charged on the order, read from the order's taxed price. iPaaS.com marks no field on a tax record as required, so this is recommended rather than required — but it is the reason the collection exists and the figure downstream systems post and reconcile against. It is the order's total tax across every contributing jurisdiction, not a per-jurisdiction figure. Where commercetools has not calculated a taxed price the field is left unset rather than written as zero. |
Dynamic Formula | (order total tax, divided by 100 — formula below) | OriginalAmount | Optional. The tax as originally assessed. The formula is identical to the one behind Amount, so the two values are always identical on this integration and the transaction carries no record of a tax figure having been adjusted after first assessment. Subscribers who need that distinction must change this mapping to draw from a different source. |
Dynamic Formula | (rate of the first tax portion — formula below) | TaxPercent | Optional. The tax rate, read from the first tax portion recorded on the order's taxed price. Where the order has no taxed price, or no tax portion to read a rate from, the field is left unset. See the two constraints described after this table. |
The Amount formula:
int? amount = Parent.taxedPrice?.totalTax?.centAmount;if (amount != null) {//iPaaS saves in dollars, not centsdouble dollarAmount = (double)amount / 100;return dollarAmount;} else return null;The OriginalAmount formula:
int? amount = Parent.taxedPrice?.totalTax?.centAmount;if (amount != null) {//iPaaS saves in dollars, not centsdouble dollarAmount = (double)amount / 100;return dollarAmount;} else return null;The TaxPercent formula:
double? amount = Parent.taxedPrice?.taxPortions[0]?.rate;if (amount != null) { return Convert.ToDouble(amount);} else return null;How Far the Tax Rate Can Be Trusted
commercetools records tax as a set of portions, one for each contributing jurisdiction, each carrying its own rate. This mapping reads only the first of those portions. On an order taxed by a single jurisdiction that is the whole story. On an order taxed by several jurisdictions — a combined state and local tax, for example — the rate written here describes only one component while Amount carries the full total. Subscribers whose orders are taxed in more than one jurisdiction should not attempt to derive tax from this rate and should treat Amount as the authoritative figure.
Separately, the scale of this value is not documented on either side: commercetools publishes the tax rate as a decimal number without stating whether it is a fraction or a whole-number percentage, and the iPaaS.com tax percent field carries no documented value range. Subscribers should transfer a representative taxed order into a staging environment and confirm the resulting value reads the way their downstream systems expect before relying on it in production.
Add/Update commercetools Order Payment TO iPaaS.com
iPaaS.com data type: Transaction Payment
Mapping Filter
SourceTypeName != "ParentOnly"
Filter Description. When the parent order transfer runs, the integration presents payment candidates to this collection in two different shapes: one candidate for each real payment record attached to the commercetools order, and one additional candidate derived from the order itself rather than from any payment record. The second shape carries the source type ParentOnly. This filter is the negation of that test, so it has two branches:
Passes — any candidate whose source type is not
ParentOnly, meaning an actual commercetools payment record attached to the order. Each one produces its own iPaaS.com payment record.Skipped — the single order-derived candidate carrying the source type
ParentOnly. That candidate is the one handled — as shipped, not handled — by Add/Update commercetools Order Payment Placeholder TO iPaaS.com.
The practical effect is that an order with three payments produces three iPaaS.com payment records, and an order with no payments produces none, which is not an error condition and does not stop the order transfer. The filter pins no environment-specific value and needs no substitution during implementation.
Description: Writes one iPaaS.com payment record per payment attached to the commercetools order, recording the payment method, the payment interface that handled it and the amount.
Mapping Type | Source Field (commercetools) | Destination Field (iPaaS.com) | Description |
Dynamic Formula |
| Method | Required. The only field iPaaS.com requires on a payment record. iPaaS.com requires the value to match the name of a Payment Method already configured in the subscriber's tenant, and this mapping passes the commercetools value straight through with no Lookup Translation — so the names must line up exactly, including case. The property is optional in commercetools; where it has not been recorded, no value is supplied for this required field and the payment record is rejected. |
Dynamic Formula | (fixed value — always | Status | Optional. As configured, this mapping records the value |
Dynamic Formula |
| Description | Recommended. The commercetools payment interface, recorded as free text. It identifies the payment service provider that handled the payment, which gives downstream systems a way to tell one payment channel from another on the same transaction. commercetools imposes no vocabulary on this property; the values seen depend on the payment service providers configured in the project. Where it has not been recorded, the field is left empty and no error occurs. |
Dynamic Formula | (planned amount, divided by 100 — formula below) | Amount | Recommended. The value of the commercetools payment. Where commercetools has recorded no planned amount, the payment record is created without an amount and the order transfer is not interrupted. iPaaS.com accepts a payment record without an amount, though such a record is of limited use downstream. |
The Status formula:
if (1==0){ //Deposit ticket support TBD return Parent.paymentState;} else { return "Authorized"}The Amount formula:
int? amount = amountPlanned?.centAmount;if (amount != null) {//iPaaS saves in dollars, not centsdouble dollarAmount = (double)amount / 100;return dollarAmount;} elsereturn null;The Payment Status Is Always Authorized
The formula's first branch is guarded by the condition 1==0, which is never true, so the branch that would read the commercetools payment state is never taken and only the fixed value is returned. Every payment record this collection creates carries the status Authorized, whatever the payment's real state in commercetools. A failed payment, a pending payment and a fully settled payment all arrive identically.
The observable consequence is that this field carries no information. Subscribers or their MiSP reading iPaaS.com payment records must not treat it as evidence of the payment's real state, and any downstream rule keyed on payment status will behave as though every order was authorized.
Subscribers who need the real commercetools payment state recorded must edit this mapping to read it from the order. commercetools records an order-level payment state whose documented values are BalanceDue, Failed, Pending, CreditOwed and Paid (commercetools API reference, consulted 2026-07-20). Any such change should be validated in a staging environment first, since iPaaS.com publishes no accepted-value list for the destination.
Payment Methods Must Be Pre-Configured
This is the single most likely failure in this collection, and it depends entirely on subscriber configuration. Before the first order transfer, subscribers or their MiSP must:
Inventory the commercetools payment method values in use — every value the project can record as a payment method on an order payment.
Create a matching iPaaS.com Payment Method for each one, with the name matching exactly, including case.
Or add a Lookup Translation to the Method mapping that translates each commercetools value into the name of an iPaaS.com Payment Method that already exists.
Either approach resolves the constraint; doing neither leaves payment intake exposed to rejection. Rejections are reported under Dashboard / Integration Monitoring / Error Logs.
Separately, iPaaS.com requires additional gift card identification alongside a payment whose method resolves to a gift card. This collection maps no such field, so a payment resolving to a gift card payment method is rejected. Subscribers whose commercetools project issues gift cards should validate this path in a staging environment before relying on it in production.
Add/Update commercetools Order Payment Placeholder TO iPaaS.com
iPaaS.com data type: Transaction Payment
Mapping Filter
1==0 && SourceTypeName == "ParentOnly"
Filter Description. This filter has two conditions joined by a logical AND, so a record is admitted only when both are true.
1==0— asks whether one equals zero. This is never true, for any record, under any configuration. On its own it is enough to make the whole filter false.SourceTypeName == "ParentOnly"— asks whether the candidate being evaluated is the order-derived payment candidate rather than a real commercetools payment record. Of the candidates the integration presents during an order transfer, only the order-derived one carries the source typeParentOnly. This condition would be true for that single candidate and false for every real payment record.
Because the first condition is a constant false, the second is never reached in effect and the combined filter admits nothing. No record passes this collection today and none ever will while the filter stands. No error is raised — the collection simply contributes no record. Removing the 1==0 && portion leaves the second condition operating alone, which is the behavior the rest of this subsection describes.
The filter pins no environment-specific value; the 1==0 term is a deliberate kill switch rather than a placeholder to substitute. The placeholder in this collection is the Method value — see the field table.
Description: Would create a single stand-in payment record on the transaction, derived from the commercetools order itself rather than from any payment attached to it, for use where no individual payment records are available to transfer. Everything below describes what the collection would do if a subscriber enabled it, not behavior that occurs today.
Mapping Type | Source Field (commercetools) | Destination Field (iPaaS.com) | Description |
Static |
| Method | Required, and a hard prerequisite. Placeholder value — replace during implementation: an iPaaS.com Payment Method named exactly |
Dynamic Formula | (order gross taxed total, divided by 100 — formula below) | Amount | Recommended. The order's gross taxed total. Unlike the corresponding mapping on Add/Update commercetools Order Payment TO iPaaS.com, the amount comes from the order rather than from any individual payment, because this collection represents the order's payment as a whole. An order carries a gross taxed total only once tax has been calculated on it; where none is present the payment record is created without an amount. |
Static |
| Description | Optional (designed constant). A fixed label identifying the record as a stand-in for the order's payment rather than a record of an actual payment transaction. Because this collection carries no payment service provider detail from commercetools, this label is what tells anyone reading the transaction downstream that the payment line was synthesized from the order total. The wording may be changed; the value has no meaning to iPaaS.com beyond being free text. |
Static |
| Status | Optional (designed constant). A fixed status marking the record as a stand-in rather than a settled payment. iPaaS.com publishes no accepted-value list for the status on a payment record, so there is no published basis for confirming whether this value is stored as given, normalized or refused. Subscribers or their MiSP should validate payment status handling in a staging environment before enabling this collection in production, and change the value if their downstream systems expect a specific vocabulary. |
The Amount formula:
int? amount = Parent.taxedPrice?.totalGross?.centAmount;if (amount != null) {//iPaaS saves in dollars, not centsdouble dollarAmount = (double)amount / 100;return dollarAmount;} elsereturn null;Note that iPaaS.com separately documents a payment-method type list that includes a title-case entry for checks. The value required by the Method mapping is the name of a configured Payment Method, not a type, and a title-case Payment Method name does not satisfy a Static value of CHECK.
Three of this collection's four fields carry fixed values that are not read from commercetools. This is deliberate for a stand-in record, but it does mean that every record the collection would create looks identical apart from the amount.
Error Handling
The complete catalog of user-facing messages for this integration is in the commercetools Error Messages article. The conditions below are the ones specific to the order family; each is reported under Dashboard / Integration Monitoring / Error Logs.
A transaction status could not be resolved — the commercetools order state has no row in the Order State To iPaaS Lookup Translation, which is most commonly the Confirmed state. The required Status field receives no value and the order is rejected. Resolution: add a row for that order state to the Lookup Translation, choosing the iPaaS.com status that matches the downstream process, then re-run the order with Manual Sync.
A transaction type value was not accepted — the raw commercetools value reaching the Type mapping is not one of the nine values iPaaS.com accepts. Resolution: change the Type mapping to a Static value of
Order, or add a Lookup Translation that maps the incoming value onto an accepted one.A transaction could not be tied to a customer, company or email address — the commercetools order carries no customer email, and no customer or company identifier is mapped. Resolution: ensure the storefront captures a customer email on every order, or add a mapping for the customer identifier.
A line item could not be resolved to a product — the line arrived with no SKU, or with a SKU that does not exist in the iPaaS.com catalogue. The order transfers without that line. Resolution: confirm the commercetools variant carries a SKU, confirm the product exists in iPaaS.com, then re-run the order with Manual Sync. commercetools custom line items always fail this condition.
A shipping method was not recognized — the commercetools shipping method name has no exactly matching iPaaS.com Shipping Method. Validate this behavior in a staging environment before go-live; the transfer at intake, not just the address. Resolution: create an iPaaS.com Shipping Method with the exactly matching name, or add a Lookup Translation on the ShippingMethod mapping.
A payment method was not recognized — the commercetools payment method value has no exactly matching iPaaS.com Payment Method name. The payment record is rejected and the payment does not reach the transaction; the rest of the order still transfers. Resolution: create a matching iPaaS.com Payment Method, or add a Lookup Translation on the Method mapping.
A gift card payment could not be completed — iPaaS.com requires gift card identification alongside a payment whose method resolves to a gift card, and no such field is mapped. Resolution: this path is not supported as shipped; validate it in a staging environment and route gift card payments outside this collection.
A commercetools request was declined for a limit or quota — commercetools applies request limits and per-project quotas. Nothing in this integration reschedules or resumes a declined request. Resolution: treat it as a failed transfer, re-run the affected orders with Manual Sync, and consider reducing concurrency or poll frequency. Per-project quotas are documented at
https://docs.commercetools.com/api/limits(retrieved 2026-07-20).A delete request failed without a descriptive message — delete is not supported by this integration. Resolution: no fix is available; handle removals in the downstream system directly.
Note that some conditions produce no message at all. Orders dropped by the poll page limit described under System Caveats are skipped silently, and the permanently disabled placeholder collection contributes nothing without raising an error. Neither appears in the Error Logs.
Validation Rules
TransactionNumber, Type, Status, SystemId and EmailAddress are required on the transaction. A missing or unacceptable value on any of them rejects the order, and no child records are written.
Type must be one of Order, Shipment, Invoice, Hold, Quote, Ticket, Return, Validated Return, Job.
Status must be one of Pending, Complete, Cancelled, Shipped, Backorder, Refunded, Partially Refunded, Partially Shipped, Awaiting Pickup, Awaiting Payment, On Hold, Processing, Returned, Draft. The same list applies to the transaction line status.
A transaction line must be typed Product or Giftcard. Every line from this family is typed Product, which requires the line to resolve to an existing iPaaS.com product or variant on its SKU.
A transaction payment must carry a Method matching the name of a configured iPaaS.com Payment Method, exactly, including case. It is the only field iPaaS.com requires on a payment record.
A shipping method name should match a configured iPaaS.com Shipping Method exactly. The field is Recommended rather than Required; subscribers should validate the behavior of an unmatched value in a staging environment before go-live.
No field on a tax record is required, so the tax collection cannot fail a required-field check.
SystemId is enforced on creation only and is ignored on subsequent updates of the same transaction.
Mapping filters are evaluated before mappings. A record that fails its collection's filter is skipped without error; it is not a rejection.
Testing and Validation
Test Scenarios
Create and transfer a complete order. Place an order in commercetools with at least two line items, a shipping address, a billing address, calculated tax and at least one payment. Run Manual Sync on Add/Update commercetools Order TO iPaaS.com with the order identifier. Expected: one iPaaS.com transaction carrying the order identifier as TransactionNumber, one transaction line per commercetools line item, exactly two address records distinguished by their primary shipping and primary billing flags, exactly one tax record, and one payment record per commercetools payment.
Verify the monetary conversion. Compare the transferred Total, Subtotal, TaxAmount, ShippingAmount and DiscountAmount against the commercetools order. Expected: each figure equals the commercetools minor-unit value divided by 100. Confirm the same for line prices, the tax record's Amount, and the payment Amount. Subscribers trading in a currency that does not use two decimal places should expect this test to fail and adjust the divisors accordingly.
Update an order and re-transfer it. Change the order state in commercetools and run Manual Sync again with the same identifier. Expected: the same iPaaS.com transaction is matched through its external ID link and updated; Status reflects the new state through the Lookup Translation; SystemId is unchanged; no duplicate transaction is created.
Verify the order state translation covers every state in use. Transfer an order in each order state the storefront produces. Expected: each translates to an iPaaS.com status. An order in the Confirmed state will fail the required-field check on Status until a row is added.
Verify required-field validation on the transaction. Transfer an order whose commercetools record carries no customer email. Expected: the order is rejected and the rejection appears under Dashboard / Integration Monitoring / Error Logs. No line, address, tax or payment record is written.
Verify the transaction type value. Inspect the value the Type mapping produces on a real order before the first production transfer. Expected: one of the nine accepted values. If it is not, change the mapping to a Static value of
Orderor add a Lookup Translation.Verify SKU resolution. Transfer an order containing a line whose commercetools variant has no SKU, and an order containing a commercetools custom line item. Expected: both lines are rejected, the rejections appear in the Error Logs, and the order arrives without those lines while its other lines transfer normally.
Verify shipping method matching. Transfer an order using a commercetools shipping method with no matching iPaaS.com Shipping Method. Expected: confirm and record the observed behavior — this is the scenario to validate in staging rather than assume. Create the matching Shipping Method and re-run to confirm it then succeeds.
Verify payment method matching. Transfer an order whose payment uses a commercetools payment method value with no matching iPaaS.com Payment Method. Expected: the payment record is rejected while the rest of the order transfers. Create the matching Payment Method and re-run to confirm the payment then arrives.
Confirm the payment status limitation. Transfer orders with payments in different commercetools payment states. Expected: every iPaaS.com payment record carries the status
Authorizedregardless. This confirms the field cannot be used to reason about payment state.Confirm the placeholder collection produces nothing. Transfer any order and inspect the transaction's payment records. Expected: only records produced by Add/Update commercetools Order Payment TO iPaaS.com are present, and no
Payment placeholderrecord appears.Verify poll behavior at volume before go-live. In a staging environment, modify more commercetools orders between two poll cycles than a single default page can carry (commercetools defaults
limitto 20 —https://docs.commercetools.com/api/general-concepts, retrieved 2026-07-20) and let the poll run. Expected: fewer orders arrive than were modified, with no error raised. This confirms the page-limit behavior described under System Caveats and establishes the poll frequency the subscriber's volume requires.
Validation Checklist
The iPaaS.com transaction carries the commercetools order identifier as its TransactionNumber and as its external ID link.
Type and Status hold values from the accepted iPaaS.com lists.
The transaction is tied to the expected customer through EmailAddress.
The transaction line count matches the commercetools line item count, excluding custom line items.
Every transferred line carries a SKU that resolves to an existing iPaaS.com product or variant.
Exactly one address carries the primary shipping flag and exactly one carries the primary billing flag.
The shipping method name on the transaction matches a configured iPaaS.com Shipping Method.
Exactly one tax record is present, carrying the order's total tax.
The payment record count matches the number of payments attached to the commercetools order.
Every payment Method value matches a configured iPaaS.com Payment Method name.
All monetary values are in major currency units and reconcile against the commercetools order.
No
Payment placeholderrecord is present unless that collection has been deliberately enabled.No orders are missing from iPaaS.com relative to the commercetools order count for the same period.
Dashboard / Integration Monitoring / Error Logs contains no unexpected rejections for the test orders.
Additional Notes
The following are out of scope for this family of mapping collections:
Deleting orders or any of their child records. Delete is not supported by this integration in either direction.
Sending orders from iPaaS.com to commercetools. All seven collections in this family are inbound only; there is no outbound counterpart.
Webhook or event-driven order delivery. Intake is polling-based only.
Initialization. Existing commercetools order history is not backfilled.
Collision handling. No collision-resolution behavior is implemented on any collection.
Custom fields. This integration has no custom-field implementation for orders.
Automatic dependency transfer. Customers, products and catalogue records referenced by an order are not transferred on the order's behalf.
Payment transaction detail below the payment record — authorizations, captures, refunds and their individual states.
Gift card identification and any payment method detail beyond the four mapped payment fields.
Shipped or remaining quantities on a line. Only the ordered quantity is mapped.
Per-jurisdiction tax records. A single order-level tax record is produced.
Order-level discounts recorded outside the line items. The DiscountAmount total covers item-level and cart-level discounts recorded on the lines.
Behaviors a subscriber should treat as constraints on this release, at the time this documentation was written, are gathered in the commercetools Known Limitations article; the ones with the widest effect on this family are the poll page limit, the untranslated Type mapping, the always-Authorized payment status and the two-decimal currency assumption in every monetary formula.
For assistance, contact iPaaS.com Support at support@ipaas.com.