A paid Clover order is transferred into iPaaS.com as a transaction. Clover refers to these records as orders; in iPaaS.com they are stored as transactions, and the entity label stays Transaction throughout this documentation to match the collection type. The parent transaction and its billing address, payment, and order line detail all transfer together as one connected set of records. Automatic capture is by transaction polling, and a manual sync of a single order is always available.

For a manual transfer, the subscriber enters the Clover order identifier so the integration knows which order to fetch. Clover order identifiers are alphanumeric values shaped like the order's native Clover id, for example a value such as A1B2C3D4E5F6G.

The billing address, payment, and line child records do not accept an identifier of their own on the Manual Sync page. They transfer as part of the parent order, so re-syncing a single order by its Clover order identifier re-syncs the whole set.

The integration tracks each transferred order by a dedicated external identifier that mirrors the Clover order id. This external identifier is the primary key the integration uses to recognize an order it has seen before and to match it on a later transfer. The transaction number written into iPaaS.com provides subscriber-facing visibility and serves as a fallback matching key; it is not the primary external identifier.

Each child record carries its own external identifier so it can be matched on later transfers: the billing address uses a composite identifier built from the Clover order identifier and the address identifier together, the payment mirrors the Clover payment id, and each line mirrors the Clover line item id.

Outbound delete is not supported for this flow. When a Clover order is deleted, that deletion does not propagate to iPaaS.com, and delete mappings are not included in the default templates for these collections. A transaction that has already transferred remains in iPaaS.com even if its originating Clover order is later removed. At the time this documentation was written, removing a record on either side is a manual reconciliation task rather than an automated one.

Status: Enabled. All five collections in this flow (the two parents and three children) are enabled.

Trigger Events: Create and Update. Automatic capture is by transaction polling: the integration checks Clover for new and updated orders on its polling schedule and transfers the ones that qualify. A manual sync of a single order is always available.

The Add Clover Transaction TO iPaaS.com and Update Clover Transaction TO iPaaS.com collections both write to the iPaaS.com transaction from the same Clover order entity. The Add collection creates new transactions; the Update collection refreshes existing ones. Subscribers or their MiSP should avoid configuring any additional collection that writes to the same iPaaS.com transaction from Clover, so that one transfer does not overwrite another. Likewise, no second address, payment, or line collection should be configured against the same transaction records.

This integration does not offer configurable collision handling on the transaction collections. There is no subscriber-selectable conflict-resolution method to choose. Duplicate prevention is handled instead by the external identifier described under ID Format: the integration matches an order it has seen before by that identifier and updates the existing transaction rather than creating a second one.

When the integration prepares to write an order and finds more than one Clover order sharing the same external reference, it will automatically remove matching open duplicates, but it will not remove orders that have already progressed past open. In that case it stops and raises an error that requires manual attention in Clover. See the Error Handling section for the exact message and the resolution steps.

The parent collection is Add Clover Transaction TO iPaaS.com. It supports three child collections that transfer automatically with the order:

The Update Clover Transaction TO iPaaS.com collection refreshes the transaction header only. The child collections are configured under the Add parent collection.

Monetary amounts in Clover are stored in the smallest currency unit (cents), and order and line quantities are stored in thousandths. The integration converts monetary amounts to standard currency by dividing by 100 and quantities to whole units by dividing by 1000, so the values that land in iPaaS.com are already in familiar units. Clover order timestamps are stored as Unix time and are converted to a standard date and time during the transfer.

Only orders whose Clover payment state is PAID transfer; orders in any other payment state are excluded. Address parts, the item name on a line, and other order details transfer only when Clover supplies them on the order.

When Clover reports that too many requests have been made in a short period, the integration automatically pauses and retries the affected calls; no subscriber action is required.

The transaction number must be unique within iPaaS.com. Because the Add collection creates new transactions, a Clover order identifier that already exists as a transaction number can be handled as a conflict; such orders are better served by the Update collection.

The billing address is written as both the primary billing and primary shipping address on the transaction. If a downstream process expects a separate shipping address, account for the fact that this integration transfers a single order address in both roles. The address country is always recorded as United States because it is a fixed value rather than read from the Clover order.

