This article describes the known limitations of the Adobe Commerce/Magento 2 integration for iPaaS.com. These limitations are inherent to the current design of the integration and to the capabilities of the Adobe Commerce/Magento 2 REST API, and they apply to all subscribers. Everything described here reflects how the integration behaves at the time this documentation was written; behavior may change in later releases as the integration and the Adobe Commerce/Magento 2 platform evolve.

Each limitation below includes a plain-language What this means for you explanation and, where a different behavior might suit your workflow, a path forward and a route to request an enhancement. None of these are faults in your store or your configuration; they describe the boundaries of what the integration is designed to do today.

This integration is built for Adobe Commerce and Magento Open Source on the Magento 2 platform (referred to throughout iPaaS.com as Adobe Commerce/Magento 2). It communicates with your store through the standard Magento 2 REST Web API, which every Magento 2 store exposes at your store's own base URL. Magento's REST Web API is documented in the Adobe Commerce web API documentation. Magento 2 does not publish a separate, independently versioned public API generation, so the integration is built against the documented production REST Web API rather than a dated API version.

As of the date this documentation was written, the integration was last tested end-to-end against a production Magento 2.3.6 store. Stores on other Magento 2 releases are expected to work, because the integration targets the standard REST Web API rather than a specific point release, but 2.3.6 is the version the current documentation was validated against.

Not built for. To set expectations clearly:

The sections below cover each limitation in turn. Use this list as an overview and scroll to the section that applies to your workflow.

Initialization (a bulk import of the data that already exists in your store when you first connect) is not supported for Adobe Commerce/Magento 2 in iPaaS.com. Records that existed before the integration was installed — products, orders, deposit and gift-card tickets, gift cards, categories, category assignments, and inventory sources — are not back-filled automatically. Once the integration is configured, records transfer on demand and in response to events and scheduled activity. This is described alongside the connection setup in the Adobe Commerce/Magento 2 Connections and Settings article.

What this means for you: Existing data reaches the other system only through a Manual Sync (or, for the catalog, an initial catalog load). Plan an initial load as part of your go-live: run Manual Sync for the records you need in place before day-to-day activity begins, and configure all data synchronization and mappings during setup. If bulk initialization would materially help your onboarding, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP) describing your requirement; input like this informs future enhancement releases.

Each collection moves data in a single direction. Collections that write to your store (from iPaaS.com) do not read product, inventory, category, option, unit, variant, or inventory-source data back from Magento into iPaaS.com. Collections that capture into iPaaS.com (from Magento) do not write those records back to your store. Most records that already exist in Magento are not discovered or linked to iPaaS.com automatically — a product, category, or inventory source created directly in the Magento admin is not matched to an iPaaS.com record on its own. People records are the exception: where no link yet exists, the integration looks for an existing Magento customer with the same email address, and an existing company with the same company email address, and links to it rather than creating a duplicate. Orders behave similarly, matching an existing Transaction by its transaction number where no link is held.

What this means for you: Treat the originating system for each flow as the source of truth for that flow. For products, categories, and inventory sources to be linked across the two systems, they should be created through the integration rather than added independently on each side; where an existing Magento record needs to participate, transfer the corresponding iPaaS.com record so the integration can establish the link. Customers, companies, and orders you already hold on both sides link themselves on the first transfer, so there is no need to re-create them — but keep email addresses and order numbers consistent across the two systems, because those are what the match relies on. If your workflow needs two-way synchronization or automatic discovery of existing Magento records, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

When the integration updates a record that already exists, it sends a full record update on every transfer. Each field that an update collection maps and that arrives with a value overwrites the matching value at the destination each time the record transfers, including a value someone changed by hand. Because the integration sends the whole record rather than only the fields that changed, a field left blank at the source, or a field the update collections do not map, should not be assumed to be automatically preserved. How the destination treats a field that arrives without a value depends on the field, so the safest assumption is that any field the update collections touch is under the originating system's control.

