Skip to main content

Shopware Order Update From iPaaS.com Mapping Documentation

How order updates, including line items and payment status, are written from iPaaS.com into Shopware.

Summary

This mapping family pushes status changes from iPaaS.com back onto existing orders in Shopware; it does not create orders. The parent Update Shopware Order FROM iPaaS.com collection resolves the matching Shopware order and updates its overall status, delivery (shipment) status, payment status, and shipping-cost values from the mapped fields. Detailed payment and line-item status updates can be handled by its child collections instead of, or alongside, the header-level mappings.

ID Format

Manual Sync ID Format

A record is transferred from iPaaS.com to Shopware when an iPaaS.com order transfer targets this Shopware subscription. The parent collection resolves the existing Shopware order from the iPaaS.com order (transaction) identity, so the source identifier is the iPaaS.com order id — for example, 12345.

External ID Format

The targeted Shopware order is located through the external id that was saved when the order was first transferred between iPaaS.com and Shopware. The order being updated must already exist in Shopware and be linked to the iPaaS.com order; if no linked Shopware order is found, the update has no target and an error is recorded in Dashboard / Integration Monitoring / Error Logs.

Deleted Record Support

This family supports order updates only — it does not delete orders, deliveries, payments, or line items. There is no Delete collection in the Order Update FROM iPaaS.com family, so deletions are not propagated by this family. Removing an order or its sub-records in iPaaS.com does not remove the corresponding Shopware record through these collections.

Mapping Collection Status

  • Update Shopware Order FROM iPaaS.com: Enabled

  • Update Shopware Order Line Item FROM iPaaS.com: Enabled

  • Update Shopware Order Payment Status FROM iPaaS.com: Enabled

Trigger Events

  • These collections run when an iPaaS.com order transfer targets this Shopware subscription, applying the mapped fields to the matching existing Shopware order. The child collections run as part of the parent order update.

  • Transfers can also be initiated on demand by triggering a Manual Sync of the order from iPaaS.com.

Duplicate or Conflicting Mappings

These collections update order data in Shopware from iPaaS.com. The following mapping collection operates on Order records in the opposite direction:

  • Add/Update Shopware Order TO iPaaS.com: Transfers orders from Shopware to iPaaS.com.

Important: Before enabling these inbound "FROM iPaaS.com" collections alongside the outbound Add/Update Shopware Order TO iPaaS.com collection, subscribers or their MiSP should review and customize their mapping collection filters to prevent circular updates. Define clearly which system is the source of truth for order status. If both directions are active with default mappings, status changes may propagate back and forth between systems.

For payment status and delivery status, the parent's header-level mappings overlap with the dedicated child collections. Use one level — header or child — for each. To update payment status at the child level, leave the parent's header-level Order_Payment_Status mapping unmapped or have it resolve to nothing; to update delivery status at the child level, do the same for Order_Delivery_Status, so the two levels do not issue conflicting updates.

Supported Child Collections

The parent Update Shopware Order FROM iPaaS.com collection supports the following child collections:

  • Update Shopware Order Payment Status FROM iPaaS.com (Transaction Payment): Updates the payment status of the order's payments at the payment (child) level instead of the header-level Order_Payment_Status mapping. The external id resolves the existing Shopware order and its payments, which must already be linked to the iPaaS.com order.

  • Update Shopware Order Line Item FROM iPaaS.com (Transaction Line): Updates line-item status on the order and can create new line items from the incoming data. Each line item is matched to a Shopware product by SKU against the Shopware product number.

  • Update Shopware Order Delivery Status FROM iPaaS.com (Transaction Delivery): Updates the delivery status of the order's deliveries at the delivery (child) level instead of the header-level Order_Delivery_Status mapping.

  • Update Shopware Order Return FROM iPaaS.com (Order Return): Updates order returns associated with the order.

This document details the parent collection and the Line Item and Payment Status child collections. For both delivery status and payment status, choose one level — header or child — for each. To update at the child level, leave the corresponding header-level mapping (Order_Delivery_Status or Order_Payment_Status) unmapped or have it resolve to nothing, so the two levels do not issue conflicting updates.

