Home How to How to Automate WooCommerce Order Management with Make.com

How to Automate WooCommerce Order Management with Make.com

🛒 WooCommerce × Make.com · Step-by-Step

How to Automate WooCommerce Order Management with Make.com

Every new order, every status change, every low-stock product is an event WooCommerce already knows about — it just doesn’t tell anyone unless you’re staring at the admin dashboard. This guide wires WooCommerce’s own webhook system into Make.com so orders log themselves, customers get updates, and you find out about stock problems before they become missed sales.

Built-in
WooCommerce webhooks need no extra plugin — just settings
~15 min
Setup time for the core order.created webhook
5 events
Order created, updated, deleted + product + customer events
$0
Make.com free tier covers most small-store volumes

WooCommerce already tracks everything that happens in your store — every order, every status change from “pending” to “completed,” every time stock drops. The gap isn’t data; it’s that none of it leaves the WordPress admin unless someone logs in and looks. This guide closes that gap using WooCommerce’s built-in Webhooks feature (Settings → Advanced → Webhooks — no plugin required) connected to Make.com.

This is the natural counterpart to the Paystack → Make.com guide earlier in this series. Paystack tells you when money arrives; WooCommerce tells you everything about the order itself — what was bought, by whom, and what stage it’s at. Most stores benefit from both connected to the same automation system.

order.created
The single highest-value WooCommerce webhook topic for most stores
order.updated
Fires on every status change — processing, completed, cancelled, etc.
5 failures
WooCommerce auto-disables a webhook after 5 consecutive delivery failures
SHA256
Webhook signature algorithm for verifying requests are genuinely from your store

How the Connection Works

WooCommerce → Webhook → Make.com → Anywhere

Order events become triggers for everything else

🛒 WOOCOMMERCE Settings → Advanced → Webhooks order.created order.updated POST MAKE.COM Custom webhook receives order payload → verifies signature → filters by status/topic → routes One scenario, many branches 📊 Google Sheets / Zoho — order log 💬 WhatsApp/Telegram — notify customer or team 📦 Wave/Zoho Books — accounting sync The same scenario can also trigger from Paystack (payment) and feed WhatsApp confirmations from the earlier guides

Webhooks vs REST API — Which to Use

ApproachHow it worksBest forReal-time?
WooCommerce Webhooks (recommended)Built into WooCommerce (Settings → Advanced → Webhooks) — pushes a JSON payload to Make.com the instant an order event firesReacting to events — new orders, status changes, stock updates✅ Yes — instant
WooCommerce REST APIMake.com (or any tool) calls your store’s API using Consumer Key/Secret to fetch or update orders, products, customers on demandLooking up extra order details, updating an order’s status FROM Make.com, scheduled reportsOn-demand — not event-driven by itself
The practical combination: Use Webhooks as the trigger (Make.com hears about the order the moment it happens) and the REST API for anything Make.com needs to write back — for example, updating an order’s status to “completed” once a delivery is confirmed via a logistics aggregator, or adding an internal note to the order. Most automations only need the webhook trigger plus simple field mapping; the REST API becomes relevant once your automation needs to act back on WooCommerce itself.

WooCommerce Order Statuses — What Each One Means for Automation

The order.updated webhook fires on every status change — understanding what each status represents helps you decide which transitions matter for your automations.

Pending Payment
Order placed, payment not yet received/confirmed. Often the initial state for bank transfer or Mobile Money orders awaiting confirmation.
Processing
Payment received, order awaiting fulfilment. A strong trigger point for “order confirmed” notifications and order logging.
Completed
Order fulfilled and delivered. Natural trigger for delivery confirmation messages and review requests.
On Hold
Awaiting action — often manual payment methods pending verification. Useful trigger for an admin alert to follow up.
Cancelled
Order cancelled by admin or customer. Trigger for restoring stock counts and removing from active order tracking.
Refunded
Order refunded fully or partially. Trigger for accounting adjustments and stock restoration where applicable.
For most stores, the two statuses worth building automations around first are Processing (the order is real and paid — log it, confirm it) and Completed (the order is done — close the loop with the customer). The other statuses become useful as your automation matures, particularly Cancelled and Refunded for keeping inventory and books accurate.

Step-by-Step: Connecting WooCommerce to Make.com