How much is exposed depends on the family. The widest exposure is on the families that maintain a record over time: simple and configurable products with their variants, options, option values and alternate units; product categories; customers and customer addresses; B2B companies; customer groups; shared catalogs; and the inventory sources created from locations. Families that raise a record rather than maintain one — orders written into your store, invoices, and shipments with their tracking — write only the narrow set of fields needed to create that record, so their exposure is limited to those fields; note that re-transferring one of these can repeat an action rather than simply rewriting a field, capturing payment or sending a notification a second time. The inventory collections write stock figures only and touch no other product data. In the capture direction, a re-transfer overwrites the iPaaS.com record the same way, which matters most where both directions are enabled for the same entity. The add-only collections described below do not overwrite an existing record at all. Each family's mapping documentation article lists the exact fields that family writes — treat it as the definitive field list for the collections you enable.

What this means for you: The originating system is the effective system of record for the fields the update collections map, so a manual edit to one of those fields can be replaced on the next transfer. If you need a field to hold a specific value that your source system does not supply, set a DestinationValue on that mapping so the integration writes the value you choose instead of leaving it to the source. Keep values you deliberately maintain by hand on fields the update collections do not map, check the affected family's mapping documentation for the exact list before you rely on a field being untouched, and confirm in a staging environment that those fields behave as you expect before relying on it in production. If your workflow needs finer control over which fields the integration is allowed to overwrite, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

With one exception, removing or clearing a record in iPaaS.com does not delete or archive the corresponding record in Magento. Products and configurable families are not deleted or archived when a product is removed in iPaaS.com; a variant is not removed from a family when it is removed in iPaaS.com; obsolete option values, options, attributes, and alternate-unit variants remain in Magento; and a category cleared in iPaaS.com is not removed. Magento itself does not support deleting an inventory source at all — a source can only be disabled in the Magento admin.

Product category assignments are the exception. A dedicated delete collection ships alongside the add collection, and removing an assignment in iPaaS.com does remove the product's category membership in Magento. One gap applies: if the last remaining category assignment on a product is deleted in iPaaS.com, that assignment is not removed in Magento.

Note: Customer deletion is also supported, but through a separate mapping that is not part of the collections shipped with the integration. Subscribers who need customer deletions to propagate should raise it with their MiSP rather than assume it is unavailable.

What this means for you: For everything other than category assignments, use a record's status to take it off the storefront rather than expecting a deletion to flow through — setting a product or family status is how you hide it from shoppers. Clean up obsolete attributes, option values, and variants in the Magento admin when needed. Keep the category assignment delete collection enabled if you want unassignments to reach Magento, since removals stop propagating without it. To clear an abandoned last-remaining assignment, assign a different category to that product so a later product update can reconcile it. If your workflow needs wider removal propagation, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

Most catalog entities are handled by a pair of collections: an add collection that creates records that do not yet exist in Magento, and an update collection that maintains records that already exist. Neither performs the other's job — the add collection does not update an existing record, and the update collection does not create a missing one.

What this means for you: Enable both the add and the update collection for each entity you synchronize so that new records are created and existing records are kept current. If only one is enabled, you will see either new records that never update or updates that never reach a record that was never created.

Deposit tickets and gift cards are add-only: they are created at the first transfer and are not maintained afterward. A deposit ticket keeps the totals it was first written with even if the underlying Magento order later progresses, is amended, or is cancelled — and its status is not a snapshot of the order at all. Every deposit ticket arrives with a status of Pending, regardless of what state the originating order is in. A gift card is recorded with a fixed Status of Active and with its Balance and original amount both taken from the same point-in-time source balance, so a card already partially redeemed before its first transfer records its remaining balance as its original amount. The gift card collection does not carry a card's later balance adjustments, redemptions, status changes, or transaction history.

Gift card tickets behave differently. That family creates and also maintains its record, so a gift card ticket that transfers again has its header, line, tax, and payment values written over the existing record, and a value edited by hand in iPaaS.com on a mapped field is replaced.

