Retail POS guides: choosing a till you will not outgrow
Checkout speed, inventory and omnichannel selling. Nothing on this shelf is published yet.
What this shelf covers
Two different products share one name
A till that is really a payment terminal with a product list behind it rings items, tenders, prints and reports a total. A till that is really an inventory system tracks stock at item and variant level as sales and returns happen, references the original transaction when a refund is issued, and controls discounts, refunds and drawer access by role. Both look identical during the part of a demo everyone gets shown, which is the checkout screen. The way to tell them apart is to ask what the system does between sales: if the honest answer is nothing, it is a register with a subscription, and that is a fair choice for a short catalogue and an expensive one for a long one.
Buy for the catalogue you will have
The number that decides this is not how many products you sell but how many variants you stock — a shirt carried in several sizes and colours is one line on the rail and a whole grid the system has to keep separate. Entry tiers commonly cap products, users or locations, so the tier that fits on signing day is not necessarily the tier that fits a year in, and the price of the one above it is worth knowing before you need it. Price the tier that fits the catalogue, the staff list and the second location you actually expect, and confirm whether the price is held for the term.
One stock pool, or two systems and a sync
If anything on the shelf is also listed online, what matters is whether the store and the website read and write the same stock, or whether a connector copies numbers between two databases on a schedule. The second arrangement survives an ordinary Tuesday and gives way on the day you needed it: an update that lands on a delay holds until both channels sell the same last unit inside the same interval, and then the oversell and the apology are yours. Ask which direction the sync runs, how often, and what a return taken at the counter against an order placed online actually updates.
The extra till, and the day the line goes down
Two things break at peak that never break in a demo. The first is licensing: an extra station in December means knowing what a second register costs under your agreement, because software priced per register and software priced per location move in opposite directions the moment a temporary station appears. The second is the connection. Offline behaviour covers two separate systems — the software that rings the sale and the payments that authorize it — and a vendor can claim it while only one of them keeps working. Where card transactions are queued locally and forwarded once the connection returns, they were approved without the issuer, so one that declines on the way through is the merchant’s loss. That is why the queue carries per-transaction and total limits, and why they are worth setting deliberately against your own average ticket rather than accepting a default.
Choosing a retail POS
How do I tell a real retail POS from a terminal with a product list on it?
Run one test in the demo instead of reading the feature list: sell an item, refund it against the original transaction, then look at the stock count and at who was allowed to authorize that refund. A real retail POS moves stock at item and variant level as it happens and permissions the refund by role. A register with a subscription has nothing to show you once the receipt has printed.
How many items do I need before the inventory side matters?
There is no threshold worth quoting, because variants rather than products are what make a catalogue heavy: a small shop of serialized or multi-variant goods can be harder to keep straight than a large one selling single-variant stock. The practical test is whether somebody in the building currently holds the stock position in a spreadsheet or in their head. That is the work you are buying the system to take over — and an entry tier that caps how many products it will hold is capping exactly that.
Our website already tracks its own inventory. Is that a problem?
Only if the two are stitched together rather than genuinely shared. One pool, decremented in real time by whichever channel sells first, is one system; an hourly or nightly copy between two databases is two, and it shows up as an oversell on your busiest day. Ask the vendor whether inventory is shared natively or synchronized, then test the things that only work when it is shared: click-and-collect, an online order returned at the counter, and a gift card that spends in either channel.
Can I add a till for the holidays without rebuilding the setup?
Usually yes — but what it costs was settled at signing, not in November. Get in writing what a second register adds to your licence, then ask whether the extra checkout has to be a register at all: a handheld or tablet with tap-to-pay lets staff take payment away from the counter, check stock from the floor without leaving a customer, and sell at markets and pop-ups on the same system. Count what you need at peak, not in a quiet week.
What actually keeps working when the internet drops mid-queue?
Less than a demo suggests, and the two halves fail separately. Software holding a local copy of the catalogue can usually still open a sale, ring items and print a receipt; software that keeps everything in the cloud may not open the sale at all. Payments are their own question, and debit is the hard one: verified by PIN and authorized against the account in real time, it generally stops outright. That is why a terminal or router that switches to cellular by itself, within seconds, is the resilience feature worth paying for.
The terminal beside the till already works. Why integrate it?
Because a keyed amount is a total typed twice, and the second copy is the one that disagrees. Integrated payments send the amount from the till to the terminal, and refunds, partial payments and gift-card redemptions come back into the same reporting, so the day’s sales total and the processor’s settlement agree without anyone reconciling them by hand. APPIE and integrated payments also let existing point-of-sale software drive RapidCents terminals, so the processing layer can be evaluated on its own before the catalogue is touched.
