WooCommerce Store Connector

The problem

A WooCommerce storefront and a Zoho back office describe the same business in two incompatible vocabularies. WooCommerce thinks in posts, line items, coupons and gateway payloads. Zoho Books thinks in Contacts, Items, Sales Orders, Invoices and Payments Received, each bound to an Organization with its own tax settings and chart of accounts. Zoho Inventory thinks in Item Groups, composite items, warehouses and stock adjustments. Zoho CRM thinks in Leads, Contacts, Accounts and Deals.

Without a bridge, somebody re-keys the middle. Orders get exported to CSV at the end of the week, imported into Books with the wrong tax treatment, and stock in Zoho Inventory drifts from stock on the storefront until an oversell forces a refund. Refunds and partial refunds usually never make it back at all, so revenue in Books overstates what actually cleared the gateway. Customer records fork: the same buyer exists as three Contacts because the email casing differed.

Zoho Inventory ships sales-channel integrations for several marketplaces, but not for a self-hosted WooCommerce store. That gap is exactly what this connector fills.

What ECOSIRE builds

ECOSIRE builds a two-part system: a WooCommerce-side plugin that emits and receives events over the WooCommerce REST API and webhooks, and a Zoho-side layer made of Deluge custom functions, scheduled functions, workflow rules and a connection registered against the Zoho REST APIs. Where a visual, maintainable branch is more appropriate than code — for example routing an order by shipping country to a different Books Organization — the flow is implemented in Zoho Flow instead of Deluge, so your team can read it later.

Order ingestion

A WooCommerce order.created webhook posts to a secured endpoint. The Deluge handler resolves or creates the buyer as a Zoho CRM Contact and, for B2B stores, an Account, then creates a Books Sales Order with line items mapped to Zoho Items by SKU. Order status transitions (processing, completed, cancelled, refunded) are mapped to the Books document lifecycle you choose during scoping — typically Sales Order on processing, Invoice plus Payment Received on completed, and a Credit Note on refunded. Partial refunds create a partial Credit Note rather than being silently dropped.

Item and stock synchronisation

Items are matched on SKU. Products that exist in WooCommerce but not in Zoho Inventory can be auto-created as Items with their sales and purchase accounts pre-set, or held in an exception queue for review — your choice. Variable products map to Zoho Item Groups with variations as individual Items. Stock is pushed from Zoho Inventory to WooCommerce on a schedule and on every Inventory-side movement, with per-warehouse selection so only the warehouses that fulfil web orders drive the storefront number. Composite (bundled) items publish their computed available quantity.

Payments and reconciliation

Gateway settlement rarely equals order value. Each Payment Received records the gateway reference, and gateway fees post to the expense account you nominate, so the deposit that lands in your bank feed reconciles cleanly instead of leaving an unexplained variance.

Tax

Tax lines from WooCommerce are mapped to Zoho Books Tax and Tax Group records rather than recalculated, so the invoice matches what the customer was actually charged. For Indian Books Organizations the mapping honours place-of-supply and GST treatment; for VAT jurisdictions it maps to the correct VAT rate and reverse-charge flag where relevant.

Failure handling

Every inbound and outbound call is logged to a custom module with the payload, the Zoho record it produced, and the retry state. Failed calls retry with backoff via a scheduled function; anything still failing after the retry window raises an alert to a named owner. You are never in a position where an order quietly vanished.

Who this is for

Merchants running one or more self-hosted WooCommerce stores who already keep their books in Zoho, or who are moving to Zoho and refuse to keep re-keying orders. It suits businesses with real inventory constraints — where an oversell costs money — and B2B sellers who need the storefront order to become a proper Sales Order with credit terms rather than just a cash receipt.

It is a poor fit if you have no Zoho Books or Zoho Inventory subscription, or if your store is purely digital with no stock and fewer than a handful of orders a month, where manual entry is genuinely cheaper.

How delivery works

1. Scoping call. We walk your store and your Zoho org together: how many Books Organizations, which warehouses fulfil web orders, your tax setup, your product structure (simple, variable, bundled), your gateways, and the exact status-to-document mapping you want. We also confirm edition and API access.

2. Fixed quote. You receive a written scope and a fixed price. Nothing is built before you approve it.

3. Build. ECOSIRE develops the WooCommerce plugin and the Deluge/Flow layer against a sandbox store and a test Zoho environment.

4. Install in test, then production. We install into a staging WooCommerce site and a test Books Organization first, run a agreed set of end-to-end cases — new customer order, repeat customer, variable product, partial refund, out-of-stock — and only then cut over production, with the historical-order backfill window you specify.

5. Support. A support window follows go-live, covering defect fixes and configuration adjustments as real order volume exposes edge cases.

Lead time is typically two to four weeks from approved scope, depending on how many stores, Organizations and warehouses are in play.