Tax: the order-level total is captured onto the transaction by this collection, the combined per-order tax detail by the Sales Order Tax collection, and the per-line estimate by the Sales Order Line collection.

Discount: the order-level figure is captured onto the transaction by this collection, order-level discounts again as detail by the Sales Order Header Discount collection, and item-level discounts on each captured line by the Sales Order Line collection.

Payment: the Sales Order Payment collection captures the payment detail, while the Sales Order Unmapped Payment collection acts on the same payment data for the opposite purpose — stopping orders paid by a method that has not been mapped. Keep the two in step: every method the payment collection is set up to capture must also appear on the Unmapped Payment allowlist, and vice versa.

Add/Update Zoho Commerce Sales Order Line TO iPaaS.com: captures each item on the order, with its SKU, item name, quantity, unit and extended pricing, line discount, and line tax.

Add/Update Zoho Commerce Sales Order Billing Address TO iPaaS.com: captures the order's billing address and the billing contact name.

Add/Update Zoho Commerce Sales Order Shipping Address TO iPaaS.com: captures the order's shipping address and contact name, along with the shipping method and delivery detail carried on the order.

Add/Update Zoho Commerce Sales Order Tax TO iPaaS.com: captures the order's tax detail, including the tax authority name, the tax percentage and the summed tax amount. It produces a record only when the order carries at least one tax entry.

Add/Update Zoho Commerce Sales Order Payment TO iPaaS.com: captures the payment recorded against the order, including the payment method, description and amount.

Add/Update Zoho Commerce Sales Order Unmapped Payment TO iPaaS.com: holds the allowlist of payment methods you have mapped and stops any order paid with a method that is not on it, so the order is not captured as a partial record needing manual repair. This collection carries no field mappings; its filter is its entire function.

Add/Update Zoho Commerce Sales Order Header Discount TO iPaaS.com: captures a discount applied to the order as a whole. It produces a record only when the order's discount was applied at the order level rather than to individual items.

Authentication is tied to the United States Zoho accounts domain: the integration signs in through Zoho's US accounts service, and there is no setting that changes which regional service is used. A store whose Zoho organization is hosted on a data center outside the United States cannot currently connect, so no collection in this integration can transfer for that store.

Orders are captured, never written back: this family of collections reads sales orders from Zoho Commerce into iPaaS.com. The integration does not create, update or delete orders, lines, addresses, tax, payments or discounts in Zoho Commerce, and it does not take, authorize, capture or refund money.

Order content varies by order: what an individual order carries differs, so tax entries, discounts, shipping detail, secondary street lines and additional contacts are present on some orders and absent on others. Validate against a representative set of real orders in a staging environment that the values your processes depend on are populated.

Tax is calculated in Zoho Commerce: the captured values are what the store charged at checkout. This integration does not calculate, re-calculate or validate tax. Changing tax rules in Zoho Commerce changes what is captured on orders placed afterwards.

Payment and shipping method names are defined in the store: the captured method names are whatever those methods are called in Zoho Commerce, and they are not always identical to the labels shown in the storefront or in the gateway's own settings. Take the exact values from a real order. Renaming a method changes the value captured on orders placed afterwards, and adding a payment method requires a matching update to the allowlist.

How an order is discounted is decided at checkout: whether a given order carries an order-level or an item-level discount is determined by how the promotion is configured in Zoho Commerce, not by this integration. Storefronts that use both kinds of promotion produce captured orders of both shapes.

Call volume matters on large runs: Zoho does not publish a call quota for the Zoho Commerce store API, and a store may still refuse calls made too quickly. Capturing a large number of orders in a short window concentrates a great deal of traffic on one store. Stagger large catch-up runs rather than sending everything at once, and validate throughput in a staging environment before relying on high-volume automatic capture in production.

