WooCommerce POS and Payments

WooCommerce is not a till. It has no cash drawer, no barcode workflow, no card reader integration and no offline mode. What it does have is a product catalogue, stock levels, orders and customers — which is exactly what a point of sale needs behind it.

So in-person selling on WooCommerce means one of two architectures, and choosing between them is the whole decision.

Two architectures

WooCommerce as the source of truth. A POS plugin runs in a browser on the till, reads products from WooCommerce, and writes each sale back as a WooCommerce order. One catalogue, one stock figure, one order history.

An external till with a sync connector. A dedicated POS system runs the shop, and a connector pushes products and stock between it and WooCommerce.

The honest heuristic: if most of your revenue is online and the counter is secondary, use a POS plugin. If the shop is the business, use a real till system and treat the website as a second channel.

Stock is where this goes wrong

Overselling is the failure mode that costs you customers, and it comes from having two systems each convinced they own the stock number.

Decide, explicitly, before you buy anything:

• Which system owns stock? There must be exactly one answer.
• How often does the other one learn about a change? Real time, or every fifteen minutes? Fifteen minutes is a lot of Saturday afternoon.
• What happens to a reserved item in an abandoned online cart while someone is buying the last one at the counter?
• How are variations handled? Per-variation stock is where sync connectors most often fall short — product variations.
• What happens to a refund or an exchange processed at the counter?

Then test it deliberately: set an item to a stock level of one, sell it online and in person at the same time, and see what the two systems do.

Choosing a payment gateway for in-person

Card-present payment is a different product from online checkout, even from the same provider. What matters:

• A card reader that works with your POS, with a supported connection — the fiddly part is usually pairing, not payments.
• Card-present rates, which are normally lower than online rates. Confirm you are actually being charged the in-person rate.
• One provider for both channels if possible, so refunds and reconciliation are not split across two dashboards.
• Cash handling, including a float, change and an end-of-day count, if you take cash at all.
• Offline card acceptance, and what the provider's terms say about the risk you carry if a stored transaction is later declined.

For online payment more generally — gateways, tokenised cards, recurring billing — the mechanics are in WooCommerce subscriptions, and the general cost of processing is covered in what a WordPress website costs.

Offline, which is the question people forget

Shop internet fails. Ask the POS vendor precisely what happens when it does:

• Can the till still take a cash sale?
• Can it take a card payment, and if so who carries the risk?
• Are sales queued locally and synced afterwards, or lost?
• Does the product catalogue stay available, or is the till dead?

For a physical shop this is more important than any feature list. A till that stops selling when the router reboots is not a till.

Hardware and the room it sits in

• Barcode scanner. Most act as keyboards and need no integration — but your products need barcodes stored in a field the POS reads.
• Receipt printer, and whether the plugin can drive it or only produce a browser print.
• Cash drawer, usually opened by the receipt printer.
• The device itself. A tablet POS in a browser is entirely dependent on that browser staying awake and logged in.
• The WordPress site's speed, because the till is a logged-in user hitting uncacheable pages. Every sale is an uncached request — the hosting implications are in hosting services for WordPress, and cart and checkout must be excluded from caching as choosing a cache plugin sets out.

Staff access

Till operators should not be administrators. Create a role with exactly the capabilities the POS needs — process a sale, apply a permitted discount, issue a refund up to a limit — and nothing else. The capability model is in WordPress user roles explained, and every till account needs two-factor authentication if it can reach the admin at all.

Reconciliation

At the end of each day someone has to answer: does the money match the orders?

• Orders in WooCommerce, grouped by payment method.
• The gateway's own settlement report.
• The cash counted in the drawer.
• Any refunds or voids.

Make sure in-person orders are tagged distinctly so reporting can separate channels. If everything lands as an ordinary online order, you lose the ability to answer basic questions about which channel is working.

Common mistakes

• Two systems both owning stock, which produces overselling within a week.
• Not testing offline until the day the connection drops.
• Online payment rates on in-person transactions, quietly, for months.
• Administrator accounts on the shop floor.
• In-person orders indistinguishable from online ones in reporting.
• A till on the same slow hosting as a heavily cached brochure site, where nothing about the cache helps the till.

Before opening

Run a full day as a rehearsal: sell a simple product, a variable product and a discounted one; process a refund; take one cash and one card sale; disconnect the internet mid-transaction; then reconcile the totals against the gateway and the drawer. Whatever breaks in that rehearsal is what would otherwise have broken with a queue waiting.