Shopware Caveats

  • These collections update existing orders only; they do not create orders. The targeted Shopware order must already exist and be linked to the iPaaS.com order.

  • Order, delivery, payment, and line-item status changes are translated from iPaaS.com statuses to Shopware states by name. The referenced Shopware states must exist in the target store, or the corresponding status is not changed.

  • When an order has multiple deliveries or multiple payments, a status update applies to all of them, subject to the DoNotUpdateOrderDeliveryStatuses and DoNotUpdateOrderPaymentStatuses presets that protect statuses already set. Multiple statuses can be listed in each preset, using the exact status names as defined in Shopware.

  • For a single-delivery order, the integration checks the DoNotUpdateOrderDeliveryStatuses preset and, when that value does not match and the TrackingUpdateDefaultDelivery setting is set to True, updates the status of the default delivery.

  • Line items are matched to Shopware products by SKU against the Shopware product number; if the SKU does not match, a new line item cannot be added for it. When the parent order is cancelled, line items are set to Cancelled regardless of their own status.

iPaaS.com Caveats

  • These collections write order, delivery, payment, and line-item status changes into Shopware. When the opposite-direction Add/Update Shopware Order TO iPaaS.com collection is also enabled, subscribers or their MiSP should define which system owns order status so updates do not circulate between the two platforms.

  • Subscribers should stagger large manual jobs and rely on the configured throttle limits for the subscription so that a bulk order update does not overwhelm the Shopware API. If the Shopware API is temporarily unavailable when a transfer is triggered, the transfer fails and an error appears in Dashboard / Integration Monitoring / Error Logs; the record can be retried by triggering a new transfer from iPaaS.com.

Setup Requirements

For automatic transfer, the order data flow that pushes iPaaS.com orders to this Shopware subscription must be configured as an Outbound Data Flow from iPaaS.com to Shopware. The parent Update Shopware Order FROM iPaaS.com collection and any child collections to be used must be enabled, and the Shopware orders to be updated must already exist and be linked to their iPaaS.com counterparts.

Integration Flow

  1. An iPaaS.com order transfer targets this Shopware subscription (automatically via the Outbound Data Flow, or on demand via Manual Sync).

  2. The parent collection resolves the existing Shopware order from the iPaaS.com order (transaction) identity using the saved external id. If no linked Shopware order is found, the update has no target and an error is recorded in Dashboard / Integration Monitoring / Error Logs.

  3. The parent collection translates the incoming iPaaS.com order status into the matching Shopware order state and applies it to the order header, and optionally updates the header-level delivery status, payment status, and shipping-cost values.

  4. Child collections run as part of the same order update: line items are matched to Shopware products by SKU (and added when new), and payment status is applied to the order's payments at the child level when the header-level mapping is left unmapped.

  5. The order remains linked to the iPaaS.com order through its existing external id; no new link is created because the order already exists.

Mappings

Update Shopware Order FROM iPaaS.com

Description: Updates the overall status, delivery status, payment status, and shipping-cost values of an existing Shopware order from iPaaS.com data.

Mapping Type

Source Field (iPaaS.com)

Destination Field (Shopware)

Description

Dynamic Formula

Order (Transaction) identity

Id

required — resolves which existing Shopware order this update is applied to via GetExternalIdAsync. If no linked Shopware order is found, the value resolves to nothing, the update has no target, and an error is recorded in Dashboard / Integration Monitoring / Error Logs.

Dynamic Formula

Status (translated)

StateId

required for an order-status update — sets the overall order state, translating the iPaaS.com status to a Shopware order state name and resolving it via GetOrderTechnicalNameByStatusName. If no Shopware order state has that name, the status is not changed.

Dynamic Formula

Status (translated)

Order_Delivery_Status

optional — sets the delivery (shipment) status, resolved via GetOrderDeliveryTechnicalNameByStatusName. When it resolves to nothing the delivery status is left unchanged. Leave unmapped to update delivery status at the child level instead.

Dynamic Formula

Status (translated)

Order_Payment_Status

optional — sets the payment status, resolved via GetOrderTransactionTechnicalNameByStatusName. When it resolves to nothing the payment status is left unchanged. Leave unmapped to use the Update Shopware Order Payment Status FROM iPaaS.com child collection instead.

Field

TotalQty

ShippingCosts_Quantity

recommended — carries the iPaaS.com order total quantity onto the shipping-cost quantity. Shopware treats the shipping-cost quantity as required when shipping costs are written, so supply a value when this collection updates shipping costs.

Static

"6"

ShippingCosts_UnitPrice

optional — sets the per-unit shipping cost; Shopware treats it as required when shipping costs are written. Placeholder value — replace during implementation: "6" is an example amount, not derived from the order. Replace it with the correct shipping-cost unit price, or remove this mapping if shipping costs should not be changed.

