POS and Payments for Retail

Start with the catalog, not the card reader

Most of the pain in retail payments isn't payment pain. It's catalog pain arriving at the counter. A line that won't scan, a size that shows three in stock and none on the shelf, a return nobody can look up. The card part is usually the easy bit.

So when you're comparing a POS for retail, the questions worth asking are about the catalog first. If the catalog is right, the rest tends to follow.

SKUs and variants

Every distinct sellable thing needs its own SKU. Not every product, every variant. A shirt in three colors and five sizes is fifteen SKUs, and if you track it as one, your stock figures are decoration.

This is where retail systems genuinely differ. A good one lets you build a variant matrix once, so colors down and sizes across generates the combinations for you. A weak one makes you create fifteen separate products by hand, and then makes you edit fifteen of them when the price changes.

• Branded goods. Come with a UPC or EAN on the box. Scan it in once and the barcode is the lookup for good.
• Unbranded or handmade goods. Have no barcode, so you assign your own SKU and print your own labels. Worth deciding a naming scheme before you have four hundred items and no pattern.
• Weighed or measured goods. Need a unit of measure the system understands, not a fudge where you ring up four of something to mean four yards.

Scanning at the counter

Retail is the one setting where a scanner beats a touchscreen. A busy shop ringing tagged goods wants a scanner, not a grid of buttons, and the gap widens the more SKUs you carry. Menus of tiles work for a cafe with thirty items and fall apart at three thousand.

One technical point worth knowing. A basic laser scanner reads the standard striped barcodes on packaging. A 2D imager also reads QR codes and, importantly, barcodes off a phone screen, which is what you need if you ever want to scan a digital gift card or a discount code a customer is holding up. The cheaper scanner is fine until the day it isn't.

Label printing. If you sell anything unbranded you'll be printing labels, so check that the system drives a label printer directly rather than exporting a file you have to lay out yourself.

Returns, exchanges and store credit

This is the part restaurants barely deal with and retail lives with daily, and it's worth understanding properly because it sits across inventory, payments and fraud at the same time.

• Return to the original tender. A card purchase should go back to the card it came from. Refunding a card sale to cash, or to a different card, is a well-known fraud route and a good system makes the correct path the default rather than something staff have to remember.
• Receipt lookup. Staff should be able to find the original sale from a receipt, a card, or a phone number, because customers rarely bring the paper. A system that can only refund against a receipt number creates a queue and an argument.
• An exchange is two transactions. A refund and a new sale. That matters because both legs touch stock, and if your system fudges it, your stock figures drift every time someone swaps a size.
• Store credit is a liability. Credit you issue is money you owe, and it sits on your books until it's spent. Track it in the POS rather than on paper slips, and be aware that unclaimed balances are governed by state rules, which is a bookkeeping question worth putting to your accountant.
• Gift receipts. Small feature, disproportionate effect at Christmas. It lets the recipient return without seeing the price and without you having to guess.

Selling online as well as in the shop

Once you sell in both places, the question stops being which checkout and becomes whether they share one catalog. Two systems with two stock figures will disagree, usually on the item someone has just bought twice.

Platforms like Clover and Square both offer a first-party online store that shares the catalog with the counter, which is the point of using theirs rather than bolting on something separate. If you already run a store on another platform, check the integration properly before you commit, because sync that only runs periodically will oversell during a busy weekend.

Online sales cost more to process. An online order is card-not-present, so no chip was read and nobody matched the card to the person. That carries more fraud risk and sits in a more expensive interchange category, which is set by the card networks rather than by your processor. Worth knowing when you price shipping.

The seasonal spike, and the wave after it

Retail volume is lumpy in a way most businesses aren't. A gift shop can do a large share of its year in a handful of weeks, and the system has to hold up exactly when you can't afford to fix it.

1. Add lanes before you need them. A second reader and a tablet cost less than a queue out the door, and setting them up in November is easier than on the day.
2. Give seasonal staff their own logins with limited permissions. You want to know who processed a refund, and you don't want a temp holding the keys to your pricing.
3. Know what happens if the internet drops. Ask which transactions the system will store and forward, and what the limits are. A busy Saturday is the wrong time to find out.
4. Tell your processor before a big jump in volume. A sudden spike can look like risk from the outside and trigger a review or a hold on your deposits. A heads-up usually prevents it, and this is the single most avoidable cash-flow problem in seasonal retail.
5. Plan for January. Every gift season is followed by a return season, and returns hit stock, store credit and your deposits at once. Decide the return window and the policy before you need to apply it under pressure.

More than one location

A second shop changes the requirements more than people expect, and it's worth asking about even if the second one is hypothetical.

• One catalog, separate stock. You want the same products everywhere with a stock figure per location, not two catalogs drifting apart.
• Transfers. Moving stock between shops should be a recorded movement, not a deletion in one place and an addition in the other.
• Reporting per store and combined. You need both, and you need staff to see only their own.
• Accounts and deposits. Whether each location gets its own merchant account or they sit under one affects reporting and reconciliation. Ask how it's structured before you open the second door.

Chargebacks in a shop

Retail sees fewer disputes than card-not-present businesses, and the ones it sees follow a pattern.

• Chip and tap protect you. When a chip card is dipped or tapped and authorized, fraud liability generally sits with the card issuer rather than with you. Key a card in by hand and that protection is gone, so it's worth telling staff plainly rather than leaving it as an option they reach for when a chip is slow.
• The name on the statement. If your business name on a card statement doesn't match the sign over the door, genuine customers report genuine purchases as fraud. Getting that descriptor right removes a steady trickle of disputes for no effort.
• Keep the receipt. For a disputed in-person sale, the signed or authorized receipt with the card details truncated is the evidence. Filed by date is enough. Thrown away at close isn't.

What to bring to a demo

Feature lists all look the same. The way to tell retail systems apart is to make the demo use your actual products rather than the clean sample data it ships with.

1. Bring twenty real SKUs, including your most awkward variant, and build them in front of the salesperson.
2. Scan something from your own shelf, then scan a barcode off a phone screen.
3. Do a return without a receipt, then an exchange for a different size, and watch what happens to the stock count.
4. Issue store credit, then spend half of it.
5. Ask to see the report that tells you what sold last week and what you need to reorder.
6. Ask what happens to all of the above when the internet drops.

Clover and Square for retail

We set businesses up on leading platforms like Clover and Square, tailored to each business, so there's no house answer here.

Square has a retail configuration with barcode-driven stock, purchase orders and vendor records in the product itself, and it syncs with its own online store. Clover covers the everyday retail work and extends through its app market, which is where a lot of the deeper inventory functionality lives. The practical advice is the same either way: identify the one capability your shop genuinely depends on, then confirm it exists on the platform you're considering before you commit, rather than assuming it's in there somewhere.

Which fits also depends on how you buy, not just what you need. That's a separate question from features, and it's covered in the Clover vs Square guide below.