What this means for you: Treat deposit tickets and gift cards as a point-in-time capture, and work them to completion in iPaaS.com or the downstream system rather than expecting later Magento changes to flow through. Do not read a deposit ticket's status as the originating order's state — it is the same value on every ticket, so any process that keys off it needs the order's own status instead. Gift card redemption activity is handled by the gift card activity workflow, not by the add collection, and cards that need to be deactivated or expired are managed in iPaaS.com. If you backfill older cards where the originally issued value or a non-Active status must be exact, review those records after the initial load. For gift card tickets, where an iPaaS.com field must hold a value the source ticket does not supply, set a DestinationValue on that mapping, and keep any value you maintain only in iPaaS.com on a field these collections do not map. If your workflow needs deposit tickets or gift cards to stay in step with later Magento changes, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

Many collections are children of a parent record and have no transfer schedule or Manual Sync entry of their own. Order and ticket lines, payments, tax records, and addresses move only as part of their parent order or ticket; a configurable product's options, option values, units, variants, and per-source inventory move only as part of the product transfer. A change recorded in Magento against one of these children after its parent has already synced arrives only on the next transfer of that parent. A child record can also arrive unlinked — for example, a ticket whose originating order has not yet synced arrives without a parent link rather than failing.

What this means for you: To re-send a line, payment, tax record, address, option, or inventory row, run a Manual Sync of its parent order or product rather than looking for the child on its own. Confirm parent records transfer successfully, and review unlinked tickets to confirm their originating order transferred. Where a stock-only refresh is needed without a full product transfer, use the standalone real-time inventory collections described below.

Magento 2 does not natively provide webhooks. Automatic, event-driven transfer of records into iPaaS.com therefore depends on webhook delivery from a third-party Magento extension, configured in your store rather than in iPaaS.com. If webhook delivery is delayed, or the extension is unavailable, records raised during that window arrive late. Gift cards sold on an order are brought across as part of that order's transfer regardless of webhook delivery, so they do not depend on the extension the way a card issued on its own does.

What this means for you: Install and maintain the third-party Magento extension covered in the Adobe Commerce/Magento 2 Installation Instructions if you rely on real-time inbound transfers. When automatic delivery is delayed or a record does not arrive, Manual Sync of the affected order, ticket, or gift card is the recommended recovery path. Because this is a Magento platform characteristic rather than an integration setting, the polling-and-extension model is the correct shape for real-time updates from Magento. If native, extension-free real-time delivery becomes important to your workflow, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

Every inventory transfer replaces the quantity held at the target inventory source. There is no incremental or delta mode, so a stock figure adjusted directly in the Magento admin is replaced by the value the integration sends on the next transfer.

What this means for you: Keep iPaaS.com authoritative for stock levels, and make stock corrections in the source system rather than in the Magento admin, since a manual Magento adjustment is overwritten at the next inventory transfer. If your workflow needs delta-based stock adjustments, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

Inventory quantities are floored to whole units on most inventory paths: a small fractional balance is reported as zero, which marks the product or variant out of stock at that source. Alternate-unit quantities are divided by the applicable conversion factor and then floored, so partial units are never shown as available — for example, a conversion factor of 12 against 100 stocking units on hand shows 8 available.

Note: The standalone real-time inventory add collections apply no whole-unit floor, while the inventory collections that run as part of the product transfers and the paired standalone update collections do. The same fractional source quantity can therefore produce different storefront availability depending on which path processed it, and both paths can be enabled at once.

What this means for you: Expect availability to be reported in whole units. If you run both the standalone real-time inventory collections and the inventory collections that run under the product transfers, be aware that they can round the same fractional quantity differently; choose a single path where consistent availability matters. If your workflow needs fractional availability, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

An inventory transfer writes stock to a specific inventory source. It does not refresh a product's aggregate on-hand total or its product-level stock status, and a variant inventory transfer does not refresh the stock status of the configurable product the variant belongs to. Stock written to a configurable container alone does not make a family purchasable — a family whose variants carry no stock remains unpurchasable on the storefront regardless of the quantity on the parent.

Note: This follows Magento's own handling of configurable products: a variant out of stock at every source is removed as a storefront option, and where every variant of a configurable product is out of stock, the configurable product itself becomes unpurchasable.

What this means for you: To bring a product's aggregate total or a configurable parent's stock status back into line with its variants, run a full product update rather than relying on the inventory collections alone. Ensure the variants carry stock so the family is purchasable.