The payment-method allowlist must be current before the first transfer: an order paid with a method that has not been added to the allowlist on Add/Update Zoho Commerce Sales Order Unmapped Payment TO iPaaS.com is stopped and raised as an error rather than captured. As delivered, that list holds only a demonstration entry and a literal placeholder entry, so it must be updated before any real order can transfer. Errors appear under Dashboard / Integration Monitoring / Error Logs.

Child detail is refreshed only with the order: lines, addresses, tax, payment and header discount are captured as part of the order's transfer. There is no way to capture or refresh any of them independently; to refresh any of them, re-transfer the order through the parent collection.

A stopped order is not partially captured: when the allowlist guard stops an order, nothing is written for that order, so there is no partial transaction and no line, address, tax, payment or discount detail to clean up. That is the outcome the guard exists to produce.

Automatic capture depends on the inbound subscription: no order transfers automatically until the Zoho Commerce sales order subscription is enabled under Inbound Data Flows.

Values set on the transaction outside this integration: these collections capture a defined set of order fields onto the iPaaS.com transaction and its detail records. Subscribers or their MiSP who populate other transaction or line fields from another source should validate in a staging environment how those values behave when the same order is captured again, before relying on them in production.

Errors show the store's own wording: when Zoho Commerce rejects or fails a request during a transfer, the text shown in the iPaaS.com error log is the response the store returned, carrying Zoho Commerce's own phrasing rather than an iPaaS.com-authored message.

A discount applied to the order as a whole contributes the order's own discount amount.

A discount applied to individual items contributes the combined discount across the order's lines instead.

An order with no discount at either level records an explicit zero rather than an empty value, so every captured order carries a discount figure.

The line carries a discount amount and its quantity is not zero: the line's discount is subtracted from the line sub-total and the result is divided by the quantity, producing the effective, discounted price of a single unit.

The line carries no discount amount, or its quantity is zero: the line's own rate is captured unchanged, with no calculation applied.

The line carries a discount amount: the discount is subtracted from the line sub-total and the discounted total is captured.

The line carries no discount amount: the line sub-total is captured unchanged.

The line carries one or more tax entries: each entry's tax amount is added to a running total and the combined figure is captured. A single line can carry more than one tax entry, for example where separate state and local taxes apply.

The line carries no tax entries: the running total stays at zero and zero is captured, so every captured line holds an explicit tax amount.

Multi-line street addresses are flattened. Zoho Commerce holds the street address as a single value that can contain more than one line, and this mapping replaces each line break with a comma and a space. A billing address entered as two lines is therefore captured as one comma-separated Address1 value, and the original line breaks are not preserved. Downstream processes that parse the street address should account for that separator.

The contact name comes from the order, not the address. Both name fields read the first contact person on the order rather than any name held on the billing address itself.

Billing and shipping addresses are read from different parts of the order. Zoho Commerce keeps the order's billing address and the order's shipping address in two separate parts of the order record, and each address collection reads the part that belongs to it. That asymmetry is by design and both collections capture with the same order transfer; it does not indicate a problem with either one.

Multi-line street addresses are flattened. As on the billing address, each line break in the street value is replaced with a comma and a space, so a two-line street address is captured as one comma-separated Address1 value. Because shipping labels and carrier processes are sensitive to address formatting, confirm in a staging environment that the flattened value is acceptable to your fulfillment process.

The captured contact may not be the recipient. Both name fields read the order's contact detail rather than the shipping address, so gift orders and orders shipped to a third party carry the ordering contact's name on the captured shipping address.

Billing and shipping addresses are read from different parts of the order. The billing collection reads the order's billing address block and this collection reads the order's address detail. The two collections therefore draw on different source detail while capturing with the same order transfer. That asymmetry is by design and does not indicate a problem with either one; a subscriber comparing the two captured addresses should simply not assume they behave identically.

Shipping method names come from the store. The captured text is whatever the method is called in Zoho Commerce. Subscribers whose downstream processes match on specific shipping method names should confirm those names in a staging environment first.