Static

"6"

ShippingCosts_TotalPrice

optional — sets the total shipping cost; Shopware treats it as required when shipping costs are written. Placeholder value — replace during implementation: "6" is an example amount, not derived from the order. Replace it with the correct total shipping cost, or remove this mapping if shipping costs should not be changed.

Static

"3"

ShippingCosts_CalculatedTaxes

optional — sets the calculated tax amount on the shipping costs. Placeholder value — replace during implementation: "3" is an example amount, not derived from the order. Replace it with the correct calculated shipping tax, or remove this mapping if shipping-cost taxes should not be changed.

Static

"2"

ShippingCosts_ListPrice_Price

optional — sets the shipping-cost list price. Placeholder value — replace during implementation: "2" is an example amount, not derived from the order. Replace it with the correct shipping-cost list price, or remove this mapping if shipping-cost list pricing should not be changed.

Static

"2"

ShippingCosts_ListPrice_Discount

optional — sets the shipping-cost list-price discount. Placeholder value — replace during implementation: "2" is an example amount, not derived from the order. Replace it with the correct shipping-cost list-price discount, or remove this mapping if shipping-cost discounts should not be changed.

The StateId, Order_Delivery_Status, and Order_Payment_Status mappings each use a Dynamic Formula that first translates the incoming iPaaS.com status into a Shopware state name, then resolves that name to the Shopware technical name the record requires. The verbatim translation formulas are:

// StateId
var returnStatus = "";
if(Status == "Pending") {
    returnStatus = "Open"
}
else if(Status == "Complete" || Status == "Shipped"){
    returnStatus = "Done";
}
else if(Status == "Cancelled"){
    returnStatus = "Cancelled";
}
else {
    returnStatus = "Open";
}return await GetOrderTechnicalNameByStatusName(returnStatus);
// Order_Delivery_Status
var returnStatus = "";
if(Status == "Pending") {
returnStatus = "Open"
}
else if(Status == "Complete"){
returnStatus = "Shipped";
}
else if(Status == "Cancelled"){
returnStatus = "Cancelled";
}
else {
returnStatus = "Open";
}
return await GetOrderDeliveryTechnicalNameByStatusName(returnStatus);
// Order_Payment_Status
var returnStatus = "";
if(Status == "Complete"){
returnStatus = "Paid";
}
else if(Status == "Cancelled"){
returnStatus = "Cancelled";
}
else {
return null;
}return await GetOrderTransactionTechnicalNameByStatusName(returnStatus);

Update Shopware Order Line Item FROM iPaaS.com

Description: Updates line items on the existing Shopware order from iPaaS.com data and can add new line items, matching each line item to a Shopware product by SKU.

Mapping Type

Source Field (iPaaS.com)

Destination Field (Shopware)

Description

Dynamic Formula

Sku

Identifier

required when new line items may be created — resolves the Shopware product via GetProductIdBySku. If no Shopware product number matches the SKU, the product resolves to nothing and a new line item cannot be added.

Field

Qty

Quantity

recommended — carries the iPaaS.com line-item quantity onto the Shopware line item, so it reflects the ordered amount when line items are added or maintained.

Field

UnitPrice

PriceDefinition_Price

optional — sets the line item's defined price from the iPaaS.com unit price. Optionally configurable to use the Shopware product's gross price instead via GetProductGrossPriceBySku.

Dynamic Formula

Status (translated)

StateId

optional — sets the line-item status, resolved via GetStateIdByOrderLineStateName. When the parent order is cancelled the line item is set to Cancelled regardless of its own status. When it resolves to nothing the line-item status is left unchanged.

The StateId mapping uses the following Dynamic Formula:

if(Parent.Status == "Cancelled"){
  return await GetStateIdByOrderLineStateName("Cancelled");
}var returnStatus = "";
if(Status == "Pending"){
returnStatus = "Open";
}
else if(Status == "Complete"){
returnStatus = "Shipped";
}
else if(Status == "Cancelled"){
returnStatus = "Cancelled";
}
else if(Status == "Shipped"){
returnStatus = "Shipped";
}
else{
    returnStatus = "Open";
}
return await GetStateIdByOrderLineStateName(returnStatus);

Update Shopware Order Payment Status FROM iPaaS.com