Three collections ship disabled and transfer nothing until their mapping filter is edited: the configurable product inventory stock-status collection, the simple product inventory totals collection, and the simple associated product variant inventory totals collection. A subscriber who is unaware of this sees no error and no transfer activity — the affected records are simply skipped. While these collections are disabled, inventory-only movements refresh the individual Magento inventory sources but never the parent product's aggregate total or stock status, because the main product update collections exclude those inventory-only records whether or not the totals collections are enabled.

What this means for you: If you need parent-level totals and stock status kept current from inventory-only movements, enable the relevant totals or stock-status collection. Two steps are needed, not one: remove the leading condition that holds the collection off from its mapping filter, and switch the collection on in the interface. Doing only one of the two leaves it processing nothing, with no error to tell you. Because there is no error when they are disabled, confirm during setup whether your workflow relies on them. If your workflow needs these to be active by default, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

Inventory location handling depends on a Lookup Translation you configure that maps each iPaaS.com location to its matching Magento inventory source. A location that is missing from iPaaS.com silently lowers the calculated total rather than raising an error, so a product can be marked out of stock on the basis of an incomplete set of locations. A location that matches no row in the translation produces no error at the iPaaS.com end; the condition surfaces only as a Magento rejection of that inventory row, reported under Dashboard / Integration Monitoring / Error Logs, which identifies the transfer but not the unmatched location.

What this means for you: Keep the location translation complete, and audit it against your store's configured inventory sources before go-live and whenever locations change. When a stock figure looks wrong or an inventory row is rejected, check the translation for a missing or unmatched location as part of your diagnosis.

Several fields resolve through Lookup Translations that you configure for your environment — product and order status, tax class, and payment method among them. An unmatched value is generally handled quietly rather than raised as an error: an unmatched product or order status leaves the status field unset; an unmatched tax class falls back to Taxable Goods; and an unmatched payment method leaves the payment Method unset. Where the destination requires the field, the record is then rejected and the rejection is reported under Dashboard / Integration Monitoring / Error Logs — but the reported failure names the missing value rather than the missing translation row.

What this means for you: Complete every Lookup Translation your enabled collections use during setup, and audit each translation against the values your store actually uses (statuses, tax classes, tenders). Because most unmatched values do not raise an error, detect gaps by reviewing transferred records, and when a record is rejected for a missing value, check the corresponding translation first.

For configurable products, the Magento attribute code for each option is generated from the option name. This has several consequences. Renaming an option in iPaaS.com after products are live produces a different attribute code and therefore a second Magento attribute rather than a rename; the original attribute is neither renamed nor removed. The code is produced by trimming the option name and replacing each space with an underscore; everything else in the name, including punctuation and accented characters, is carried through exactly as it stands. Two names that differ only in their spacing therefore reduce to the same code and are treated as one option. An option name that reduces to a Magento-reserved attribute code cannot be used, and on the update collection such a name fails the transfer rather than being adjusted automatically. The option's input type is re-asserted as a dropdown on every run, and a label edited directly in the Magento admin is display text only — it does not rename the code and is overwritten the next time the option transfers.

What this means for you: Settle option names before products go live, and avoid renaming an established option in iPaaS.com. Because nothing is stripped out of the name, keep option names to plain letters, numbers, and spaces so the code they generate is one Magento will accept, and keep the spacing consistent so two names do not collapse onto the same code. Also, make display-label changes in the Magento admin knowing they will be re-asserted, and remove any duplicate attribute left behind by a rename in the Magento admin. If your workflow needs option renames to update the existing attribute in place, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

Configurable option values are matched by exact text, including case: a casing difference in a value creates a second option value rather than matching the existing one, and the duplicate is not detected automatically. Separately, a numeric option value label can be rejected by Magento as already existing when it is not. An option value with no sort order recorded in iPaaS.com transfers without one, and Magento applies its own ordering; a sort order corrected in iPaaS.com after a value already exists is not written back over the existing value by the add collection.

What this means for you: Standardize the casing of option values in your source data so the same value matches rather than duplicating. When a numeric option value is rejected as already existing, create that value by hand in the Magento admin and re-send. Manage sort-order changes for existing values through the Magento admin or the paired update collection. If your workflow needs case-insensitive matching or automatic numeric-value handling, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

