Not which platform is better, but where stock actually moves, who gets told, and where your data sits. Compared on each side's documented state machine.
Key takeaways
- In WooCommerce the documentation states that stock is reduced when an order moves to Processing, and also in the On hold status, and is returned to inventory on Failed and Cancelled.
- In Shopify stock does not "go down"; it moves between eight documented states, and an accepted order moves the quantity into the committed state.
- Changes to the committed, reserved, damaged, safety_stock and quality_control states do not trigger webhooks. That is a blind spot you have to design around.
- From WooCommerce 8.2, storing orders in dedicated tables is the default for new installations instead of WordPress post types.
- Neither platform produces an invoice allocation number or an Israeli courier label. Another system supplies that either way.
The choice between WooCommerce and Shopify for an Israeli store comes down to two things: exactly when stock moves in each platform, and where your content and data physically sit at the end of each day. Both platforms sell. They differ on the state machine and on ownership.
What this article decides, and what was already decided elsewhere
The general comparison between the two, on setup, maintenance, fees and extensions, already exists here in full in Shopify versus WooCommerce. This article does not repeat it.
What it does instead: take one order and follow it through both platforms at the level of the documented event. The reason is that most operational pain in an Israeli store comes not from the platform itself but from the seam between it and the warehouse, the bookkeeping and the courier. That seam behaves according to the state machine, not according to the feature list.
Where exactly does stock move in each platform?
| Event | WooCommerce, per the documentation | Shopify, per the documentation |
|---|---|---|
| Order created, not yet paid | Pending payment status. Stock has not been reduced | The quantity moves to the committed state when the order is placed |
| Payment received | Processing status: "Payment has been received (paid), and the stock has been reduced" | The quantity stays committed until fulfilment |
| Payment awaiting manual confirmation | On hold status: "Stock is reduced, but you need to confirm payment" | Not defined as a separate inventory state |
| The order failed | Failed status. If stock was previously reduced, it is returned | Depends on the action the app performs |
| The order was cancelled | Cancelled status. Stock returns if inventory management is enabled | Depends on the action the app performs |
| Goods in transit from a supplier | No dedicated status in the order-status documentation | The incoming state, the only state not physically present at a location |
| Damaged item or item in inspection | No dedicated status in the order-status documentation | The damaged and quality_control states, both shown to merchants as unavailable |
| Safety stock | No dedicated status in the order-status documentation | The safety_stock state |
Shopify's eight states are incoming, on_hand, available, committed, reserved, damaged, safety_stock and quality_control, and per the documentation on_hand is the sum of the states that are physically present at the location.
What happens to an order that was never paid?
This is the row that surprises store owners most, because the two platforms solve it in completely different ways.
WooCommerce has a setting called Hold Stock (minutes), under the products settings. The documentation notes that it applies only to orders in Pending payment status, and not to orders that are On hold. When the limit is reached the pending order is cancelled and the held stock is released back to available inventory. Leave the setting blank and the mechanism is off.
In Shopify the mechanism is not a timed hold but a state. The quantity sits in committed, meaning it is not available to sell yet is still physically in the warehouse and counted in on_hand. The documentation also notes that reserving items on a draft order commits them as soon as they are reserved.
The practical consequence for an Israeli store shipping goods: the count that is "right" depends on which number you are looking at. Anyone comparing available against a warehouse count without accounting for committed will conclude the system is wrong. See controlling inventory sync between a shop and a website.
Who is told about a stock change, and who is not
Shopify's documentation lists the inventory webhook topics that exist: inventory_items/create, inventory_items/update, inventory_items/delete, inventory_levels/connect, inventory_levels/disconnect and inventory_levels/update. On the same page comes the important caveat:
- Changes to the committed, reserved, damaged, safety_stock and quality_control states do not trigger webhooks.
What that means in practice:
- An external system relying on webhooks alone will never learn that an item moved into quality control.
- A system that syncs inventory needs a periodic pull as well as event listening.
- The gap is documented, which makes it designable. The trouble starts when someone assumes webhooks cover everything.
In WooCommerce the equivalent is WordPress hooks plus the REST API. The gap there is different in kind: what fires an event also depends on the plugins installed, so it has to be verified on the specific installation and not just in the core documentation. The platform-by-platform version - Shopify and WooCommerce into Priority, SAP B1 or Hashavshevet - is in connecting an online store to an ERP.
Where the content and the data actually sit
In WooCommerce everything sits in a WordPress installation you host. The documentation describes that orders were historically stored as post types and post meta, and that storing orders in dedicated tables became the default for new installations from version 8.2. Either way it is a database you can back up and query directly.
In Shopify the data sits with Shopify and access is through interfaces. That is not an automatic disadvantage: a documented, stable interface is usually more reliable than direct access to a database somebody has altered. It does mean the answer to "what do we hold if we leave" is completely different between the two, and it is worth answering before launch rather than after.
The commercial side is documented too: Shopify documents objects named Company, CompanyLocation and CompanyContact for business-to-business selling, and price lists through a PriceList object that overrides default prices with either a fixed price or a percentage adjustment. Per the documentation, a catalog can be assigned only to a company location.
What neither platform does in Israel
- Obtaining an invoice allocation number from the Tax Authority. That happens in the invoicing system.
- Producing the uniform-format export for an accountant.
- Producing an Israeli courier label. See Israel Post versus a private courier.
- Reconciling the amount captured against the amount ordered, which is a server-side check regardless.
- Deciding who owns an item's price when it exists in both the ERP and the store.
Cost shape, without numbers
- What scales with transactions. Order volume moves cost on both platforms, through entirely different mechanisms.
- What scales with extensions. In WordPress every plugin is both a maintenance cost and a compatibility surface at every update.
- What scales with checkout customisation. Changes in the payment flow are always the most expensive category of work.
- What scales with infrastructure. WooCommerce requires somebody accountable for hosting, backups and security updates.
- What stays flat. Defining field ownership between the store and the financial system. One-off work that saves years.
Sources
Frequently asked questions
Which platform suits an Israeli store better?
There is no general answer, because both need an additional system for invoicing and shipping. The deciding difference is who maintains the infrastructure: WooCommerce requires someone accountable for hosting and updates, Shopify does not. If nobody in the business will hold that, you already have your answer.
Why does my stock figure differ from the warehouse?
Usually because you are comparing the wrong number. In Shopify a quantity that is ordered but not yet fulfilled sits in committed and is not counted in available, even though it is physically on the shelf. In WooCommerce the reduction already happened at Processing or On hold.
Can a store be moved from one platform to the other?
It can, and the hard part is not products but history: orders, credit notes, and the identifiers other systems have already stored. Plan to keep an external identifier on both sides from day one, and the move becomes a data job rather than a rebuild.
Which matters more, data ownership or interface stability?
It depends who maintains it. Full ownership is worth a lot when someone knows how to maintain it, and very little when nobody does. A documented, stable interface beats direct access to a database nobody documents. Answer this from the people you have, not from the principle.
Keep reading
Related service
Inventory & Purchasing
SKU-level stock, reorder rules and an approval flow that leaves a record.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.