1
Step 1 · In Make.com
Create a Scenario with a Custom Webhook Trigger
Same starting point as the Paystack guide: create a new Make.com scenario, add a Custom webhook trigger module, and create a new webhook (name it something like “WooCommerce — Order Events”). Copy the generated URL — you’ll paste it into WooCommerce in the next step.
💡 If you already have a scenario from the Paystack guide, you can either add this as a second trigger in a new scenario, or — for stores wanting one unified order pipeline — some sellers run separate scenarios for “payment events” (Paystack) and “order events” (WooCommerce) that both write to the same Google Sheet, since they represent different sides of the same order.
2
Step 2 · In WooCommerce
Create the Webhook in WooCommerce Settings
In WordPress admin, go to WooCommerce → Settings → Advanced → Webhooks → “Add webhook.” Give it a name (“Make.com — Order Created”), set Status to Active, set Topic to Order created, and paste the Make.com webhook URL into the Delivery URL field. WooCommerce will generate a Secret — copy this, you’ll need it for signature verification.
💡 Repeat this step to create a second webhook with Topic Order updated if you want to react to status changes (Recipe 2 below uses this). Each topic needs its own webhook entry, but they can all point to the same Make.com webhook URL, or to different scenarios if you prefer separation.
3
Step 3 · In Make.com
Capture a Test Payload
Click Run once on your Make.com scenario, then in WooCommerce, either place a real test order (recommended — use a test product at a low price, or WooCommerce’s test payment gateways if enabled) or use the “Delivery Logs” section of the webhook you just created to resend a previous delivery if one exists. Make.com captures the payload structure, making all order fields available for mapping in later steps.
4
Step 4 · Security
Verify the Webhook Signature
WooCommerce signs each webhook request with an X-WC-Webhook-Signature header — a base64-encoded HMAC-SHA256 hash of the request body, generated using the Secret from Step 2. Add a module (Make.com’s built-in crypto functions, or an HTTP/Tools step) that computes this hash from the raw request body and compares it to the header value. If they don’t match, filter out the request.
⚠️ As with the Paystack guide, this matters most for automations with customer-facing or financial consequences. For a first build focused on internal order logging, you can proceed without it and add it once the core automation works — but add it before relying on this for anything that writes back to WooCommerce or messages customers.
5
Step 5 · In Make.com
Filter by Status (for order.updated webhooks)
If using the Order updated topic, the payload includes a status field reflecting the order’s current status after the update. Add a Filter checking this field against the specific status you care about (e.g. status equals completed) so your automation only runs for the transitions that matter, not every minor update.
6
Step 6 · Build & Test
Add Your Action Modules and Test End-to-End
Add the modules for your chosen recipe (below) — Google Sheets, WhatsApp/SMS, Telegram, accounting sync. Map fields from the captured payload (order ID, billing name/email/phone, line items, total, status) into each module. Place a full test order and confirm the entire chain fires correctly before considering it done.

What’s Inside the Order Payload

An order.created or order.updated webhook payload is the same structure as the WooCommerce REST API order object — substantially larger than Paystack’s payload, since it includes full order details:

Example order payload (abbreviated)
{
  "id": 1234,
  "status": "processing",
  "currency": "GHS",
  "total": "250.00",
  "date_created": "2026-06-12T14:32:00",
  "billing": {
    "first_name": "Ama",
    "last_name": "Owusu",
    "email": "ama@example.com",
    "phone": "0241234567"
  },
  "line_items": [
    {
      "name": "Kente Tote Bag",
      "quantity": 2,
      "total": "200.00",
      "product_id": 88
    }
  ]
}

Compared to the Paystack payload from the earlier guide, this gives you the actual order contents (line items, product names, quantities) — useful for order logs that show what was bought, not just the total amount. Note billing.phone is in local format (e.g. starting with 0) — the same reformatting step from the WhatsApp confirmations guide applies if sending WhatsApp messages from this data.


4 Ready-to-Build Automation Recipes

📊
Recipe 1: Log Every New Order with Full Line-Item Detail
Topic: order.created — the foundational recipe

Every new order becomes a row in your order sheet — including what was actually purchased, not just the total. This extends Recipe 1 from the Paystack guide by adding product-level detail that payment payloads don’t include.

Webhook (order.created) → Filter (signature valid) → Google Sheets: Add a Row

Map: id → Order ID, billing.first_name + billing.last_name → Customer, line_items (iterate if multiple) → Product/Qty columns, total → Amount, status → Status, date_created → Date.

