Ecommerce POS System: How to Choose One

Most guides to picking an ecommerce POS system rank vendors by card processing rate, which is the wrong axis. The gap between the cheapest and dearest published in-person rate among the big platforms is roughly two tenths of a percent. On 8,000 dollars a month of card volume that is about sixteen dollars. Sixteen dollars is one refunded order and one apologetic email.

The expensive failure in a two-channel business is always the same one. Someone buys the last unit at the counter. Your website does not find out for forty minutes. In that window a customer online buys the same unit, gets a confirmation email, and then gets a refund and an apology instead of a product. Do that twice a week and the rate difference stops being interesting.

So this walks the decision in the order that actually matters: how each system keeps one stock number honest across two channels, then what it costs, then the fees that never appear in the headline rate, then how to go live without spending a weekend recounting shelves. All prices below were checked against each vendor’s own pricing page on 1 September 2026, and where a vendor does not publish a rate, this says so rather than guessing.

What an ecommerce POS system actually is

An ecommerce POS system is a till application that reads and writes the same product, stock and customer records as your online store, rather than keeping its own separate copy. That is the whole definition, and it is the whole difference between a POS and a card reader with a receipt printer attached.

A plain POS records that a sale happened. An ecommerce POS records that a sale happened and decrements the same inventory row your product page checks before it lets someone add to cart. Everything else the marketing pages talk about, loyalty programmes, staff shifts, gift cards, tap to pay, is available in some form on every platform in this category and is not what separates them.

The one-line rule for choosing: pick the system where your online store and your counter share a single inventory database, not two databases with a connector between them. If you cannot have that, pick the connector with the shortest sync interval and the clearest rules about which side wins a conflict.

The sync problem is the actual decision

One product sold in two places needs exactly one source of truth for its stock level, and every real-world POS problem traces back to a business that has two. The failure is not dramatic. It is a slow accumulation of small lies about what is on the shelf, until nobody trusts the number and staff start walking to the stockroom to check before confirming an online order.

Real-time versus batched, and the size of the oversell window

Real-time sync writes the stock change as part of the sale transaction, so the oversell window is effectively zero. Batched sync runs on a schedule, and the oversell window is exactly the length of that schedule. A connector polling every fifteen minutes gives you a fifteen minute window on every single sale in both directions. A connector polling hourly gives you an hour.

The risk is not evenly spread. It concentrates on your last unit of anything, which is also the item most likely to be a one-off, a sale item or a discontinued line you cannot reorder. Low-stock items are where the window bites, and low-stock items are a large share of a small retailer’s catalogue.

Bidirectional, or just one way with extra steps

Plenty of integrations that call themselves sync only push in one direction. Products and stock flow from the POS to the store, and online orders flow back as sales records but never adjust POS stock, or the reverse. Ask the direct question before you buy: when an online order is placed, does the counter’s available quantity drop without a human touching anything? If the answer involves a nightly export, that is not a two-channel inventory, that is two inventories and a habit.

Variants and bundles, where mapping quietly fails

Variants break sync more often than simple products do, because two systems have to agree on which child SKU is which. If your online store models a shirt as one parent with nine size and colour children, and your POS models it as nine independent products, the connector matches them on a code. Any SKU that is blank, duplicated or edited in one system stops matching, and that variant silently stops syncing while everything around it keeps working.

Bundles and kits are worse. Selling a gift set of three items should decrement three component stock levels. Most POS platforms treat a bundle as its own SKU with its own count, which means a bundle sold at the counter does not reduce the components your website sells individually. If you sell kits, test that specific behaviour before you commit.

Returns, which have to travel back the other way

A return accepted in store against an order placed online has to do three things: refund to the original payment method, put the unit back into sellable stock, and mark the online order as refunded so your accounting and your customer’s account agree. Native systems do all three from one screen. Connector-based setups frequently do the first two and leave the third as a manual edit, which is how you end up with a store that thinks it sold something it later took back.

Multi-location, where a single number stops being enough

Once stock lives in more than one place, a single quantity is no longer a useful fact, and your system needs per-location quantities plus a rule for which locations the website is allowed to sell from. Two shops and a warehouse holding two units each is six units, but if the website is fulfilled only from the warehouse it can promise two, not six. Systems that model locations natively handle this. Systems that sum everything into one number will cheerfully sell you stock that is 200 miles from your packing bench.

How the main options actually handle sync

Two of the five options below share one database between counter and website, and three of them run two databases with something in the middle. That single structural fact predicts most of what you will experience day to day.