Each transferred line carries a fixed product identifier (CLOVER-PRODUCT) rather than a Clover-specific product code, so subscribers should identify an item by its line description rather than by that value. The payment method is recorded as a generic Other value because Clover does not surface a specific tender type through this transfer.

Before an order is written, the integration reads the order's customer from Clover and looks that customer up in iPaaS.com. If the customer does not yet exist in iPaaS.com, the integration transfers the customer first, automatically, as a prerequisite. Subscribers do not need to pre-sync customers by hand. If the prerequisite customer transfer fails, the order transfer is blocked and will not complete until the customer issue is resolved.

These collections write the order as a full-object update that ignores null values, so fields the integration does not send are preserved on the iPaaS.com record. However, every field a collection does map is overwritten with the Clover value on each transfer. If a subscriber maintains a value in iPaaS.com that should not be replaced by the Clover source on the next transfer, they should set that field using a fixed destination value rather than mapping it from the Clover source.

The Add collection derives the transaction number from the Clover order identifier, while the Update collection prefers the Clover order title and falls back to the identifier only when no title is present. When a Clover order carries a title, the number written on update can therefore differ from the number written when the order was first added. Subscribers should validate in a staging environment that an update still matches the transaction the Add collection created for orders that carry a Clover title, before relying on this behavior in production.

Both Subtotal and Total are set from the same Clover order total. The subtotal therefore equals the gross order total — including any tax and shipping — rather than a tax-exclusive subtotal. Subscribers whose downstream processes expect the subtotal to exclude tax or shipping should validate this behavior in a staging environment before relying on it in production.

The Clover integration must be installed and authorized for the subscription, with valid Clover credentials in place. No webhook configuration is required for this flow; automatic capture is by transaction polling. See the Clover Installation Instructions for credential setup and the polling schedule configuration.

No subscriber-facing setup is required on the iPaaS.com side beyond installing and authorizing the integration and enabling the collections. The order's customer must be transferable to iPaaS.com, because the customer is fetched and transferred first automatically when it does not already exist.

To transfer a single order on demand, open the Manual Sync page in iPaaS.com and enter the Clover order identifier.

After the transfer completes, the order appears in iPaaS.com as a transaction with its header, billing address, payment, and line items populated from the Clover order.

Each collection is presented below with its live mapping filter (where one exists), a plain-language description, and its field mapping table. Monetary conversions divide Clover cents by 100; quantity conversions divide Clover thousandths by 1000.

iPaaS.com data type: Transaction

Mapping Filter

Filter Description. Only Clover orders whose payment state is PAID pass this filter and create a transaction in iPaaS.com. An order in any other payment state is skipped silently and does not appear in the Error Logs. This ensures that only completed, paid orders create transactions.

iPaaS.com data type: Transaction

Mapping Filter

Filter Description. As with the Add collection, only Clover orders whose payment state is PAID are refreshed in iPaaS.com. An order in any other payment state is skipped silently. This collection maps a smaller set of header fields than the Add collection, focused on the values most likely to change between transfers. It does not re-transfer tax or subtotal; those are set when the order is first created.

iPaaS.com data type: Transaction Address

This child collection transfers the billing address from the Clover order onto the transaction, marking it as both the primary billing and primary shipping address. It creates the address the first time and updates it on subsequent transfers. It has no mapping filter; every billing address on a qualifying parent order is processed.

iPaaS.com data type: Transaction Payment

This child collection records the order's payment on the transaction: the paid amount plus a fixed method, description, and status. It has no mapping filter; every payment on a qualifying parent order is processed.

iPaaS.com data type: Transaction Line

This child collection creates a transaction line for each Clover order line item, with its description, quantity, unit price, and extended price plus a fixed line type, status, and product identifier. It has no mapping filter; every line on a qualifying parent order is processed.

The errors below can surface during this flow. All errors appear in the iPaaS.com Dashboard under Integration Monitoring and then Error Logs. Records skipped by the payment-state filter (an order not yet in PAID state) are filtered silently and do not appear in the Error Logs. For the full error catalog, see the Clover Error Messages article.