Recipe 2: Notify Customer When Order Status Changes to “Completed”
Topic: order.updated, filtered to status = completed

This is the WooCommerce-side equivalent of Template 3 (Delivery Confirmation) from the WhatsApp guide — but triggered by you marking the order Completed in WooCommerce, rather than a separate manual message.

Webhook (order.updated) → Filter (status = completed) → Filter (signature valid) → Reformat billing.phone → WhatsApp/SMS API: send Template 3

When you mark an order as Completed in WooCommerce (after the rider confirms delivery, for example), this fires automatically — closing the loop without a separate manual step in your delivery tracking process.

⚠️
Recipe 3: Alert the Team When an Order Goes “On Hold”
Topic: order.updated, filtered to status = on-hold

Orders sitting On Hold (often awaiting manual payment verification — relevant for bank transfer or Mobile Money payments not routed through an automatic gateway) can be easy to forget. This recipe ensures someone is notified the moment an order needs attention.

Webhook (order.updated) → Filter (status = on-hold) → Filter (signature valid) → Telegram: “Order #{{id}} needs payment verification — GHS {{total}} from {{billing.first_name}}”

Particularly useful if you’re using WooCommerce’s native “Direct bank transfer” or “Cash on delivery” payment methods alongside Paystack/Flutterwave — these often default orders to On Hold pending manual confirmation, and this recipe prevents them from being silently missed.

📒
Recipe 4: Sync Completed Orders to Wave or Zoho Books
Topic: order.updated, filtered to status = completed

Closes the loop from the bookkeeping category of the automation tools guide — every completed order becomes an invoice/sales record automatically, without manual re-entry.

Webhook (order.updated) → Filter (status = completed) → Filter (signature valid) → Wave/Zoho Books: Create Invoice (or Sales Receipt)

Map line items to invoice line items, billing details to the customer record (creating a new customer in Wave/Zoho if one doesn’t exist for that email), and total to the invoice amount. Combined with Recipe 1’s order log, this gives you both an operational view (the sheet) and a financial view (the books) updating from the same trigger.


Which Recipe Should You Build First?

🎯 Get a Build Order Recommendation

One question — a suggested sequence based on your store’s situation

Suggested build order


Troubleshooting Common Issues

IssueLikely CauseFix
Webhook shows “disabled” in WooCommerce5 consecutive delivery failures auto-disable a webhookCheck the webhook’s Delivery Logs (in WooCommerce → Webhooks → click the webhook) for the error response, fix the underlying issue (often the Make.com webhook URL changed or the scenario was off), then re-enable and resend.
order.updated fires for every tiny change, not just statusThis topic fires on any order update, including ones unrelated to status (e.g. admin notes)Always filter on the status field for the specific status you care about — don’t rely on the topic alone to mean “status changed.”
Phone number missing or in wrong formatCustomer didn’t provide a phone number at checkout, or it’s in local formatMake the phone field required in your checkout (via WooCommerce settings or a checkout fields plugin) for stores relying on WhatsApp/SMS automation. Apply the same international-format reformatting from the WhatsApp guide.
Signature verification always failsHashing a re-serialized version of the JSON instead of the raw request bodyAs with Paystack, the HMAC must be computed on the exact raw bytes WooCommerce sent — not a re-parsed/re-stringified version, which can differ in whitespace or key ordering.
Multiple line items not handling correctly in Sheets/Telegram messageline_items is an array — directly referencing it without iterating only grabs the first item or produces an errorUse Make.com’s Iterator module on line_items if you need every product listed, or use an Array Aggregator to combine them into a single text field (e.g. “2x Kente Tote Bag, 1x Shea Butter Set”) for a single-row log entry.

5 Mistakes to Avoid