System	How sync works	Real-time or batched	Multi-location	What breaks	Best fit
Shopify POS	Same database as the Shopify store. The till is a front end on the same product and inventory records.	Real-time, because there is nothing to sync	Native locations with per-location stock; several multi-location tools sit in the POS Pro tier	Third-party apps that write stock on their own schedule and fight the platform for authority	Anyone already selling on Shopify, or willing to move the storefront there
Square	Square is the master catalogue; Square Online is built on the same item library. External carts connect through apps.	Real-time inside Square; batched to any non-Square storefront	Per-location item stock on the paid tiers	Keeping your storefront elsewhere. You inherit a polling connector and its interval	Market stalls, cafes and small shops happy to run the web store on Square too
Lightspeed Retail	Retail holds inventory and purchase orders; its own ecommerce and third-party carts attach to it	Near real-time to Lightspeed’s own storefront; batched to third-party carts	Strong. Built for several stores, transfers and consolidated purchasing	Matrix and variant mapping to an outside cart, and any product without a clean unique code	Multi-location retail with a deep catalogue and real buying operations
Clover	POS first. Inventory lives in Clover; ecommerce links through App Market apps or third-party middleware	Batched, and the interval depends on which app you install	Varies by plan and by the bank or reseller selling you the account	Sync quality is the app vendor’s problem, not Clover’s, and support bounces between them	Counter-service and hospitality where in-person is the dominant channel
WooCommerce POS plugin	The WooCommerce database is the only database. The POS is a browser till writing to the same products and orders tables	Real-time, because there is no second system	Not native. Needs a separate multi-location inventory plugin	Offline behaviour, receipt and drawer hardware support, and speed on large catalogues	WordPress sellers with one counter, a modest catalogue and reliable internet

What each one costs, verified

Published software pricing ranges from nothing to 289 dollars a month before hardware, and published in-person card rates cluster between 2.4 and 2.6 percent plus a fixed fee of 10 to 15 cents. The figures below come from each vendor’s own pricing page. Two of the five do not publish enough to fill the row, which is itself a finding.

System	Monthly software	In-person card rate	Online card rate	Fixed per-transaction fee	Entry hardware
Shopify POS	Basic 39 USD, Grow 105 USD, Advanced 399 USD. POS Pro adds 89 USD per month per location, billed yearly	2.6% on Basic, 2.5% on Grow, 2.4% on Advanced	2.9% on Basic	10 cents in person, 30 cents online	POS Terminal 349 USD
Square	Free 0 USD, Plus 49 USD, Premium 149 USD per location	2.6% on Free and Plus, 2.4% on Premium	3.3% on Free and Plus, 2.9% on Premium	15 cents in person, 30 cents online, keyed entry 3.5% plus 15 cents	Reader 59 USD, Terminal 299 USD, Stand 149 USD, Handheld 399 USD, Register 899 USD
Lightspeed Retail	Basic 89 USD, Core 149 USD, Plus 289 USD	1.5% card-present published on the pricing page, with a note that rates vary by business and industry	Not published	Not published	Not published on the pricing page; quoted per configuration
Clover	Not retrievable from Clover’s public pricing pages	Not published	Not published	Not published	Not published
WooCommerce plus POS plugin	Core plugin free; Pro sold as a yearly or lifetime licence with the price shown only at checkout	Whatever your gateway charges. Stripe lists 2.7% in person	Stripe lists 2.9% online	5 cents in person, 30 cents online on Stripe standard pricing	Reader bought separately from the gateway

Treat the Lightspeed figure as an opening position rather than a final number, given the page’s own caveat. Treat any Clover quote the same way, because the reseller sets it. If a rate is not on a public page, it is negotiable, and you should get it in writing with the fixed per-transaction fee stated alongside the percentage.

Processing rates: what the headline number hides

Every rate you are quoted sits on top of interchange, which is the floor that nobody prices below. Visa describes interchange as a transfer between the acquiring bank and the card issuer, and says merchants do not pay it directly but instead pay a merchant discount to their own financial institution. Your processor pays interchange, adds card network assessments, adds its own margin, and quotes you the total.

Flat-rate versus interchange-plus

Flat-rate pricing charges one percentage regardless of which card is presented, and interchange-plus passes through the actual interchange for each card and adds a stated markup. Flat rate is simpler and shields you from expensive rewards and commercial cards. Interchange-plus is cheaper once your volume is large enough for the blended saving to outrun the fixed monthly account costs that usually come with it. Stripe, for instance, offers interchange-plus under custom pricing but does not publish the volume threshold that qualifies you.

Worked example: where the crossover sits

This is a worked example with stated assumptions, not measured data. Assume an average card-present ticket of 45 dollars, all domestic consumer cards. Flat rate is 2.6 percent plus 15 cents, which is Square’s published in-person rate on its Free and Plus tiers. Interchange-plus assumes a blended interchange of 1.80 percent plus 10 cents and a negotiated markup of 0.30 percent plus 10 cents, giving 2.10 percent plus 20 cents, with 25 dollars a month in gateway and statement fees and a 99 dollar annual PCI fee, which is 8.25 dollars a month.