The order's payment method is on the list. The first formula returns false, so this collection takes no action and the order continues through the normal capture process. Its payment detail is captured by the Sales Order Payment collection.

The order's payment method is not on the list. The first formula returns true and the inverted error formula also returns true, so the order is caught here and raised as an error. The order is stopped rather than captured, so no transaction is created for it and there is no partial record — no line, address, tax, payment or discount detail — for anyone to repair by hand. The error appears under Dashboard / Integration Monitoring / Error Logs.

At implementation: replace the delivered entries with every payment method your storefront accepts. Confirm the exact spelling from a real order in Zoho Commerce rather than from the storefront's own settings labels, and make the same change to both the filter and the error filter.

When you add a payment gateway or method in Zoho Commerce: add it to the list before the first order using it is placed. Orders paid with the new method are stopped until it is listed.

When you retire a method: leaving it on the list is harmless for historical orders; removing it means any late-arriving order using it is stopped.

After any change: re-transfer the affected orders through the parent collection using Manual Sync, because correcting the list does not re-capture past orders on its own.

An order paid with a payment method that is not on the allowlist is stopped and raised as an error — the Unmapped Payment collection caught the order because its payment method is absent from the mapped-methods list. Nothing is captured for that order: there is no transaction, and no partial line, address, tax, payment or discount detail. As delivered, the list holds only a demonstration entry and a literal placeholder entry, so every real order produces this error until the list is replaced. Resolution: open Add/Update Zoho Commerce Sales Order Unmapped Payment TO iPaaS.com, add the exact payment method name as Zoho Commerce records it on the order to both the filter and the error filter, then re-transfer the affected orders through Add/Update Zoho Commerce Sales Order TO iPaaS.com using Manual Sync.

A message returned by Zoho Commerce — when the store rejects or fails a request during a transfer, the text shown in the error log is the response Zoho Commerce returned, carrying the store's own wording rather than an iPaaS.com-authored message. Resolution: read the message to identify what the store objected to, correct the order or the connection settings accordingly, and re-run the transfer.

An order that carries no tax, and an order with no order-level discount, simply produce no tax record and no header discount record. Downstream processes should treat a missing detail record as "none charged" rather than as a failure.

An order whose Zoho Commerce status has no pair in the Order Status translation is captured without a status value rather than being rejected. Add the missing pair and re-transfer the order.

The order's payment method must appear on the mapped-methods allowlist. This is the only rule that stops an order. An order failing it is raised as an error and nothing is captured for it.

Tax detail is produced only for an order carrying at least one tax entry. A tax-free order produces no tax record rather than a zero one.

A header discount record is produced only for an order discounted at the order level. An item-level discount, or no discount at all, produces no header discount record.

Every child collection is evaluated only as part of an order's transfer. None can be triggered independently, and none has an ID of its own to enter on Manual Sync.

The captured transaction carries the Zoho Commerce order number, status, customer email address, subtotal, tax, shipping, discount, total and total quantity.

A second transfer of the same order updates the existing transaction; no duplicate transaction is created.

The external-ID record is written against the order after the first successful transfer.

Every line on the order is captured, each with a SKU, and the captured line values reconcile to the order subtotal.

The billing address and the shipping address are both captured, each marked as the transaction's primary address of its kind, with the contact name taken from the order's first contact person.

A taxed order carries a tax record whose combined amount reconciles against the order-level tax total; a tax-free order carries none.

An order-level discount produces a header discount record marked as an order-level discount; an item-level discount does not.

The payment is captured with the method name exactly as Zoho Commerce records it, and that name appears on the allowlist.

No order is stopped for an unmapped payment method once the allowlist has been updated for every method the storefront accepts.

Automatic capture produces the same result as Manual Sync for an equivalent order.

