When an order sells one or more gift cards, the integration raises a separate gift card ticket from that order and transfers it into iPaaS.com as its own Transaction of type Ticket. The ticket carries only the gift-card portion of the originating order — the gift card lines, their payments, and the gift-card share of the totals — and it is linked back to the order's Transaction as its parent.

The ticket is identified by an order number ending in -GC. That suffix is applied by the integration itself when it raises the ticket; it is not a store naming convention and subscribers do not configure anything in Magento to produce it.

Four child collections write the ticket's lines, tax, and payments onto the same Transaction. The transfer is unidirectional.

Enter the gift card ticket's record identifier — the originating Magento order record identifier with the -GC suffix appended, for example 1234-GC.

The plain order record identifier without the suffix resolves the originating order rather than the ticket.

After a successful transfer, iPaaS.com stores the gift card ticket's identifier as the external ID on a record linking it to the iPaaS.com Transaction. The ticket's own TransactionNumber carries the suffixed order number, and a separate mapping records the underlying Magento entity identifier.

The ticket is also linked to its originating order: the ParentId mapping strips the -GC suffix from the ticket's identifier and looks up the Transaction created for that order, so the ticket hangs beneath the order rather than standing alone.

Outbound delete is not supported for gift card tickets. Removing an order or ticket in Adobe Commerce/Magento 2 does not remove the corresponding Transaction from iPaaS.com, and delete mappings are not included in the default templates for this family.

Several destination fields in this family are iPaaS.com custom fields rather than standard Transaction fields, and must exist in the subscriber's environment before the mappings that populate them will land:

Status: Enabled. All five collections in this family ship enabled.

Trigger Events: Creation or update of a gift card ticket raised from an order in Adobe Commerce/Magento 2, plus Manual Sync on demand.

Adobe Commerce/Magento 2 has no native webhook capability, so automatic transfers depend on the third-party webhook extension being installed and configured in the Magento store. Manual Sync is always available regardless.

Two other parent collections read the same underlying Adobe Commerce/Magento 2 orders and are separated from this one only by the order-number suffix in their filters:

Because all three families operate over the same underlying orders, the suffix conditions in the three filters are what prevent one record from being processed twice into conflicting Transactions. Subscribers or their MiSP should review all three filters together before enabling or modifying any of them. Loosening the suffix condition on any one collection can cause the same record to be written by more than one.

This family also depends on Add Adobe Commerce/Magento 2 Gift Card TO iPaaS.com. The gift card lines and gift-card payments here resolve a card by its number, so the card must already have been transferred into iPaaS.com or those lines and payments cannot be linked.

This integration implements no selectable collision-handling methods, and the behavior is not configurable on these collections. The external-ID record linking the ticket to its iPaaS.com Transaction decides whether a transfer creates or updates; TransactionNumber acts as the fallback match where no link yet exists.

When a ticket is re-transferred, the mapped values are written again over the existing Transaction. The fields at risk are, on the header, Mage Entity ID, SystemId, TransactionNumber, ParentId, Type, Status, EmailAddress, DiscountAmount, TaxAmount, ShippingAmount, Subtotal, Total, TotalQty and TransactionCreatedDateTime — together with the line, tax and payment values written by the four child collections.

The mitigation is a DestinationValue. Where an iPaaS.com field must hold a specific value that the source ticket does not supply, set a DestinationValue on that mapping so the integration writes the value chosen there instead of taking it from the source. Values that must be maintained only in iPaaS.com should be kept on fields these collections do not map.

The parent collection is Add/Update Adobe Commerce/Magento 2 Gift Card Ticket TO iPaaS.com. It is the parent of four child collections, each of which writes its records onto the Transaction created or updated by the parent and none of which transfers independently of it:

Full step-by-step setup instructions are in the Adobe Commerce/Magento 2 Installation Instructions article, and the webhook extension setup is covered in Configure Mageplaza Webhooks for iPaaS.com.

The gift cards sold on the originating order are transferred into iPaaS.com automatically as a prerequisite of that order's transfer, before any ticket is raised. Prerequisite processing is deliberately skipped for the ticket itself — a record whose number ends in -GC or -D returns immediately, because its prerequisites were already handled by the order it came from.

The practical consequence is that a ticket cannot be relied upon to bring its own gift cards or customer with it. If the originating order failed to transfer, the ticket will be missing both its parent Transaction and, potentially, the Gift Card records its lines refer to.

iPaaS.com data type: Transaction

Mapping Filter

This collection processes only records whose order number ends in -GC, the suffix the integration applies when it raises a gift card ticket from an originating order. Ordinary orders and deposit tickets do not pass and are handled by their own families. Records that do not pass are skipped without error.

Note that, unlike the order and deposit ticket parents, this filter carries no fraud-status exclusion. A gift card ticket raised from an order that Magento later flags as suspect is still processed here.

iPaaS.com data type: Transaction Line

Mapping Filter

This collection writes the ticket's gift card lines. A line passes only when its Magento product type is a gift voucher. Because the ticket exists to represent the gift-card portion of an order, this is the only line collection beneath it — ordinary product lines on the originating order are carried by the order family instead.

iPaaS.com data type: Transaction Tax

This collection carries no mapping filter. It runs against every ticket the parent transfers and writes a single consolidated tax record.

iPaaS.com data type: Transaction Payment

Mapping Filter

This collection writes the ticket's payments for every tender other than gift card. Gift-card tenders are handled by the sibling collection below.

iPaaS.com data type: Transaction Payment

Mapping Filter

This collection writes the ticket's gift card tender payments — that is, where a gift card was used to pay for the gift cards being sold.

Used by the parent collection's Status mapping.

A Magento status with no row here is not translated, no value is sent for Status, and no error is raised. Add a row for every custom status the store uses.

Used by the Method mapping on both payment collections.

Add a row for any payment method the store uses that is not already listed, and confirm each destination value matches a Payment Method configured in the environment. A payment whose method code is missing from this translation will not be matched.

The full catalog of messages this integration produces, with causes and resolutions, is in the Adobe Commerce/Magento 2 Error Messages article. The conditions most often seen on this transfer are:

Errors are reported under Dashboard / Integration Monitoring / Error Logs.