Alternate units of measure are handled through per-variant override maps rather than free-form SKUs, which introduces several constraints. A variant SKU is derived from the base variant SKU and the applicable unit name; there is no SKU override. A variant SKU that is missing from any populated override map stops the transfer for that whole product rather than skipping only that variant, so adding a variant to a family requires every override map in use for that family to be updated at the same time. Renaming a unit produces an additional variant SKU rather than renaming the existing variant, and the obsolete variant is not removed automatically. A variant SKU containing a comma or a semicolon cannot be used with the per-variant overrides, because those characters separate the entries in the map. A missing or misnamed override custom field produces no value and no error. The barcode attribute the unit collections write into must already exist in Magento with global scope, and unit prices are not scaled from the base price — a unit with no price in iPaaS.com transfers without one.

What this means for you: Keep every override map for a family complete and updated together whenever variants change, and avoid commas and semicolons in variant SKUs that use overrides. Pre-create the barcode attribute with global scope before enabling these collections. Because a missing or misnamed override field is silent, verify the transferred variants in Magento after the first run. If your workflow needs more flexible unit or SKU handling, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

A special price applied by the product collections takes the transfer date as its start date and carries no end date. It reaches the variants as well as the parent: a variant uses its own sale price where it has one and falls back to the parent's where it does not, and in either case the special price is only applied when that sale price is below the regular price and above zero. On an update, the special-price start date advances to the transfer date each time a qualifying discount is re-sent, and a special price set by hand in Magento is removed by the next update whenever the source record presents no qualifying discount.

What this means for you: Manage scheduled promotions — those with a future start date or a fixed end date — directly in Adobe Commerce/Magento 2, since the integration always starts a special price on the day it transfers and never sets an end date. Be aware that a manually set Magento special price can be cleared by a later update. Because shipping and pricing are quoted against the selected variant, check that a discount intended to change what a shopper pays has produced a special price on the variants and not only on the family record. If your workflow needs scheduled special pricing from the integration, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

A product, family, or variant whose weight is blank in iPaaS.com arrives in Magento with a fallback weight of 1, interpreted in whatever weight unit the Magento store is configured for. On an update this fallback is written on every transfer, so a weight corrected by hand in Magento is reset on the next transfer while the source weight remains blank. A product shipped on the fallback weight can be quoted incorrectly.

What this means for you: Populate a real weight in your source data for anything where shipping accuracy matters, rather than relying on the fallback. For configurable families this applies to the variants in particular: shipping is quoted against the selected variant, and variants use the same fallback, so a variant with no weight recorded in iPaaS.com also arrives weighing 1 and will be quoted on that figure. Populate weights on the variants, not only on the family record.

Category handling has several behaviors worth knowing before go-live. A category on a product that cannot be resolved to a Magento category is simply not assigned; on the update collection, because the resolved list replaces existing assignments outside the parent-item case, an unresolved category is dropped from the product rather than retained. A category whose parent has not yet been transferred is created at the root of the Magento catalog tree rather than failing, and no error is raised. The active state is sent as a fixed value, so every category the integration transfers arrives enabled regardless of any staging intent in iPaaS.com. The display order falls back to 0 whenever the sort-order field is absent, empty, or not a whole number. There is no back-fill of categories that already existed in Magento, so a first run against a store with an existing tree can create parallel categories alongside the ones already there. Category descriptions, images, menu placement, page layout, and SEO fields remain admin-maintained.

Shared Catalogs (an Adobe Commerce B2B feature) are handled, but by a separate collection rather than by the ordinary category mappings: catalogs are created from the iPaaS.com product category records you flag as shared catalogs, and categories are assigned to them. The ordinary category collection can additionally carry a category's shared-catalog membership and its B2B store view. What the integration does not decide is which products a catalog contains or which companies can see it — both are granted in the Magento admin. The shared catalog collection also ships with fixed example values for its store view, tax class, and catalog type; see Placeholder Values to Replace Before Go-Live below.