Writing orders to Zoho Commerce: every collection in this family moves data in one direction only, from Zoho Commerce into iPaaS.com. Orders, lines, addresses, tax, payments and discounts are never created or updated in Zoho Commerce by this integration, and no money is taken, authorized, captured or refunded.

Deleting orders: removing an order in Zoho Commerce does not remove the transaction captured from it, and removing a line from an order is not propagated as a deletion. See Deleted Record Support.

Independent triggering of child collections: none of the seven children can be transferred on its own; each is captured as part of the parent order's transfer.

Automatic capture from product and category events: Zoho Commerce product and category events do not trigger inbound capture into iPaaS.com. Products and categories move outbound through their own collections, which are driven separately.

Customer address books and promotion detail: only the addresses recorded on the order itself are captured, not customer address records held in Zoho Commerce; and the captured discount carries its amount and order-level marker but not the promotion or coupon that produced it.

Individual customer records cannot transfer in either direction. Zoho Commerce provides neither API access nor customer webhooks for the customer data held in its Member Portal, so customer records cannot be transferred by this integration in either direction. The customer's email address captured on the order is the identifying detail available, and downstream systems should be built around it rather than around a separately linked customer record.

As delivered, every real order is blocked. The payment-method allowlist ships holding only a demonstration entry and a literal placeholder entry. Until it is replaced with the methods your storefront accepts, every real order is stopped and raised as an error and no orders are captured. This is the single most important configuration step before the first transfer, and orders stopped for this reason transfer successfully when they are retried afterwards.

Automatic inbound capture must be verified as actually running before it is relied on. Enabling the sales order subscription is not by itself confirmation that Zoho Commerce is notifying iPaaS.com, because the subscription is not confirmed to register reliably with the store. Place a real order in the storefront and confirm it arrives in iPaaS.com without a Manual Sync before switching off any manual process that depends on automatic capture, and re-confirm after any change to the subscription. Where automatic capture is not arriving, Manual Sync remains available and captures the same order in full.

A payment method added later stops orders until it is listed. Introducing or renaming a payment method in the storefront without updating the allowlist stops every order paid with it from the moment the method goes live.

Order statuses outside the translation are not captured. An order whose Zoho Commerce status has no pair in the Order Status translation is captured without a status value until a pair is added.

Only the first contact person on an order is read. Orders carrying several contacts contribute only the first one to the captured email address and to the contact names on both captured addresses.

Original street line breaks are not preserved. Because a multi-line street address is captured as one comma-separated value, the original line breaks cannot be recovered downstream.

No per-authority tax breakdown. An order taxed by more than one authority is captured as a single combined amount with the order's tax name and rate, so the individual authorities cannot be separated out of the captured record.

A line with a quantity of zero records its list rate as the unit price. The quantity guard on the UnitPrice calculation means a zero-quantity line falls back to the line rate rather than a calculated per-unit figure. The transfer still completes.

One status for all captured payments. Because the payment status is applied as a fixed value, the captured payment does not reflect the payment's actual state with the payment processor. Subscribers who need a true payment state should remap that field or derive it downstream.

One status for all captured lines, regardless of the order's own status. The order header's status is translated through the Order Status translation and can be captured as either of the delivered values, but every captured line carries the same fixed starting status. A completed order therefore captures lines that all read as pending, and line status does not follow the order forward. Subscribers who need line status to reflect the order should change the fixed value or derive line status downstream from the captured order status.

Captured detail refreshes only with the order. Every captured value reflects the order at the time it was transferred. Changes made in Zoho Commerce afterwards appear in iPaaS.com only when that order is transferred again.

Zoho Commerce Connections and Settings

Zoho Commerce Installation Instructions

Zoho Commerce API Endpoints

Zoho Commerce Error Messages

Zoho Commerce Known Limitations

iPaaS.com to Zoho Commerce Category Mapping Documentation

iPaaS.com to Zoho Commerce Product Mapping Documentation

iPaaS.com to Zoho Commerce Inventory Mapping Documentation