❌ Using order.created for “order is ready” notifications
An order can be created with status “pending payment” — if your confirmation message fires on creation rather than on payment confirmation, customers may receive “your order is confirmed!” before they’ve actually paid.
→ Fix: For payment-confirmation messaging, trigger from the Paystack webhook (payment succeeded) or from order.updated filtered to status = processing/completed, not order.created alone.
❌ Not testing the Cancelled/Refunded paths
Building automations only for the “happy path” (created → processing → completed) means cancellations and refunds — which affect stock and books just as much — go unhandled, leading to inventory and accounting drift over time.
→ Fix: At minimum, ensure Recipe 1’s order log reflects status changes to Cancelled/Refunded (order.updated catches these too) so your records stay accurate even for orders that don’t complete normally.
❌ Forgetting that webhooks need the site to be reachable
WooCommerce webhook delivery depends on your WordPress site being able to make outbound HTTPS requests — on some restrictive hosting setups or with aggressive security plugins, outbound requests can be blocked, silently preventing webhook delivery.
→ Fix: If webhooks consistently fail to deliver with no clear error in the logs, check with your hosting provider whether outbound HTTPS requests from PHP are permitted, and check security plugin settings for any outbound request restrictions.
❌ Running both Paystack-triggered and WooCommerce-triggered logging without deduplication
If both the Paystack guide’s Recipe 1 and this guide’s Recipe 1 are active and both log to the same sheet, a single order can produce two rows — one from the payment event, one from the order event — leading to double-counted revenue in reports.
→ Fix: Choose one system as the “source of truth” for order logging (WooCommerce’s order.created is usually more complete since it includes line items) and use the other (Paystack) purely for payment-specific actions like WhatsApp confirmations, not duplicate logging — or add a lookup step that checks whether the order reference already exists before adding a new row.
❌ Hardcoding currency symbols or assuming GHS
If your store serves multiple currencies (relevant for the “mixed local + diaspora” audience from the WooCommerce plugins guide), messages and logs that hardcode “GHS” will be wrong for orders placed in other currencies.
→ Fix: Map the payload’s currency field into messages and logs dynamically rather than hardcoding a symbol, even if most of your orders are currently in one currency.

Frequently Asked Questions

Do I need both this AND the Paystack → Make.com automation?

They serve complementary purposes. Paystack’s webhook tells you the moment money arrives — useful for instant payment confirmations regardless of what’s in the order. WooCommerce’s webhook tells you about the order itself — what was bought, current status, customer details — and covers order lifecycle events (cancellations, completions) that have nothing to do with the payment moment. A mature setup often uses Paystack for “payment received, confirm to customer immediately” and WooCommerce for “here’s the full order record” and “order lifecycle status changes.” Smaller stores can start with just one — WooCommerce’s webhooks if you want full order detail and lifecycle tracking, Paystack’s if instant payment confirmation is the priority.

Can Make.com update WooCommerce, not just receive data from it?

Yes — using the WooCommerce REST API (Consumer Key/Secret generated in WooCommerce → Settings → Advanced → REST API), Make.com can create, read, update, and delete orders, products, and customers. A common pattern: a logistics aggregator confirms delivery via its own webhook or API, and Make.com then calls the WooCommerce REST API to update that order’s status to “Completed” — which in turn fires Recipe 2 and Recipe 4 automatically, completing the automation loop in both directions.

What if I’m using Paystack/Flutterwave’s WooCommerce plugin — does that change anything here?

The payment gateway plugins (covered in the WooCommerce plugins guide) handle the payment side and update the WooCommerce order status accordingly (typically to “Processing” once payment is confirmed). That status change is exactly what fires the order.updated webhook this guide uses — so the gateway plugin and this automation work together naturally: the plugin changes the status, WooCommerce’s webhook reports the change, Make.com acts on it.

How many webhooks can I have active at once?

WooCommerce doesn’t impose a meaningful limit on the number of webhooks for typical store sizes — you can have separate webhooks for order.created, order.updated, product.updated (useful for stock-level automations), and more, each potentially pointing to different Make.com scenarios if you prefer to keep automations separated by purpose rather than building one large scenario with many filters and branches. Either approach (one scenario with branches, or multiple focused scenarios) works — choose based on what’s easier for you to maintain and debug.


Your Order Data, Working for You

Recipe 1 (order logging with line-item detail) is the foundation — get that working first, including signature verification once you’re past initial testing. From there, Recipe 2 (completion notifications) and Recipe 4 (accounting sync) both branch off the same order.updated webhook with different status filters, so adding them is incremental once the first one is solid. Recipe 3 (on-hold alerts) is independent and can be added any time it’s useful for your payment mix.

Combined with the Paystack and WhatsApp automations from earlier in this series, this completes the operational core: payment confirmed → order logged → customer notified → status tracked through to completion → books updated — all without manual re-entry at any step.

More at OurInternetBusiness.com

Practical guides on automation, online business systems, and growing income from Ghana and across Africa. Visit OurInternetBusiness.com and bookmark it.