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

Deleting a record in the source system does not remove the corresponding record in the destination system. Deleting a customer, order, or product in Square does not remove the iPaaS.com record, and deleting a product, variant, option, or option value in iPaaS.com does not remove the corresponding record in Square.

What this means for you: the integration keeps records aligned as they are created and updated, but removals are not propagated. Remove records directly in the system where they should no longer appear. For products written to Square, removing part of a product in iPaaS.com is reflected only when the whole product is next transferred.

Every Square order is recorded in iPaaS.com with the status Complete and the type Order, and every order line is recorded with the status Complete and the type Product, regardless of the order's actual state in Square.

What this means for you: the recorded transaction and line status do not distinguish open, completed, or canceled Square orders. If your workflow depends on the order's live Square state, review the Status and Type mappings on the Order and Order Line Items collections before relying on the recorded values, and submit a feature request to your iPaaS.com partner channel describing the states you need reflected.

A Square order is transferred only after every product on its line items already exists in iPaaS.com. An order whose line items reference a SKU that is not yet an iPaaS.com product or product variant is held back until that product is created.

What this means for you: keep your product data current in iPaaS.com so orders are not delayed. Create a product for every SKU that can appear on an order, including static SKUs for non-catalog charges such as fees or surcharges. A held-back order transfers automatically once the missing products exist.

iPaaS.com requires an email address to record a customer, but Square allows a customer profile without one. A Square customer that has no email address cannot be transferred.

What this means for you: confirm your Square customers carry an email address before relying on automatic transfers. Orders placed by a customer with no email address are attributed to a fallback customer instead (configured during implementation).

When a product is written to Square, its iPaaS.com categories are matched to existing Square categories by name and by the full parent chain. A category with no exact match — including any ancestor that does not match — is left off the Square item.

What this means for you: create the matching category hierarchy in Square before relying on category assignment, so products are filed correctly. Categories that do not match exactly are simply not assigned; no error is raised.

Product options and their values are matched to Square using the Match Different Case Product Options and Values subscription setting. When that setting is off, matching is case-sensitive and an option or value that differs only in letter casing can be reported by Square as a duplicate.

What this means for you: set Match Different Case Product Options and Values to match how your Square catalog is maintained. Turning it on reuses existing Square option names regardless of case and preserves existing option-value colors when the incoming data does not include them.

When a product has more than one option (for example, Size and Material), each variation must specify a value for every option, listed in the same order the options are defined on the product. Square rejects the product if a variation omits an option or lists them in a different order.

What this means for you: ensure each variation in iPaaS.com carries a complete, correctly ordered set of option values before transferring products with multiple options.

iPaaS.com applies a full-record update when it revises an existing record, so a destination field that is not mapped is cleared on each transfer. On the Order collection, ShippingAmount is not mapped. On the Customer Address collection, Address3, Company, FirstName, LastName, PhoneNumber, Type, IsPrimaryBilling, and IsPrimaryShipping are not mapped.

What this means for you: if you populate any of these iPaaS.com fields by other means, they will be overwritten with empty values on the next transfer unless you preserve them. To keep an existing value, add a Dynamic Formula mapping that uses the DestinationValue function — for example, map DestinationValue.ShippingAmount to the ShippingAmount field, or DestinationValue.Type to the address Type field.

The integration does not support initialization — a one-time bulk import of all existing records on first connect. Records are transferred as they are created or updated, and on demand from the Manual Sync page.

What this means for you: to load a large set of existing records, use the supported bulk sync using Postman workflow rather than expecting an automatic historical import.

To update an existing variation, Square requires the variation's current catalog version, and the integration supplies the version it recorded on the variation's last transfer. Child records — line items, payments, discounts, options, option values, and variation options — are written as part of their parent's transfer and are not independently triggerable; the parent order or product is refreshed as a whole.

What this means for you: if a variation is changed directly in Square outside the integration, its recorded version can fall behind and the next update may be rejected until the product is re-synced from iPaaS.com. Re-transfer the parent product to bring the variation back into alignment. To change a child record (a line, payment, discount, option, or option value), re-transfer its parent order or product rather than expecting the child to transfer on its own.

The default mappings ship with example values that each subscriber must replace during implementation. Confirm all of the following before enabling the affected collections:

What this means for you: these values are examples, not defaults you can leave in place. Review each one with your MiSP or implementation partner before go-live; an unreplaced placeholder causes affected transfers to fail or to record data against the wrong customer.

This document covers 11 known limitations of the Square integration. For detailed technical documentation of each mapping collection, see the Square Mapping Collections articles.