Monthly card volume	Transactions at 45 USD	Flat rate, per month	Interchange-plus, per month	Annual difference
8,000 USD	178	234.67 USD	236.81 USD	Flat rate wins by about 26 USD a year
60,000 USD	1,333	1,760.00 USD	1,559.92 USD	Interchange-plus wins by about 2,401 USD a year

The shape to take from that: below roughly ten thousand dollars a month, flat rate is fine and the admin saved is worth more than the difference. Somewhere in the tens of thousands, interchange-plus starts paying for itself, and by fifty or sixty thousand a month it is worth the phone calls. The crossover is driven by the fixed monthly fees, not by the percentages.

Fees that never appear in the headline rate

• Chargeback and dispute fees. Stripe publishes 15 dollars per dispute; Lightspeed publishes a 15 dollar chargeback fee. Square publishes no dispute fee on its pricing page.
• PCI compliance fees. Common on traditional merchant accounts, charged monthly or annually, and sometimes accompanied by a non-compliance fee if you never complete the questionnaire.
• Monthly minimums. A floor on processing fees. Quiet months cost you the difference between what you generated and the minimum.
• Early termination fees. Attached to multi-year merchant agreements, not to the month-to-month platforms. This is the fee that turns a bad choice into an expensive one.
• Keyed entry and card-not-present surcharges. Square charges 3.5 percent plus 15 cents for keyed transactions against 2.6 percent plus 15 cents in person. Phone orders typed into the till are keyed transactions.
• Online versus in-person spread. On Square’s Free and Plus tiers the online rate is 3.3 percent plus 30 cents against 2.6 percent plus 15 cents in person. Your channel mix changes your blended cost more than your vendor choice does.

Hardware: what you need, and what locks you in

A small counter needs a card reader and a device to run the till on, and nothing else. That is a 59 dollar Square reader paired with a phone or tablet you already own, or tap to pay running directly on the phone with no reader at all. Everything past that point is convenience, not capability.

A full till adds a customer-facing terminal, a receipt printer, a cash drawer and a barcode scanner. The scanner is the one that pays for itself fastest in a shop with more than a few hundred SKUs, because scanning is what keeps the stock count honest at speed. Published entry points sit around 299 to 349 dollars for a countertop terminal, with all-in-one registers near 899 dollars.

The lock-in question matters more than the price. Card readers from Shopify, Square, Clover and Lightspeed are tied to that company’s payment processing and do not move to a competitor. Peripherals such as printers, drawers and scanners are usually generic and portable. So a 900 dollar register is a 900 dollar bet on one processor, while a 200 dollar printer is not a bet on anything. Buy the readers late and cheap, buy the peripherals once.

The WooCommerce and WordPress route

A WooCommerce POS plugin gives you one genuine advantage that no native platform can match: there is no second inventory database, so there is no sync to break. The till writes orders and decrements stock in the same tables your product pages read from. For a WordPress seller who has already built the store, that is a real structural benefit, and it is why the plugin route deserves serious consideration rather than a dismissal.

Where it breaks down is everything around the transaction. Offline mode is the big one: a browser till on a shop’s internet connection stops taking payments when the connection drops, where a native platform queues the sale on the device. Hardware support is thinner, because a plugin author is testing against a shortlist of printers and drawers rather than shipping its own. Performance degrades on very large catalogues, since your till is now competing for the same database as your shoppers. And your uptime is your host’s uptime, which is a different risk profile from a platform running the till app locally on the device. Those are the same practical limits WordPress runs into whenever it is asked to be real-time transactional infrastructure.

The honest recommendation: if you have one counter, a catalogue in the low thousands of products, decent connectivity and an existing WooCommerce store, the plugin route is the cheapest correct answer and the sync argument is settled in its favour. If you are opening a second location, trading somewhere with unreliable internet, or running a market stall, take a native platform. If you are still building the store, our guide to building a WordPress ecommerce site covers the setup, and the same product data you organise for the till is what your WooCommerce SEO work depends on later. If the answer turns out to be leaving WordPress entirely, the Shopify alternatives comparison is the next thing to read. TopTut sells none of these systems and takes no position beyond what the numbers support.

Going live without a stock disaster

The order of operations matters because every step after the first one assumes an accurate opening count. Get that wrong and you spend the following month chasing variances that were baked in on day zero.

