WooCommerce point of sale needs 5 decisions: merchant eligibility, catalogue ownership, stock updates, payment evidence and interruption recovery. Compare a native Woo mobile POS with an integrated external till rather than treating all POS products as interchangeable. The opened native POS supported-country list excludes Zambia, so local availability must not be assumed.
Which WooCommerce POS approach fits the business?
A point-of-sale system records an in-person transaction; an online store records a web transaction. The business question is how these channels share products, stock and order evidence. Start by listing the sales tasks required at the counter: selecting variants, changing quantities, recording payment, issuing a receipt and handling a return. Then compare each proposed route against those tasks using the actual merchant entity.
The native Woo mobile POS documentation sets country, currency, device and software requirements. Its current supported-country list does not include Zambia. That excludes an assumption of native availability for a Zambian store; it does not prove that every WooCommerce-compatible POS is unavailable. Evaluate another product against its own eligibility and operating requirements rather than importing the native product restriction.
An external till integration introduces a different responsibility: deciding which platform owns product data. The WooCommerce Square synchronisation guide illustrates a system-of-record choice between WooCommerce and Square. Use it to understand the question, not as evidence that Square merchant services support Zambia. For any alternative, establish which side staff should edit and what information flows in the other direction.
Separate product synchronisation from inventory synchronisation. Product names, descriptions, images and stock quantities are different data. A synchronised product title does not prove that a counter sale reduced online availability. The Square example documents separate sync settings and selected-product participation. Ask the proposed implementer to demonstrate each required data flow with the exact products and variations the business intends to sell.
Choose stable product identifiers before testing. A similar product name in two systems can conceal different pack sizes or variants. Prepare a fictional catalogue with recognisable references and a deliberately similar pair of items. Sell the intended variant in each channel, then inspect the other side. The purpose is to catch an incorrect mapping before a convincing demonstration of general connectivity is mistaken for catalogue accuracy.
How should stock synchronisation be tested?
Test stock reduction across both channels. Record the starting quantity, make an authorised test sale at the till and observe the resulting online quantity. Repeat in the other direction. Retain the observed time and configuration rather than inventing a real-time promise. The Square guide describes scheduled checks and background processing, which shows why a connection alone is insufficient evidence of instantaneous consistency.
Test competing changes to the same item. A counter sale, an online order and a manual stock correction may occur close together. Ask which event takes precedence and how staff investigate an unexpected balance. This is an acceptance scenario to demonstrate, not a claim that the products automatically resolve every conflict. Where the mechanism remains unclear, keep the item out of the approved configuration until the behaviour is understood.
Treat payment status separately from stock status. A created order may be unpaid, cancelled or awaiting confirmation. Ask which state reserves stock and which state releases it. Compare the till receipt, WooCommerce order and payment evidence for the same fictional purchase. A stock balance that looks correct does not establish that the payment was captured or that a refund has been processed.
Rehearse interruption and resumption. Disconnect the test environment using an authorised method and observe what the selected POS permits. Do not assume offline selling exists, or that an offline sale will synchronise safely later. Record what the cashier sees, whether an order reference exists and how repeated submission is prevented. The operating procedure should reflect demonstrated capability rather than a general promise of continuity.
Include returns and fulfilment in the comparison. A returned product may be saleable, damaged or pending inspection, so refunding does not automatically justify adding it to available stock. The Square documentation describes optional fulfilment-status synchronisation, disabled by default. That is another reason to inspect settings explicitly: a working inventory connection does not establish that every order-status event crosses the integration.
Add a product-change exercise to the stock worksheet. Rename a fictional item in the chosen catalogue owner and observe which fields change in the other channel. Then make a stock correction in the approved location and inspect the result. These tasks distinguish catalogue ownership from quantity handling and reveal whether staff are likely to edit the wrong system. Retain an explanation for any deliberately unsynchronised field. If a product is excluded from sync, make that exclusion visible to the people selling it. Otherwise they may interpret a legitimate configuration boundary as a technical fault, or manually adjust both channels and create a new discrepancy while trying to repair the first one.
A documented software candidate: Oliver POS
Oliver POS’s author-maintained plugin listing provides a WooCommerce-compatible software route to evaluate. It describes WooCommerce as the catalogue owner and uses its REST API for register integration. This is a different proposition from assuming access to native Woo payments or Square merchant services in Zambia.
Its documented installation sequence is to install and activate the plugin, open Oliver POS in WordPress administration and select Connect, then use an authorised Oliver account. The listing describes synchronisation of products, customers, orders and tax settings, followed by opening the web register or pairing a supported mobile app. Keep station credentials private. This is a documented starting route, not a deployment performed here.
For a local evaluation, begin with a fictional variant and the payment-recording method the proposed merchant arrangement actually supports. Check product selection, stock changes, receipt references and returns before considering an integrated terminal. Confirm country, currency, account entitlement and processor approval separately; the software listing does not establish these for a Zambian merchant.
| Route | Documented distinction | Decision before adoption |
|---|---|---|
| Native Woo POS | Country and device prerequisites | Zambia is absent from the cited supported list |
| Square integration | Configurable catalogue owner and sync settings | Verify merchant eligibility separately |
| Oliver POS | WooCommerce catalogue with a connected register | Demonstrate the local workflow and confirm payment arrangements |
Decision worksheet
Original contribution: a two-channel stock reconciliation worksheet. Start with a fictional variant and record the quantity visible at the till and online. Add separate rows for a counter sale, an online order, a cancellation, a manual correction and a return awaiting inspection. For every event, record its source, order reference, expected stock effect, observed effect and unresolved difference. Repeat with a product intentionally excluded from synchronisation. The excluded item is a useful control: it tests whether staff understand the configured scope instead of assuming that every catalogue entry participates automatically.
| Checkpoint | Evidence to retain | Decision or corrective action |
|---|---|---|
| Eligibility | Merchant country, device and product requirements | Reject an unavailable route |
| Catalogue owner | Product reference and edit destination | Avoid uncontrolled editing on both sides |
| Stock flow | Starting balance and observed channel updates | Investigate mapping or processing failures |
| Payment evidence | Till order, web order and transaction reference | Keep unpaid and paid states distinct |
| Recovery | Interrupted sale, retry and return results | Write only the procedure demonstrated |
Before accepting a POS proposal, ask a cashier and a stock owner to explain the worksheet independently. They should agree where a correction belongs and which record supports it. Keep differences visible rather than balancing quantities by unexplained edits. The native documentation contains inconsistent statements about virtual-product support; verify your exact product types in the proposed version instead of relying on the broad feature overview.
See online payments for payment scope and WordPress for the surrounding store. To discuss a POS workflow, get started with a fictional catalogue, channel map and the reconciliation worksheet. Do not send live customer or payment records.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.