In brief
POS integration is the most oversold feature in loyalty software. You need it when the qualifying event is a unit of spend, because the till is the only thing that knows the amount. A program that counts visits does not need it at all.
The short answer
A loyalty program needs a point-of-sale integration when the thing it counts is money. Points, cashback and spend tiers all need the transaction amount, and the till is the only thing in the building that knows it. A program that counts visits needs someone to confirm a visit happened, and a member of staff can do that without the till knowing the program exists.
POS integration is the most oversold feature in loyalty software, because it is the one that sounds like infrastructure. It gets sold most often to businesses whose qualifying event is “came in and bought something”, which requires no integration to observe.
Start with the qualifying event
Searches for loyalty program integrations and loyalty program pos are one question asked two ways: does this thing talk to my till. The answer is decided by your program design, before any vendor is involved.
The qualifying event is what has to happen for the count to go up. A visit is a person, in the shop, being served, and whoever served them already knows it happened. A unit of spend is different. One point per pound requires the basket total to the penny, and nobody at a counter carries that number in their head. Retyping it into a second device is an integration performed by hand, badly, four hundred times a week.
So the rule is short. If the reward is every tenth coffee, the till has nothing to contribute. If the reward is 500 points for £5 off, the till is the source of the whole program and you need the feed.
The three depths
“Integrates with your POS” is sold as one thing and comes in three.
| Depth | What it buys | What setup costs |
|---|---|---|
| None. Staff validate by hand | A program that runs on any payment setup, including a card reader and a notebook | A poster, an account, and ten minutes showing one person how to stamp |
| One-way. Till to loyalty | Automatic earning. The amount arrives without anyone typing it | Connector or API work, a test till, and someone who understands both systems for a day |
| Two-way. Loyalty back to the till | The reward comes off the bill as a discount, so redemption is one action | The row above, plus discount rules inside the POS and a decision about what happens when the two disagree |
None is not a missing feature. It is a design where the authority is a person rather than a data feed. Staff confirm the visit, the count goes up, and the program holds no opinion about what was in the basket. That is staff validation, and it survives a POS migration because nothing was joined to migrate. NeoLoyal works this way and never asks for till credentials, because it has no use for them.
One-way is the common case and the useful one. Transactions flow from the till into the loyalty tool, which turns them into points or spend tiers. Nothing flows back, so redemption is still a person reading a screen and taking something off the bill by hand.
Two-way is the expensive one, and the one customers actually notice, because the reward and the payment meet in a single transaction. It also means the loyalty tool can now change the price of a sale. That is a different level of trust to grant a supplier, and a different audit trail to keep.
Most vendors saying “POS integration” mean one-way. Ask which.
Real time or batch, and what each breaks
Real time sends the transaction as it completes, so the balance is correct before the customer reaches the door. What it breaks is your counter’s independence: if the loyalty endpoint is slow, the queue is slow, unless the till is built to send and forget.
Batch collects transactions and sends them on a schedule, usually overnight. Nothing at the counter can hang, because nothing at the counter is waiting. What it breaks is anything needing today’s number. A customer who earned their five hundredth point at nine in the morning cannot spend it at six that evening, and the person on the till cannot explain why.
Batch is fine for reporting and useless for redemption. Wherever the customer can see a balance, that balance has to be live, even when the earning behind it is not.
The hard part is identity, not the transaction feed
Every till can tell you what was sold. Almost none of them know who bought it.
There are four ways to attach a person to a transaction, and each fails somewhere different:
- A card token. The payment processor returns a stable hash of the card, and the customer does nothing at all. It fails when they pay with a different card, and it fails completely when they pay cash.
- A phone number typed at the till. Works with any payment method. Costs seconds per transaction, gets mistyped, and slows the queue at the exact moment the queue matters.
- A code the customer shows. A card in the browser, a wallet pass, a printed number. Reliable, and it identifies the person before the payment is taken.
- An email at an online checkout. The only one of the four that costs nothing to collect, and the only one unavailable at a physical counter.
The third option deserves a second read. Once the customer has shown a code and a member of staff has scanned it, you already hold the person and the visit. The transaction feed is now contributing exactly one fact: the amount. If the amount is not what your program counts, you have built the hard half of an integration to import a number nothing reads.
Where it breaks
The till goes offline. Broadband drops, the card machine falls back to its own connection, and the loyalty tool sees nothing for two hours. Decide in advance whether those transactions are replayed or lost, and ask the vendor which their connector does. Replayed means a customer’s balance jumps that evening for no visible reason.
A transaction is refunded. A sale earns 40 points at eleven in the morning and is refunded at three in the afternoon. The points have to come back. If they have already been spent, a balance goes negative and somebody has to decide whether the customer hears about it. Refund handling is the best question to put to a vendor, because it is specific, it is ordinary, and it is the one a demo has nothing prepared for.
Two customers share a phone number. A couple, a family, or a small business where one number is on every account. The ledger merges two people into one, which flatters your frequency numbers and produces one very confused reward. A code per person rather than a number per household fixes it, and that has to be chosen at the start rather than after the merge.
The POS ships an update. Your connector runs on somebody else’s release schedule. That is not a reason to avoid integrating. It is a reason to know who fixes it and how quickly, before it matters on a Saturday.
What a CRM integration is actually for
A POS integration answers “what did they spend”. A CRM integration answers “who are they, and what have we already sent them”. Different problems, usually different products.
The valuable part of a loyalty-to-CRM link is unglamorous: one contact record, one consent state, one suppression list. Without it, a customer can unsubscribe from your marketing and keep receiving loyalty email, which is the same person receiving the message they asked you to stop sending.
The trap is buying a CRM to hold three hundred regulars. At that size the loyalty tool is the CRM. It already records who joined, when they last came in, and what they have claimed. A second system holding the same three facts adds a sync, and a sync is one more thing that can quietly be wrong.
The default answer for a single site
For one shop, one till and a program that counts visits, the correct depth is none. No connector, no API keys, no integration call to schedule, and the program keeps running through a POS upgrade because it was never attached to one. That is where the software page arrives from the other direction, and it is why a visit-based program is the cheapest place to start.
Integrate when one of three things is true: the reward depends on the amount spent, earning has to happen without staff involvement, or you run enough sites that manual validation is no longer something anyone can observe. The first and third are solid reasons. The middle one deserves interrogating, because earning without staff involvement also means earning without anyone noticing that one card is collecting a stamp for everybody in the queue.
Before you take a demo, write down two questions. Which of the three depths is this, and what happens to a stamp when the transaction that earned it is refunded. The first answer tells you what you are buying. The second tells you whether anyone has run it in a shop.