POS integration is the requirement that stops most small loyalty programmes before they start, and it is usually not a requirement at all. It is worth understanding what integration does before letting it decide the timeline.
Does a loyalty programme need to connect to the till?
No. A loyalty programme needs to know which customer visited and, for a points scheme, how much they spent. Both can be captured by a staff member in a few seconds without the till being involved at all.
The distinction that matters is between a stamp card and a points card. A stamp card needs nothing from the POS: the visit is the unit. A points card needs a basket total, which a staff member can type as easily as they read it off the screen in front of them.
What does POS integration add?
One real thing: the basket total arrives automatically, so nobody types it. Everything else usually attributed to integration is either available without it or does not work as well as promised.
| Claimed benefit | Reality |
|---|---|
| Automatic points from the basket | Real, this is the main reason to integrate |
| Fewer staff steps | Partly true; the customer still has to be identified |
| Item-level data | Real, and rarely acted on by an independent business |
| Fewer errors | True for totals, not for identifying the right customer |
| Faster checkout | Usually unchanged; the identification step dominates |
The cost side is consistently understated. An integration ties your loyalty programme to your till contract, breaks when either is updated, and adds weeks or months before a single customer is enrolled, during which the programme produces nothing.
When is integration worth it?
When transaction volume is high enough that typing a total is a real cost, or when item-level rules really drive the business. Both conditions are more common in a chain than in an independent shop.
- High volume with a points scheme, where typing a total hundreds of times a day adds up.
- Category exclusions enforced at the till: a pharmacy excluding prescriptions, a shop capping big-ticket lines.
- Multiple sites needing consistent recording without relying on staff behaviour.
- An existing POS with a documented, maintained loyalty API rather than a promised one.
The last point does most of the work in practice. An integration with a well-documented till is a week of work; an integration with a system whose API exists on a roadmap is an indefinite delay with a plausible explanation attached.
What does running alongside the POS look like?
Staff use the till exactly as they do now, and identify the loyalty customer in a separate step that takes a few seconds. Nothing about the payment flow changes, which is why it can be launched on a Tuesday.
- The order is taken and rung up on the till as normal.
- Staff type the customer's phone number, either into a tablet or the same terminal.
- For a points card, staff enter the total they can already see on the till screen.
- The stamp or points are recorded, and the customer's card updates within seconds.
For a new customer this same step issues the card: the number is typed once, the enrolment link goes out by text, and the customer adds the card to Apple Wallet or Google Wallet whenever it suits them. That is the flow Loonine is built around, and it is the reason the programme does not depend on the till.
What are the risks of not integrating?
Two, both manageable. Totals are typed, so occasional errors happen, and the loyalty record and the till record are not automatically reconciled.
Neither is serious at independent scale. A mistyped total costs a few points on one transaction, and reconciliation matters only if you intend to audit the programme against sales, which almost no small business does, and which a monthly spot check covers adequately if you do.
What should you do if your POS vendor sells loyalty too?
Compare it on enrolment rather than on integration, because integration is the feature it will lead with and enrolment is the one that decides whether the programme works. A till-native programme with a QR-code sign-up will be beaten by a standalone one that enrols by phone number.
The honest advantage of a POS vendor's own loyalty module is that it is already connected and already paid for. The honest disadvantage is that loyalty is rarely the product they care about, and the enrolment flow is usually the part that shows it.
Can you integrate later?
Yes, and that is the right order. Launch alongside the till, learn whether the programme works, and integrate once volume makes the typed total a real cost.
Doing it the other way round is how loyalty programmes die in planning. A business that spends four months on an integration before enrolling anyone has four months of data about its till and none at all about its customers.
What does an integration cost to keep working?
More than it costs to build, and that is the part rarely priced in. An integration is a dependency on two products that both ship updates you do not control, and it breaks quietly, usually by silently stopping rather than by throwing an error someone notices.
The realistic ongoing cost is a check that the two systems still agree, monthly, and somebody to call when they do not. For a business running one site, that attention is usually better spent on the enrolment rate, which has a far larger effect on the outcome than whether a total was typed or imported.
Which tills integrate with loyalty platforms?
The cloud tills with public APIs, Square, Lightspeed, Shopify POS and the larger hospitality systems, integrate readily. Older on-premise systems and the small terminals supplied by a payment processor generally do not, and no amount of asking changes it.
Check one thing before you plan around it: whether the API exposes a webhook or event for a completed sale, not just a way to read reports afterwards. A polling integration that discovers a transaction ten minutes later cannot add a stamp to a card while the customer is still standing there, which is the only moment that matters.
Does a loyalty programme slow down the till?
The identification step costs a few seconds and the integration does not remove it. Whether the basket total arrives automatically or is typed, somebody still has to establish which customer this is, and that is where the time goes.
This is why enrolling and rewarding by phone number holds up well under pressure: the number is the identifier, staff can take it while the card machine is working, and nothing waits on a customer finding an app. An integration optimises the part that was never the bottleneck.