The integration raises a deposit ticket from an Adobe Commerce/Magento 2 order and transfers it into iPaaS.com as its own Transaction of type Ticket. The ticket carries the non-gift-card portion of the originating order — its ordinary product lines, its tax, and its payments — and is linked back to the order's Transaction as its parent.

The ticket is identified by an order number ending in -D. 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 family is add-only — it creates deposit tickets and does not maintain them afterwards. The transfer is unidirectional.

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

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

After a successful transfer, iPaaS.com stores the deposit 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 -D 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 deposit 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 of a deposit 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.

A deposit ticket is raised for every order that reaches iPaaS.com, not only for orders that took a deposit. Subscribers or their MiSP should expect one ticket Transaction per order and size their expectations for volume and downstream processing accordingly. Where only some orders should produce a deposit ticket, that condition must be applied through this collection's mapping filter.

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 where a deposit is paid by gift card: the gift-card payment child resolves a card by its number, so the card must already have been transferred.

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.

Because this family is add-only, a ticket already present in iPaaS.com is not overwritten by a later transfer.

The add-only setting means an existing deposit ticket Transaction is not overwritten, so the usual re-transfer overwrite risk does not apply here. The fields written on creation 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 consequence runs the other way: because later changes are not sent, a deposit ticket does not track subsequent changes to the originating order. A ticket reflects the order as it stood when the ticket was raised.

The mitigation is a DestinationValue. Where an iPaaS.com field must hold a specific value that the source record does not supply, set a DestinationValue on that mapping so the integration writes the value chosen there instead of taking it from the source.

The parent collection is Add Adobe Commerce/Magento 2 Deposit Ticket TO iPaaS.com. It is the parent of four child collections, each of which writes its records onto the Transaction created 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.

Prerequisite processing is deliberately skipped for the ticket itself. A record whose number ends in -D or -GC returns immediately, because its prerequisites — the customer, and any gift cards sold — were already handled by the originating order's transfer.

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

iPaaS.com data type: Transaction

Mapping Filter

This collection processes only records whose order number ends in -D, the suffix the integration applies when it raises a deposit ticket. The second condition excludes anything ending in -GC, keeping gift card tickets out. The two fraud conditions exclude records Magento has flagged as suspect, so they do not reach downstream fulfillment or financial systems. Records that do not pass are skipped without error.

Subscribers or their MiSP whose store uses custom fraud-review statuses beyond Magento's two built-in values should extend this filter to exclude those statuses as well. This is also the filter to extend where only some orders should produce a deposit ticket.

iPaaS.com data type: Transaction Line

Mapping Filter

This collection writes the ticket's ordinary product lines. A line passes only when it is a top-level line — which excludes the duplicate child lines that configurable and bundle products generate in Magento — and only when its product type is not a gift voucher, since gift cards belong to the gift card ticket family.

Note that this collection maps no line-level tax amount, where the equivalent order line collection does. Line tax reaches the ticket only through the consolidated tax record below.

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.

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 the deposit.

Used by the Method mapping on both payment collections. The parent collection uses a fixed status rather than a translation, so no status translation applies to this family.

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.