Choosing a POS setup for a gas station or c-store

Few purchases confuse c-store owners more than "POS." The term gets used for at least three different things — the physical registers, the software running on them, and the back-office layer above them — and vendors have every incentive to blur the lines. Before you sign anything, it helps to understand what each layer does and which questions actually matter for a fuel-and-convenience store.

The registers are not the whole system

In fuel retail, the register layer is specialized: it talks to fuel dispensers, handles payment inside and at the pump, and manages age-restricted sales prompts. Environments built around systems like Gilbarco Passport or Verifone Commander dominate this layer because forecourt integration is genuinely hard and regulated. If you sell fuel, your register choice is often substantially made for you by your fuel brand and your dispensers — and that’s fine. The register’s job is to ring accurately and keep the forecourt running.

The back office is where the money is managed

What the register layer historically hasn’t done well is everything above the transaction: the price book across thousands of SKUs, item-level margins, purchasing, invoice reconciliation, and reporting you’d actually read. That’s the back-office layer, and it’s where an independent store wins or loses money. A store can run excellent registers and still bleed margin because nobody can see item costs — the register only knows what you charge, never what you paid.

Price book sync: the make-or-break integration

The single most important connection between the layers is the price book. When you change a price, that change has to reach every register — reliably, and with a record of who approved it. The failure mode is familiar to anyone who’s run a c-store: the shelf says one price, the register another, and the price book on the office PC says a third. When evaluating any setup, ask: Where does the master price book live? How do changes reach the registers? Is there an approval step, or can anyone fat-finger a price straight to the till? A governed flow — edit, review, approve, push — is the difference between a price book and a rumor.

Lottery and fuel: the c-store specials

Two categories make convenience retail different. Lottery needs its own reconciliation — activations, ticket-level settlement, and a daily count that actually balances. Fuel pricing needs a fast, auditable path from decision to pole sign to dispenser. Generic retail software handles neither; make sure whatever back office you choose treats both as first-class modules, not spreadsheet homework.

The integration questions to ask every vendor

• Does your software work alongside my existing registers, or does it require replacing them?
• Where is the master price book, and how do approved changes reach the registers?
• Can I see live sales and the full transaction journal without standing at the register?
• How do lottery settlement and fuel price changes work, specifically?
• Does the purchasing side connect — do my costs and margins update from what I actually buy?

That last question is the one most vendors can’t answer, because most POS back offices have no connection to ordering at all. It’s the gap we built StoreQueue POS to close: a layer designed to work alongside the register environments c-stores already run — including Gilbarco Passport and Verifone Commander setups — with a governed price push, lottery and fuel modules, and the same price book your ordering and back office run on. Whoever you choose, keep the principle: registers ring sales; the back office runs the store; and the price book had better be one book.