Description: Updates the payment status of the payments on the existing Shopware order, translating the incoming iPaaS.com payment status into the matching Shopware payment state.

Mapping Type

Source Field (iPaaS.com)

Destination Field (Shopware)

Description

Dynamic Formula

Status (translated)

StateId

required — carries the only value this collection writes, the Shopware payment state, resolved via GetOrderTransactionTechnicalNameByStatusName. "Pending" and "Authorized" return nothing; "Complete", "Paid", or "Captured" become Paid; "Cancelled" becomes Cancelled. When it resolves to nothing, no payment-status change is applied.

The StateId mapping uses the following Dynamic Formula:

var returnStatus = "";
if(Status == "Pending" || Status == "Authorized") {
return null;
}
else if(Status == "Complete" || Status == "Paid" || Status == "Captured"){
returnStatus = "Paid";
}
else if(Status == "Cancelled"){
returnStatus = "Cancelled";
}
else {
return null;
}return await GetOrderTransactionTechnicalNameByStatusName(returnStatus);

Error Handling

Errors surface in Dashboard / Integration Monitoring / Error Logs.

  • No matching Shopware order found: the order being updated does not exist in Shopware or is not linked to the iPaaS.com order, so the update has no target. Resolution: confirm the order was first transferred and linked between the systems before sending an update.

  • Referenced Shopware state does not exist: an order, delivery, payment, or line-item state name does not resolve to a Shopware state, so that status is left unchanged. Resolution: confirm the referenced Shopware states exist in the target store before enabling the collection.

  • Line-item SKU does not match a Shopware product number: the product resolves to nothing and a new line item cannot be added. Resolution: ensure the line item's SKU matches a Shopware product number when adding line items.

  • Shopware API temporarily unavailable: the transfer fails when the Shopware API cannot be reached. Resolution: retry by triggering a new transfer from iPaaS.com once the API is available.

Testing & Validation

Test Scenarios

  • Transfer an order update for an order that already exists and is linked in Shopware, and confirm the overall order status changes to the expected Shopware state.

  • Send an update for an iPaaS.com order with no linked Shopware order and confirm the update is rejected with an error in Dashboard / Integration Monitoring / Error Logs.

  • Update header-level delivery status and payment status, and confirm they apply to all deliveries and payments on the order subject to the DoNotUpdateOrderDeliveryStatuses and DoNotUpdateOrderPaymentStatuses presets.

  • Transfer an order whose incoming data includes a product not yet on the order and confirm a new line item is added when its SKU matches a Shopware product number.

  • Transfer an order whose line item carries a SKU that matches no Shopware product number and confirm the line item is not added.

  • Cancel the parent order and confirm its line items are set to Cancelled regardless of their own status.

  • Run the payment-status child collection with the header-level Order_Payment_Status mapping left unmapped, and confirm payment status updates at the child level only.

  • Trigger a Manual Sync of an order by its iPaaS.com order id and confirm the update is applied.

Validation Checklist

  • The targeted Shopware order exists and is linked to the iPaaS.com order before an update is sent.

  • The Shopware order, delivery, payment, and line-item states referenced by the mappings exist in the target store.

  • Header-level and child-level mappings are not both active for the same status (delivery or payment); one level is chosen for each.

  • Shipping-cost static placeholder values ("6", "3", "2") have been replaced with correct amounts or removed before relying on this collection to maintain shipping costs.

  • A shipping-cost quantity is supplied when shipping costs are being maintained.

  • Line-item SKUs match Shopware product numbers when line items are being added.

  • The source-of-truth direction is defined when the opposite-direction Add/Update Shopware Order TO iPaaS.com collection is also enabled, to prevent circular updates.

Additional Notes

These limitations are inherent to the current design of the integration and the capabilities of the Shopware API, and they apply to all subscribers at the time this documentation was written.

  • This family updates existing orders only; it does not create orders, payments, or deliveries, and it does not propagate deletions.

  • Each status is resolved to a Shopware state by name at transfer time. If the referenced order, delivery, payment, or line-item state does not exist in Shopware, that status is left unchanged.

  • The shipping-cost values shipped in the parent collection are example amounts. Replace them with the correct shipping costs for the order, or remove those mappings, before relying on this collection to maintain shipping costs.

  • For the payment-status child collection, incoming "Pending" and "Authorized" statuses do not change the Shopware payment status by design; only "Complete", "Paid", "Captured" (to Paid) and "Cancelled" produce a change.

Did this answer your question?