What this means for you: Transfer parent categories before their children and before the products that reference them, so categories resolve and land in the right place. Expect transferred categories to arrive enabled, and review the resulting category tree after a first run against a store that already has categories. Subscribers whose store relies on Shared Catalogs should replace that collection's shipped store view, tax class, and catalog type before enabling it, and should plan to grant catalog product membership and company access in the Magento admin. If your workflow needs staged (disabled) category creation, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

A configurable parent that is created, or left, without at least one associated option attribute renders as an unusable product on the storefront. Because the option data is written by a separate child collection, this condition is not reported against the parent product transfer.

What this means for you: Ensure the configurable product's options and option-values child collections run so that every configurable parent has at least one option attribute associated with it. Because the parent transfer does not report the problem, confirm on the storefront that new configurable products are usable after their first transfer.

Some date fields record when the transfer ran rather than when the underlying event occurred. An order's transaction created date records when the transfer ran, not when the order was placed in Magento; a gift card's purchase date records the transfer date, not the Magento purchase date; and an inventory totals updated-date records when the integration last wrote to the record, not when the underlying stock changed. For records that transfer as soon as they are created, the two dates are the same, but for records loaded in a backfill they are not.

What this means for you: Where the original Magento date matters — the order date on a Transaction, or a gift card's true purchase date — replace the relevant mapping with one that reads the source record's own created date. If your workflow needs the original event date to be carried by default, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

Addresses moving from Magento into iPaaS.com carry only the first three street lines; a fourth or later street line configured in the store is not carried across. On this path addresses are not validated, standardized, or geocoded — values are transferred as the Magento order holds them, and a value missing in Magento transfers as an empty field rather than raising an error.

Addresses moving the other way, from iPaaS.com into Magento, behave differently. The recipient name, city, and postal code are required. The region is checked against the address country, and where it does not match a region that country recognises it is left blank rather than raising an error. The three iPaaS.com address lines reach Magento joined into a single street value rather than as separate lines.

What this means for you: Keep addresses within three street lines where the full address must reach iPaaS.com, and validate or standardize addresses in your own process if you require it on that path, since the integration passes them through as-is. Where addresses flow into Magento, supply a region that matches the country — a mismatch is dropped silently, so an address can arrive with no region and no error to explain it. Because missing values are silent in both directions, review transferred records when address completeness matters.

The shipping method that reaches iPaaS.com is a fixed value configured on the shipping-address collection you enable, not a value read from the Magento order. Two orders that used different underlying carriers but share the same Magento shipping description arrive with the same shipping method value. A shipping description that does not exactly match a specific collection's filter is routed to the catch-all shipping-address collection with no error, and that catch-all applies one shipping method value to every order it handles. The shipping description filters and shipping method values shipped with these collections are examples that you replace for your store; see Placeholder Values to Replace Before Go-Live below.

What this means for you: Configure the shipping-address collections' filters and shipping method values to match your store's carriers and shipping descriptions before go-live. Because a description that does not match a specific filter is handled silently by the catch-all, review transferred Transaction address records to confirm orders are routed as you intend. If your workflow needs the actual carrier read from each order, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

Tax is transferred as one consolidated record per order or ticket by design. The integration does not itemize tax by jurisdiction, and it does not carry a line-level tax amount. It reports the figures Magento already calculated rather than calculating tax itself. A record with no applied-tax detail receives the built-in default taxing authority rather than an empty authority name, so zero-tax orders and tickets carry that default name.

What this means for you: Where your reporting depends on a per-jurisdiction or per-line tax breakdown, source it from Magento directly, since it does not reach iPaaS.com through this transfer. Expect the default taxing authority name on zero-tax records. If your workflow needs a per-jurisdiction or line-level tax breakdown, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

Payments carry the method, amount, status, and the raw Magento method code. A gift-card payment additionally carries the card code, its authorization reference, and a link to the gift card record in iPaaS.com. No card numbers, tokens, or other cardholder data are transferred in any case. The integration does not capture, refund, or void anything in Magento, and it does not transfer refunds, credit memos, or chargebacks. A payment's amount subtracts the value of any gift cards sold on the same record from every payment it writes. A gift-card payment that references a gift card not yet present in iPaaS.com cannot be linked and is rejected. On gift card tickets, every payment the integration writes carries the same amount — the total value of the gift cards sold on the ticket, not the amount actually drawn from a redeemed card. Payment status depends on the tender: a gift-card tender is always recorded as paid, while any other tender is recorded as paid only once an amount has actually been paid and as authorized until then.