1. Full physical count first, with the shop shut. Not a sample, not a spot check. Count everything, including the stockroom and anything sitting behind the counter. Freeze sales while you do it.
2. Clean the SKUs before you import. Every sellable item needs one unique code that exists identically in both systems. Blank and duplicated SKUs are the single most common cause of a variant that never syncs.
3. Decide which system owns inventory, and write it down. One system is authoritative. The other reflects it. Tell your staff which is which, because someone will otherwise fix a wrong number in the wrong place.
4. Run parallel briefly, one to two weeks. New system live, old records still being kept, on your quietest trading period rather than your busiest. You are looking for drift, not for problems to appear all at once.
5. Reconcile before you cut over. Recount a sample of fast movers and every item with fewer than three units on hand, and explain every variance before you switch the old system off.
6. Cut over on a Monday morning, never a Friday. You want a full working week and full vendor support hours ahead of you, not a weekend.

Reconciliation is arithmetic, and doing it the same way every time is what makes variances mean something:

expected_on_hand = opening_count
                 - pos_sales     + pos_returns
                 - online_sales  + online_returns
                 + stock_received
                 - writeoffs_and_samples

variance = physical_recount - expected_on_hand

# variance consistently negative on one SKU  -> shrinkage or an unrecorded sale
# variance consistently positive on one SKU  -> a return added twice, or a failed sync
# variance only on variants of one product   -> SKU mapping, not counting

Day one checks: place a test online order and confirm the counter’s quantity drops without anyone touching it, then sell the same item at the till and confirm the website’s quantity drops. Process one refund in each direction. Confirm the payout lands in the right bank account and that receipts print with the correct tax lines.

Day seven checks: recount twenty fast-moving SKUs and every item at or below two units, compare against the formula above, and check that discounts and voids applied at the till appear correctly in the online order records. Reconcile one week of card settlements against one week of recorded sales. If those two numbers agree and your low-stock counts are clean, the system is working.

Mistakes that cost more than any rate difference

Five errors account for most of the pain in two-channel retail, and none of them are about processing rates.

• Choosing on card rate alone. Two tenths of a percent on 8,000 dollars a month is about 192 dollars a year. One oversold item a week, at a 45 dollar ticket with the packing time and the goodwill discount you offer to fix it, costs more than that before you finish the first quarter.
• Running two independent stock systems and reconciling by hand. This works for about six weeks, then a busy period arrives and the manual step gets skipped. Every number afterwards is guesswork.
• Buying processor-locked hardware before testing the sync. A register bought on day one is a sunk cost that will argue against switching later, exactly when you have learned enough to know you should.
• Ignoring offline mode. Ask what happens when the internet drops mid-transaction: does the till queue the sale and take payment, or does it refuse? Then ask what happens to inventory when it reconnects. A browser-based till usually cannot queue anything.
• No plan for staff permissions and refunds. Decide before launch who can issue a refund, who can apply a discount, who can edit a stock level, and whether those actions are logged against a named user. Every unexplained variance you cannot attribute is a permissions decision you did not make.

One more that hides in plain sight: customer records. A buyer who shops both channels should be one person in your system, not two. If your ecommerce CRM and your POS keep separate customer lists, your loyalty numbers and your email segments are both wrong, and neither will look wrong until you try to use them.

The verdict: which ecommerce POS system fits which business

The right answer depends almost entirely on how many places your stock sits in and where your storefront already lives.

Business profile	Pick	Why	What to watch
Pop-up or market stall	Square on the free tier	Zero monthly cost, a 59 dollar reader, offline card taking, and nothing to configure before your first trading day	The 3.3 percent online rate on the free tier if the web store grows into a real channel
Single shop with a small online store	Shopify POS, or a WooCommerce POS plugin if you are already on WooCommerce	One database, no connector, no oversell window. Basic at 39 USD covers a single till	POS Pro at 89 USD per location adds up if you later open a second site
Multi-location retailer	Lightspeed Retail	Per-location stock, transfers and purchase ordering are built in rather than bolted on	Get the online rate and the fixed per-transaction fee in writing, because neither is published
Online-first brand doing occasional events	Your existing platform’s own POS app plus tap to pay on a phone	Keeps one inventory, adds no monthly cost, and needs no hardware at all for a few events a year	Connectivity at venues. Test the offline path before the event, not at it
Hospitality or counter service with a small web shop	Clover, quoted through more than one reseller	The in-person experience is the strongest part of the product and is what most of your volume runs through	Batched ecommerce sync via third-party apps, and multi-year merchant agreements with termination fees

If you want one default: for a single-location retailer selling both online and in person, Shopify POS on Basic is the choice that removes the most risk, because the counter and the store are the same system and the oversell window does not exist. If you are already on WooCommerce and trading from one counter with reliable internet, stay there and add a POS plugin; you already have the single database that everyone else is paying a connector to fake.

The one to avoid is any arrangement where your web store and your till are separate products joined by a nightly export, whatever the card rate is. That configuration will cost you a customer refund at a time, quietly, for as long as you run it.

Frequently asked questions