What this means for you: For reconciliation where precision matters — records that mix gift card sales with other merchandise, or that accept more than one tender — validate the resulting payment amounts in a staging environment before relying on them. When a gift-card payment is rejected because the card is not yet in iPaaS.com, re-transfer the originating record after the gift card has synced. Source refund, credit-memo, and chargeback detail from Magento directly. If your workflow needs refunds or per-tender amounts carried through the integration, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

A few line-level behaviors are worth knowing. A line whose SKU does not resolve to an existing iPaaS.com product or variant fails rather than transferring unresolved; the remainder of the order or ticket may still transfer, so a Transaction can arrive with fewer lines than the Magento order contains. Lines rely on the catalog collections having already transferred the product they refer to. The component sub-lines of configurable or bundle products are not transferred. Net unit price is derived the same way on almost every line type. Standard product lines, deposit ticket lines, and gift card ticket lines all subtract the per-unit share of the line discount — the line discount divided by the ordered quantity — which cannot produce a meaningful per-unit value when the ordered quantity is missing or zero. The gift card line on an order is the single exception: it subtracts the full line discount without dividing it across the quantity. A discounted gift card can therefore show one unit price on the order and a different one on the gift card ticket raised from that order.

What this means for you: Keep the product catalog current in Magento before transferring orders and tickets, so lines resolve rather than fail; when a Transaction is missing lines, check the error logs under Dashboard / Integration Monitoring / Error Logs for an unresolved SKU. Confirm the ordered-quantity source is populated on every line where unit-price accuracy matters, and expect a discounted gift card to compute a different unit price on the order than on its ticket — validate the values in a staging environment before relying on them downstream. If your workflow needs configurable or bundle sub-lines, or a single unit-price method across line types, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

Where a product is built from component stock, the buildable quantity is totalled one location at a time. The figure sent for an inventory source reflects only the component stock available at that same source, so a kit whose components are spread across several locations reports a lower buildable quantity at each individual source than the catalog holds overall. Some inventory paths do not apply component totalling at all and instead use the location's own available quantity.

What this means for you: Expect per-location buildable figures for kits and bundles rather than a single catalog-wide number, and take that into account when interpreting storefront availability for products assembled from components. If your workflow needs component availability totalled across all locations, submit a feature request through your iPaaS.com partner channel (subscribers or their MiSP).

Several collections ship with example values that stand in for settings each store supplies during implementation. Replace the values below before enabling the affected collections. Not every fixed value in the integration belongs on this list: the gift-card and deposit constants and the other fixed integration values are working settings you do not change, and a further group of mappings ship carrying a worked example that you adapt rather than replace — those are collected under Example mappings to adapt after this section.

Locations to update:

Note that the two filters that exclude gift-card lines test that the product type is not the gift-card code, while the two that select gift-card lines test that it is. Check which form each condition uses before editing it, so the two halves stay complementary and no line is either processed twice or skipped by both collections.

A second group of mappings ship carrying a worked example rather than a value every store shares. These are not placeholders in the sense above: nothing is broken if you leave them as delivered, each has a sensible shipped behavior, and none of them blocks go-live. They encode one store's process, so adapting them to your own is a normal part of implementation. Each is edited in the iPaaS.com mapping interface, and each can also be driven per record through a custom field.

Top-level documentation for this integration:

Each mapping collection family has its own article covering the fields it writes, the setup it needs, and how to verify it:

Catalog

Inventory and locations

Orders and fulfillment

Customers and B2B

Gift cards and tickets

This article covers 28 known limitations of the Adobe Commerce/Magento 2 integration, together with the shipped values to replace before go-live and the shipped example mappings to adapt. For the detailed, per-collection technical documentation behind each behavior, see the mapping documentation articles listed above and the mapping collection descriptions in iPaaS.com; for connection and configuration guidance, refer to the Adobe Commerce/Magento 2 Connections and Settings article.