The problem and the model
Why businesses stall on loyalty, what a POS migration actually costs, and the layered model that dissolves the problem.
1. The "don't switch POS" problem
Businesses hesitate to add loyalty because the loyalty conversation keeps turning into a POS conversation. Replacing a point-of-sale system means retraining staff, remapping accounting and inventory, renegotiating payment processing, and losing easy access to years of transaction history — a project measured in months, not days. Loyalty does not justify that, because loyalty does not need to be the system of record for transactions.
Ask a shop owner why they still run a paper punch card in 2026 and you rarely hear "I don't believe in loyalty programs." You hear a version of this: the good loyalty software wants me to be on a different till. That is the real blocker, and it is a reasonable one. A point-of-sale system is not a marketing tool that happens to take payment; it is the operational spine of the business. Ripping it out to bolt on a rewards scheme is like replacing the foundations of a house to hang a picture.
What a POS migration actually costs you
The subscription difference between two POS vendors is the smallest line in the budget. The real costs are structural, and they compound:
| Cost area | What actually happens | Who absorbs it |
|---|---|---|
| Hardware and installation | Terminals, printers, cash drawers, scanners and cabling may not carry over between vendors; some are leased or locked to a processor. | Owner, upfront |
| Staff retraining | Every till workflow changes: refunds, splits, voids, discounts, comps, end-of-day. Error rates rise for weeks. | Staff and customers, daily |
| Operational disruption | The cutover has to happen on a live business. Most owners do it overnight and absorb a bad first week. | Revenue, immediately |
| Historical transaction data | Reports, comparatives and audit trails typically stay in the old system. Year-on-year comparisons break at the seam. | Finance, for years |
| Accounting workflows | Chart-of-accounts mappings, tax codes, tip handling and daily journal exports to your bookkeeping software all need rebuilding. | Bookkeeper / accountant |
| Inventory workflows | SKUs, modifiers, recipes, variants, suppliers, par levels and stock counts must be re-entered or re-mapped, then re-counted. | Operations |
| Payment processing | Many POS vendors bundle or steer processing. Changing POS can change your effective rate, settlement timing and chargeback workflow. | Margin, permanently |
| Reporting | Every custom report, dashboard and KPI definition is rebuilt from scratch in a different reporting model. | Management |
| Multi-location complexity | Multiply every row above by the number of sites, then add the period where sites are on different systems. | Everyone |
| Vendor lock-in | Contracts, hardware leases and processing agreements can carry termination costs or minimum terms. | Legal / finance |
| Integrations | Online ordering, delivery aggregators, scheduling, payroll, accounting and reservation tools each need re-connecting and re-testing. | Whoever set them up |
Every cost above is incurred to fix a problem you did not have. Your POS was, presumably, working. The only thing it did not do was loyalty. A migration is a total-system risk taken to solve a single-feature gap — and single-feature gaps are exactly what a layered architecture is for.
The reframe: loyalty is not the system of record for transactions
Here is the sentence that resolves the whole problem:
A POS is the system of record for transactions. A loyalty platform is the system of record for customers. Those are different jobs, and they do not have to live in the same box.
When a sale happens, your POS must produce an authoritative, auditable record: what was sold, at what price, with what tax, tendered how, against what stock. Regulators, accountants and your own reconciliation depend on that record being singular and correct. Loyalty needs almost none of that. Loyalty needs to know that a known customer bought something, and often only the coarsest facts about it — a visit happened, or an amount was spent, or a category was purchased. It does not need the tax breakdown. It does not need the tender type. It does not need to be the place the money is counted.
Once you separate those roles, "you need a new POS to run loyalty" stops being an architectural truth and becomes what it usually is: a product boundary from a vendor who sells both.
Three layers, not one system
Most confusion in this category comes from collapsing three distinct responsibilities into one word — "loyalty." Pulling them apart makes every subsequent decision easier:
| Layer | Owns | Fails if… | Typical home |
|---|---|---|---|
| POS (transaction layer) | Items, prices, tax, tender, stock, receipts, reconciliation | It is not authoritative or auditable | Your existing point-of-sale system |
| Loyalty layer | Customer records, identifiers, earning and redemption rules, balances, tiers, expiry | It cannot recognise the same person twice | Loyalty software — POS-native, POS-agnostic, or standalone |
| Customer communication layer | The card the customer carries, the balance they see, and the messages they receive | The customer never sees it or forgets it exists | Apple Wallet / Google Wallet, email, SMS, app |
The practical consequence: you can change any one layer without rebuilding the other two. Change your POS and the customer keeps the same wallet card with the same balance. Change your loyalty vendor and the till workflow does not change. Change your communication channel and the earning rules stay intact. That is not a marketing claim — it is simply what layering buys you, and it is why the same pattern shows up in payments, in identity, and in every other domain where one component changes faster than its neighbours.
- A POS migration is a total-system risk; a loyalty gap is a single-feature problem. Do not pay the first price to fix the second.
- The POS is the system of record for transactions. The loyalty layer is the system of record for customers. Different jobs.
- Three separable layers — transaction, loyalty, customer communication — mean any one can change without rebuilding the others.
- "You need a new POS for loyalty" is usually a product boundary, not an architectural constraint.
Evaluating loyalty vendors before deciding how a customer will be identified at your counter. Identification is the hard constraint; everything else is configuration. Teams that skip it end up with a beautiful rewards program nobody can actually earn points in, because the till workflow was never designed.
2. The POS Loyalty Layer Model™
The POS Loyalty Layer Model™ splits a loyalty program into six layers — transaction, customer identity, loyalty logic, wallet, communication and analytics — and shows that only the first is owned by the POS. Everything above it can run on a separate platform, which is why a modern loyalty program does not require a POS change.
1. Transaction Layer — the POS. Records what was sold, for how much, with what tax and tender. Authoritative. Rarely replaceable casually.
2. Customer Identity Layer — the mechanism that links a transaction to a person: a scanned barcode or QR code, a phone-number lookup, a member ID typed at the till, an NFC tap, or an order record from your ecommerce store. This is the layer people forget, and it is the one that determines whether the whole thing works.
3. Loyalty Logic Layer — the rules engine. Earning rates, stamp thresholds, tiers, reward catalogue, expiry, caps, exclusions, fraud limits.
4. Wallet Layer — what the customer carries. An Apple Wallet or Google Wallet pass showing balance, tier and a scannable code — or a plastic card, or an app screen.
5. Communication Layer — how you reach them: wallet lock-screen updates, email, SMS, app push, in-store signage.
6. Analytics Layer — enrolment rate, active members, repeat rate, redemption rate, incremental spend, cohort retention.
The model's usefulness is in what it makes obvious. Layer 1 is genuinely hard to change — it is bolted to your operations. Layers 2 through 6 are software and configuration. A POS-native loyalty product fuses all six into one vendor, which is convenient right up until you change layer 1. A POS-agnostic architecture keeps layer 1 separate from the rest, which costs a little more coordination and buys you the ability to change either side independently.
Figure 1 — The POS Loyalty Layer Model™. The transaction layer stays where it is; the five layers above it are the loyalty program. (Original PushNotice framework diagram.)
How the layers actually connect
The connection between layer 1 and layer 2 is the only genuinely technical decision in the stack, and it has a wide range of valid answers — from "the cashier scans a QR code on the customer's phone" to "the POS fires a webhook on every completed sale." The rest of the stack is configuration.
| Layer | Typical owner | Failure mode | Change frequency |
|---|---|---|---|
| 1 · Transaction | POS vendor | Reconciliation breaks; tax is wrong | Rarely — often years apart |
| 2 · Customer identity | Loyalty platform + your counter workflow | Same person counted twice; staff skip it under pressure | Rarely, once designed |
| 3 · Loyalty logic | Loyalty platform | Rewards too hard to reach, or so easy they cost margin | Quarterly tuning |
| 4 · Wallet | Apple / Google + your pass provider | Card never gets saved; balance looks stale | Design refresh yearly |
| 5 · Communication | Loyalty / marketing platform | Over-messaging; customers delete the pass | Continuously |
| 6 · Analytics | Loyalty platform + your own reporting | You cannot prove the program pays for itself | Monthly review |
A bakery keeps its existing POS untouched (layer 1). Customers save a wallet stamp card carrying a unique QR code (layers 2 and 4). At checkout the cashier scans that code with the same handheld scanner used for products, and the loyalty platform records a visit and updates the stamp count (layers 2 and 3). The updated pass shows "7 of 10 stamps" on the customer's phone, and a message goes out when the tenth stamp lands (layers 4 and 5). Monthly, the owner checks repeat-visit rate among pass holders against non-holders (layer 6). Nothing about the POS changed. This is an illustrative example of the architecture, not a description of a specific customer deployment.
- Six layers: transaction, customer identity, loyalty logic, wallet, communication, analytics.
- Only layer 1 is owned by your POS. Layers 2–6 are the loyalty program.
- The customer identity layer is the one most often skipped and the one most likely to sink a launch.
- POS-native loyalty fuses all six layers into one vendor; POS-agnostic keeps layer 1 separate.
Before you demo a single product, sketch your own version of this model on one page: name the POS in layer 1, write exactly how a customer is identified in layer 2, and write your reward rule in layer 3. Vendors then have to fit your architecture instead of you fitting theirs.
Definitions and architecture
A clean definition, the end-to-end flow of a POS-agnostic program, every integration method compared, and exactly what data has to move between systems.
3. What is a POS loyalty program?
A POS loyalty program is a customer rewards program connected to a point-of-sale system, so that purchases made at checkout can identify a customer and automatically earn or redeem rewards. The connection can be as simple as scanning a customer's barcode at the till or as deep as a real-time API integration — and it does not require the loyalty program to be built by the POS vendor.
POS loyalty program
A loyalty program in which the point-of-sale transaction is the trigger for earning and redeeming rewards. The POS supplies the fact that a purchase happened; the loyalty system supplies the customer record, the rules and the balance. The two are connected either by a person (a cashier scanning a code) or by software (an API, webhook, middleware or scheduled import).
How it works
Every POS loyalty program, from the simplest to the most sophisticated, performs the same five steps in the same order:
- Enrolment. A customer joins and is issued an identifier — a card number, a QR code, a phone number, a member ID.
- Identification. At the counter, that identifier is presented and captured, linking this specific transaction to that specific customer.
- Attribution. The purchase — or just the fact of a visit — is attributed to the customer's record.
- Calculation. The loyalty rules run: add points, add a stamp, advance a tier, unlock a reward, apply expiry.
- Reflection. The new balance is shown back to the customer, ideally somewhere they will actually see it.
Notice what is not in that list: nothing requires the loyalty rules to run inside the POS. Steps 3, 4 and 5 can happen anywhere. Step 2 is the only one that has to happen at the counter, and it can be done by a barcode scanner, a phone number typed into a lookup box, an NFC tap, or a member ID keyed into a note field.
A coffee shop runs a "buy 9, get the 10th free" stamp card. The customer opens their wallet pass and shows a QR code; the barista scans it with the existing scanner; the loyalty platform adds a stamp; the pass on the customer's phone updates to show 8 of 9 and a notification appears when the free drink unlocks. The POS rings up the coffee exactly as it did before — the loyalty step sits beside the sale, not inside it. (Illustrative example.)
What "connected to the POS" really means
This phrase is used loosely by vendors, and the difference between its meanings is the difference between a weekend setup and a six-month integration project. There are three honest readings:
| What the vendor means | In practice | Coupling |
|---|---|---|
| "Works at your point of sale" | A cashier scans the customer's code at checkout. No software connection to the POS at all. | Loose — works with any POS |
| "Integrates with your POS" | Software reads transactions from the POS (via API, webhook, middleware or export) and awards rewards automatically. | Medium — depends on that POS's API |
| "Built into your POS" | The POS vendor's own loyalty feature, configured in the POS dashboard and shown on the POS screen. | Tight — ends when the POS ends |
All three are legitimate. The first is dramatically underrated: it requires no integration, works identically across every POS on the market, keeps working when you change POS, and is how a great many small-business loyalty programs actually run. Its cost is a manual step at the counter. That is a real cost — but it is smaller than a POS migration, and far smaller than an integration project that a POS vendor has to approve.
- A POS loyalty program uses the checkout as the trigger for earning and redeeming.
- Five universal steps: enrol, identify, attribute, calculate, reflect.
- Only identification has to happen at the counter. Everything else can live elsewhere.
- "POS loyalty" spans three very different coupling levels — ask which one a vendor means.
Assuming "integrates with my POS" means points appear on the receipt. Often it means a nightly file import. Ask for the latency in minutes, and ask what the cashier sees on screen.
4. How POS-agnostic loyalty works
POS-agnostic loyalty keeps the customer record, the rules and the balance in a platform that sits outside the POS. The POS only has to contribute one thing: the signal that a known customer made a purchase. That signal can arrive through a scan at the counter, a webhook, an API call, middleware, or a scheduled file import — and the customer's card lives in Apple Wallet or Google Wallet, independent of both.
The canonical flow is a straight line with one loop back to the customer:
Figure 2 — The POS-agnostic loyalty flow. The POS contributes the purchase; identification links it to a person; the engine calculates; the wallet displays; the notification drives the return visit. (Original PushNotice diagram.)
The seven implementation methods, compared honestly
"Integration" is not one thing. These are the seven real options, from no integration at all to a fully native build. Most businesses over-estimate how far right on this table they need to be.
| Method | How it works | Latency | Effort | Works with any POS? | Best for |
|---|---|---|---|---|---|
| Counter scan (no integration) | Staff scan the customer's wallet barcode into a loyalty app or web scanner alongside the sale | Instant | Hours | Yes | Single sites, cafés, salons, any business without an API |
| CSV / manual import | Export customers or transactions from the POS periodically and import into loyalty | Hours–days | Low | Yes | Backfilling an existing customer list at launch |
| Scheduled import (batch sync) | An automated job pulls yesterday's transactions on a schedule | Nightly | Medium | If the POS exposes exports or an API | Spend-based points where same-second accuracy is not required |
| Webhook | The POS pushes an event to your loyalty platform when a sale completes | Seconds | Medium | Only POS platforms that publish webhooks | Automatic earning without polling |
| API (real-time, pull) | Loyalty queries the POS API for orders/customers, or writes back to it | Seconds | Medium–high | Only POS platforms with an accessible API | Two-way sync, redemption at checkout |
| Middleware / iPaaS | A connector service translates between POS and loyalty when neither speaks the other's format | Seconds–minutes | Medium | Where a connector exists for both | Stacks with several systems to join up |
| POS-native integration | The loyalty tool is a certified app inside the POS's marketplace, with UI on the till | Instant | High (partner approval) | No — that POS only | Large chains standardised on one POS |
Real-time vs batch: what actually changes
The instinct is to demand real-time. It is worth being precise about what real-time buys you, because the honest answer for most businesses is "less than you think."
| Dimension | Real-time (API / webhook / scan) | Batch (scheduled or manual import) |
|---|---|---|
| Customer sees new balance | Before they leave the counter | Next day |
| Redeem a reward same visit | Yes | No — reward lands after the visit |
| "Congratulations" moment | In store, in front of staff | Later, by notification |
| Fraud exposure | Lower — balance is authoritative live | Higher — a window exists between sale and update |
| Build and maintenance cost | Higher; needs error handling and retries | Lower; a failed job can simply re-run |
| Failure behaviour | A dropped event silently loses a customer's points | A missed batch is re-runnable and self-healing |
| Suits | Points-per-dollar, tiered programs, checkout redemption | Stamp cards, visit counts, tier reviews, win-back campaigns |
Counter scanning is real-time without being an integration. The barcode is scanned at the moment of sale, so the customer sees the balance immediately — but no software ever touched the POS. For a large share of independent businesses this is the correct architecture, and it is frequently skipped because it does not sound sophisticated.
- POS-agnostic loyalty needs one signal from the POS: a known customer bought something.
- Seven integration methods exist; several of them need nothing from the POS at all.
- Real-time matters most for checkout redemption and points-per-dollar; batch is fine for stamps and visits.
- Batch failures are re-runnable; real-time failures silently lose points. Ask about retries.
Start at the loosest coupling that meets your reward mechanic, and tighten only when a measured problem justifies it. It is far easier to add an integration to a working program than to rescue a program that never launched because the integration was not ready.
5. Connecting loyalty to your existing POS
At most, a loyalty program needs a customer identifier, a transaction identifier, an amount or item category, a timestamp and a location. Most programs need far less than that — a stamp card needs only "customer X visited." Collect the minimum that your reward rule actually requires, because every extra field is a privacy obligation, an integration dependency and a thing that can break.
The data that can move between systems
| Field | What it enables | Required? | Example |
|---|---|---|---|
| Customer ID | Everything. Without it there is no program. | Always | PN-8842K encoded in the wallet barcode |
| Transaction ID | Idempotency — stops one sale awarding points twice | If automated | ord_00931 from the POS |
| Purchase amount | Spend-based earning; average-ticket analysis | Only for spend-based rules | £18.40 |
| Purchase date / time | Visit frequency, recency, expiry, daypart offers | Nearly always | 2026-08-14T08:12Z |
| Location / store | Multi-site attribution and site-level reporting | If multi-location | Store 03 — Northgate |
| Product category | Category-specific rewards and merchandising insight | Rarely | Hot drinks |
| Line items / SKUs | Product-specific rewards; basket analysis | Rarely — high privacy cost | 2× flat white |
| Reward balance | What the customer sees; redemption eligibility | Always (held in loyalty) | 7 of 10 stamps |
| Membership tier | Tier benefits and targeting | If you run tiers | Gold |
| Visit frequency | Segmentation, lapse detection, win-back triggers | Derived, not imported | 4 visits / 30 days |
| Consent & contact preferences | Lawful, wanted communication | Always | Wallet updates: yes · Email: no |
Collect only what your reward rule needs to function. This is not merely good manners: under the UK and EU GDPR, personal data must be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed" (Article 5(1)(c), the data-minimisation principle). A stamp card that only needs "customer X visited on date Y" should not be ingesting itemised baskets. Less data also means fewer integration dependencies, a smaller breach surface, and a simpler answer when a customer asks what you hold on them.
What your POS needs to support
Depending on how tightly you want to couple, here is the honest requirement list. Read down until you hit the row you can satisfy — that is your integration ceiling.
| If you want… | Your POS must… | If it can't… |
|---|---|---|
| Counter scanning | Nothing at all. You need a scanner or a phone camera and a staff member. | Not applicable — this always works |
| Customer list import | Export customers to CSV | Collect enrolments directly instead of importing |
| Automatic earning | Expose completed orders via API or webhook, with a customer reference attached | Fall back to counter scanning or scheduled import |
| Redemption at checkout | Support a discount, comp or negative line item that staff can apply | Redeem by handing over the item and marking it in loyalty |
| Customer attached to sale | Have a customer field on the ticket that staff actually fill in | Use the loyalty scan as the identity source instead |
| Points shown on the receipt | Allow custom receipt fields or a native loyalty module | Show the balance on the wallet pass — usually better anyway |
| NFC tap identification | Have a certified reader and POS software supporting the wallet NFC protocols | Use a barcode — supported by every wallet and every scanner |
POS API openness is inverted from what most buyers assume. Square publishes a Loyalty API with webhooks and a free developer account, but its own documentation states that applications using OAuth require LOYALTY_READ or LOYALTY_WRITE permission, that the seller must have an active Square Loyalty subscription, and that the loyalty program itself is created in the Square Dashboard rather than via the API. Toast documents a Loyalty API but gates partner access behind an application, approval from compliance, privacy, security and legal, a signed partner agreement, and a certification review before credentials are issued. Lightspeed's Restaurant O-Series Loyalty and Payments API documentation states that customers or their developers "will need to contact your Account Manager to be given API access." Clover's published API reference and webhook event list contain no loyalty or rewards resource at all. Verify each vendor's current terms directly — these are the states of their public documentation at the date checked.
Questions to ask your POS vendor
Send this list to your POS provider before you buy any loyalty product. The answers determine which row of Table 6 is available to you.
- Do you publish a public API, and can a merchant use it without becoming an approved partner?
- Do you publish webhooks for completed orders? Which event names?
- Can a third-party loyalty tool read customer records, or only orders?
- Is there a customer field on the ticket, and can staff attach a customer mid-transaction?
- Can I export my full customer list, and does that export include loyalty balances?
- Can I export historical transactions, and in what format and time range?
- Does your own loyalty feature cost extra, and how is it metered — per location, per member, or per loyalty event?
- If I cancel your loyalty feature, what happens to accrued customer balances?
- Can staff apply an arbitrary discount or comp line at checkout without a manager override?
- Do your terminals support wallet NFC reading, and are they certified for it?
- Is there an app marketplace, what is the review process, and what revenue share applies?
- What is your data retention and deletion policy if I leave?
- Customer ID, timestamp and consent are near-universal; everything else depends on your reward rule.
- Data minimisation is both a legal principle (GDPR Art. 5(1)(c)) and an engineering one — less data, fewer failure points.
- Counter scanning has zero POS requirements, which is why it works everywhere.
- API access varies enormously by vendor and is often partner-gated. Confirm before you design around it.
Designing a spend-based points program and only then discovering your POS will not expose transaction amounts to third parties. Confirm field availability before you choose the mechanic — or pick a mechanic (stamps, visits) that does not need the field.
6. POS-native vs POS-integrated vs POS-agnostic vs standalone
POS-native loyalty is built by your POS vendor and ends when that POS ends. POS-integrated loyalty is third-party software wired into one specific POS. POS-agnostic loyalty runs independently and connects loosely to whatever POS you have. Standalone loyalty ignores the POS entirely. Native is the smoothest to operate and the most expensive to leave; agnostic is slightly more work to run and dramatically cheaper to change.
These four are frequently conflated, including by vendors. The distinction that matters is not how the software is sold — it is where your customer records live and what happens to them when you change POS.
| Dimension | POS-native | POS-integrated | POS-agnostic | Standalone |
|---|---|---|---|---|
| Who builds it | Your POS vendor | A third party, certified for that POS | A third party, POS-independent | A third party, no POS awareness |
| Setup effort | ✓ Lowest — a toggle | ⚠ Integration project | ✓ Low — hours to days | ✓ Lowest |
| Flexibility of rules | ⚠ Whatever the POS supports | ✓ Vendor's full engine | ✓ Vendor's full engine | ✓ Full |
| POS dependency | ✕ Total | ✕ High | ✓ Low | ✓ None |
| Migration risk if POS changes | ✕ Program ends | ✕ Integration must be rebuilt | ✓ Reconnect only | ✓ None |
| Multi-location, same POS | ✓ Usually good | ✓ Good | ✓ Good | ⚠ Manual |
| Multi-location, mixed POS | ✕ Impossible | ✕ Impossible | ✓ Its core strength | ✓ Works |
| Customer identity ownership | ✕ Lives in the POS | ⚠ Split across both | ✓ Yours, in the loyalty layer | ✓ Yours |
| Apple / Google Wallet support | ⚠ Varies by vendor | ⚠ Varies | ✓ Common — often the point | ✓ Common |
| Automatic earning | ✓ Native, instant | ✓ Via integration | ⚠ Scan, webhook or batch | ✕ Manual |
| Reporting joined to sales | ✓ Same system | ✓ Usually | ⚠ Two reports to reconcile | ✕ Separate |
| Switching cost (leaving loyalty) | ✕ High — tied to POS contract | ⚠ Medium | ✓ Low | ✓ Low |
| Customisation | ⚠ Limited to POS features | ✓ High | ✓ High | ✓ High |
| Future portability | ✕ Poor | ⚠ Moderate | ✓ Strong | ✓ Strong |
POS-native loyalty is genuinely tied to its POS, and vendors say so. Square's developer documentation states that "Square sellers who use Square Point of Sale (POS) or Square Online can subscribe to Square Loyalty," and its Loyalty API requires an active Square Loyalty subscription. Toast's own support article on exporting loyalty data notes that "you must enable Toast Loyalty to access and export the necessary data reports." No POS vendor we reviewed publishes a claim that its native loyalty runs on a competitor's POS — that is the definition of native, not a criticism. Shopify POS has no native loyalty feature in its published feature list; loyalty on Shopify is delivered by third-party apps. Verify current details with each vendor.
When POS-native is genuinely the right answer
An honest guide has to say this: if you run one location on one POS, that POS's loyalty feature is already bundled in a plan you pay for, and you have no intention of changing POS, then use it. The staff workflow is native, the reporting is joined to sales, and there is no integration to maintain. The argument in this article is not that native loyalty is bad — it is that native loyalty carries a hidden, deferred cost that only appears on the day you change POS, and that cost should be priced into the decision on day one rather than discovered on day nine hundred.
"If I changed POS next year, what would happen to my customers' balances and their saved card?" If the answer is "they'd be gone" or "I'd have to ask the vendor," you are in a native architecture and should either accept that trade knowingly or move the customer layer out.
- The four models differ mainly in where customer identity lives and what a POS change costs.
- Native is smoothest to run and most expensive to leave; agnostic reverses both.
- Mixed-POS estates rule out native and integrated entirely.
- Native is the right answer for a settled single-site business — just price in the exit.
The customer-facing layer
How Apple Wallet and Google Wallet actually work as the loyalty card, what they can and cannot do with a POS, and why wallet loyalty removes the app-install problem without removing the identification problem.
7. Adding Apple Wallet and Google Wallet to POS loyalty
Apple Wallet and Google Wallet can hold a digital loyalty card that displays a member identifier, a scannable barcode, a points or stamp balance, a tier and a reward status — and both can be updated remotely so the customer's balance changes without them doing anything. Neither wallet connects to a POS by itself: something has to scan or read the card at checkout, and something has to push the updated balance back.
Apple Wallet and Google Wallet are containers, not integrations. They do not know your point-of-sale system exists and they will not communicate with it automatically. Every working wallet loyalty program has two connections that someone must provide: (a) an identification step at the counter — a barcode scan, an NFC read on a certified terminal, or a manual lookup — and (b) a synchronisation step, where your loyalty platform updates the pass after the balance changes. Where a POS and a loyalty platform do not already talk to each other, an integration or synchronisation layer is required. Any claim that "Apple Wallet integrates with your POS" is either shorthand for this architecture or wrong.
What a wallet loyalty card can carry
| Capability | Apple Wallet | Google Wallet |
|---|---|---|
| Loyalty card type | The storeCard pass style, described by Apple as appropriate for "store loyalty cards, discount cards, points cards, and gift cards" | The Loyalty API's loyaltyClass (shared template) and loyaltyObject (one per customer) |
| Member identifier | Fields on the pass plus the barcode's encoded message | accountId, accountName and the barcode value |
| Barcode / QR | QR, PDF417, Aztec and Code 128 are supported formats | Barcode on the object; also readable by NFC via Smart Tap where certified |
| Points balance | Custom fields on the pass | Native loyaltyPoints, plus secondaryLoyaltyPoints shown in addition to the primary balance |
| Stamps | Rendered as fields or artwork on the pass | Rendered as points or as pass imagery |
| Tier / status | Custom fields | rewardsTier and secondaryRewardsTier on the class |
| Remote updates | Yes — via a pass web service plus a push to registered devices | Yes — the object is updated server-side via the REST API |
| Lock-screen change alert | Only for fields that carry a changeMessage; Apple states you must provide a value for the system to show a change notification | Via addmessage with TEXT_AND_NOTIFY, or an update with notifyPreference set to notify on allow-listed fields |
| Notification limits | Not a published numeric cap; alerts only fire on changed fields with a change message | Documented cap: a maximum of 3 messages that trigger a push notification in a 24-hour period |
| Location relevance | Up to 10 locations and up to 10 beacon UUIDs per pass; Apple notes relevance is passive — it surfaces the pass, it does not post notifications | The locations field exists but Google's reference marks it as not currently supported for triggering geo notifications |
| NFC identification | Value-Added Services (VAS): requires an NFC certificate from Apple, a VAS-certified reader, and POS software supporting VAS modes | Smart Tap: requires certification, an 8-digit collector ID, a public-key exchange, enableSmartTap on the class and a redemption value on the object |
| Expiry | Pass-level expiry and relevance settings | Object state plus validity settings on the class |
| App required? | No — Wallet is pre-installed on iPhone | No — Google Wallet is available on most Android phones |
How the two wallets update differently — and why it matters operationally
The mechanics diverge, and the difference shows up in how you should design notifications.
Apple uses a hosted pass web service. When your loyalty platform changes a balance, it sends a push to every device registered for that pass; Apple's documentation specifies "an empty JSON dictionary for the payload." The push carries no content — it is purely a signal telling the device to come and fetch the updated pass, which it then does over your web service. That has a useful consequence: the notification the customer sees is generated from the pass itself, from a field that carries a change message. It also has a documented gotcha worth knowing before you go live — Apple states that a push notification for a pass update works only in the production environment.
Google keeps the object on its own servers. Your platform issues an update or patch against the loyaltyObject, and the change is live for that holder without a per-device handshake. Class-level changes, Google notes, "propagate immediately across all Passes Object instances that reference it" — so a single edit to the class touches every card issued from it. Notifications are more explicitly rationed: pushes fire either from an added message marked TEXT_AND_NOTIFY or from an update where notifyPreference is set and the changed field is on Google's allow-list, which for loyalty includes the points balance and the rewards tier. Google publishes a hard limit of three push-triggering messages per 24 hours.
Because both platforms tie notifications to meaningful field changes, the balance update is the message. You do not need to write a separate marketing campaign to tell someone they earned a stamp — the pass updating is the notification. Reserve your scarce broadcast sends for things the balance cannot say: a reward expiring, a new offer, a store opening.
The customer journey, end to end
Figure 3 — The wallet loyalty customer journey. Eight steps, with the two points where an integration or synchronisation layer is genuinely required marked explicitly. (Original PushNotice diagram.)
- Both wallets can carry a member ID, a barcode, a balance, a tier and remote updates — with no app install.
- Neither wallet talks to a POS on its own. Identification and synchronisation must be provided.
- Apple pushes an empty payload and the device fetches the pass; Google updates the object server-side.
- Notifications are rationed by design — Google caps push-triggering messages at 3 per 24 hours.
- NFC identification is possible on both but requires certification and compatible terminals. Barcodes work everywhere.
Planning an NFC tap-to-earn experience without checking terminal certification. Both Apple's VAS and Google's Smart Tap require certified hardware, an approval process and key exchange. A barcode requires a scanner you almost certainly already own.
8. Loyalty without a mobile app
You do not need a mobile app to run a loyalty program. There are three delivery routes — a native app, a web-based card, and a wallet pass — and the wallet route removes the install barrier while keeping a notification channel and an always-available card. It is not universally better: an app can do things a pass cannot, including rich browsing, ordering and in-app payment.
| Dimension | Native mobile app | Web-based card | Wallet pass |
|---|---|---|---|
| Installation | App Store / Play Store download and account creation | None — a URL | One tap to add; wallet is pre-installed |
| Customer friction to join | Highest | Low | Low |
| Friction to use at the counter | Unlock, find app, open, log in | Unlock, find browser, find bookmark, load page | Card is in the wallet, often surfaced by relevance |
| Works offline | Partially | No | Yes — the pass is stored on the device |
| Maintenance burden | Two codebases, OS updates, store review cycles | One web app | Managed by the pass platform |
| Notifications | Full push, unlimited formats | Web push only, and poorly supported on iOS | Lock-screen updates tied to pass changes, with platform limits |
| Updates without user action | Requires app open or background fetch | On next page load | Pass updates remotely |
| Discoverability later | Buried on a home screen after a week | Lost bookmark | In the wallet the customer opens to pay |
| Development cost | Highest — build and maintain | Moderate | Lowest — configuration, not code |
| What it can do that others can't | Ordering, payment, rich browsing, camera, account management | Any web experience, deep-linked from anywhere | Sit permanently in the payment surface with no install |
Where an app genuinely wins: if your loyalty program is inseparable from ordering — a coffee chain where customers pre-order and pay in-app, a restaurant group with delivery — then the app is the product and loyalty is a feature of it. Building one purely so customers can show a barcode is the expensive way to solve a cheap problem.
If you already have an app your customers use weekly, put loyalty in it and issue a wallet pass — the pass reaches the customers who rarely open it. If you do not have an app, do not build one for loyalty. Start with the wallet pass; the install barrier is the single biggest cause of loyalty programs failing to reach critical mass.
- Three delivery routes: native app, web card, wallet pass. Only the app requires an install.
- Wallet passes work offline, update remotely, and live in the surface customers already open to pay.
- Apps win when loyalty is attached to ordering and payment; otherwise they are an expensive card holder.
- If you have an app already, run both — the pass reaches the people who never open it.
Designing the program
Customer data and consent, choosing the right reward mechanic, and worked example strategies for ten business types.
9. Customer data, privacy and consent
Collect the minimum data your reward rule needs, tell customers plainly what you are collecting and why, keep a record of consent for marketing, and know how you would delete someone's record on request. A loyalty program is a first-party data asset — which is exactly why it carries obligations.
Loyalty programs are one of the few remaining ways a physical business builds a genuine first-party relationship with its customers. That is their strategic value in a world of shrinking third-party tracking. It is also why they attract regulatory attention: a loyalty database is, by definition, a record of individuals and their behaviour.
| Field | Why it matters | Privacy weight | Practical guidance |
|---|---|---|---|
| Pseudonymous member ID | Links visits without naming anyone | Low | Prefer this as the primary key. It is often all a stamp card needs. |
| First name | Personalisation in messages | Low | Optional field, not a required one. |
| Email address | Secondary contact, account recovery | Medium | Only collect if you will actually email. Store consent separately. |
| Phone number | Counter lookup; SMS channel | Medium | Useful as an identifier — but SMS marketing consent is a separate permission. |
| Date of birth | Birthday rewards | Medium | Day and month are enough. Do not collect the year unless you need it. |
| Transaction amounts | Spend-based earning; average ticket | Medium | Aggregate where you can; you rarely need per-line detail. |
| Itemised basket / SKUs | Product-specific rewards | High | Purchase histories can be revealing. Collect only with a clear purpose. |
| Location visited | Multi-site attribution | Medium | Store-level is fine; precise geolocation is a different matter. |
| Communication consent | Lawful marketing | Required | Record what they agreed to, when, and how. Make opt-out one tap. |
Five practices that keep a loyalty database defensible
- Minimise at the point of design. Under the UK/EU GDPR, personal data must be "adequate, relevant and limited to what is necessary" for the purpose (Article 5(1)(c)). Decide the reward rule first, then collect only its inputs.
- Separate enrolment consent from marketing consent. Joining a stamp card is not agreement to receive weekly promotions. Capture them as two distinct permissions with two distinct records.
- Write a plain-English purpose statement on the enrolment screen: what you collect, why, how long you keep it, and how to leave. Two sentences beats a linked policy nobody opens.
- Know your deletion path. If a customer asks to be erased, can you do it without breaking your reconciliation? Test this once before you need it.
- Set retention limits. A member who has not visited in three years is not a marketing opportunity; they are a liability. Define an inactivity horizon and honour it.
This section describes general data-protection principles and is not legal advice. Requirements vary by jurisdiction — GDPR in the UK and EU, state privacy laws in the US, PIPEDA in Canada and others. Confirm your obligations with a qualified adviser before launching, particularly around SMS and email marketing consent.
- A pseudonymous member ID is enough for most stamp and visit programs.
- Enrolment consent and marketing consent are different permissions — record both.
- Data minimisation is a legal principle and an engineering simplification at the same time.
- Test your deletion path before a customer forces you to.
10. Designing the loyalty program
Pick the simplest mechanic that matches how your customers actually buy. Stamps suit frequent, similar-priced purchases. Points suit variable basket sizes. Tiers suit high-value relationships worth segmenting. Everything else — birthday, referral, product-specific, VIP — is a layer you add once the base mechanic is working, not a substitute for it.
The mechanics, and when each one is right
| Mechanic | How it works | Use when… | Avoid when… |
|---|---|---|---|
| Stamps | N purchases earns 1 reward | Purchases are frequent and similar in price | Basket sizes vary wildly — a £3 and a £30 stamp cost you differently |
| Points (spend-based) | Points per unit of currency spent | Basket size varies; you can access transaction amounts | Your POS won't expose amounts, or purchases are near-identical |
| Points (visit-based) | Fixed points per visit | You want points flexibility without transaction data | You need to reward big spenders more than frequent small ones |
| Tiers | Cumulative activity unlocks status levels | Customer value varies a lot and your top decile is worth protecting | You have fewer than a few hundred active members — tiers will feel empty |
| Product-specific rewards | Only certain items earn or redeem | You want to shift a specific category or protect margin on another | Your POS can't pass item data, or the rule confuses staff |
| Birthday reward | A one-off offer on or near a date | You collect day and month at enrolment | You have no channel to deliver it in time |
| Referral | Existing member earns for bringing someone new | Your product is socially shareable and margin supports two rewards | You can't attribute the referral reliably — it invites gaming |
| VIP / paid membership | Customers pay for ongoing benefits | Benefits are genuinely worth the fee and delivered consistently | You can't guarantee the benefit every visit |
Plot your business on two axes and read off the mechanic. Horizontal: purchase frequency (how often a typical customer buys). Vertical: basket variability (how much the value of each purchase differs).
High frequency · low variability → Stamps. The classic café case. Simple, visual, and the reward arrives often enough to feel real.
High frequency · high variability → Spend-based points. Convenience, grocery, pharmacy. Stamps would over-reward small baskets.
Low frequency · low variability → Visit-based points with a long horizon, or a tier. Salons, barbers, pet grooming. The reward must be worth waiting for.
Low frequency · high variability → Tiers. Furniture, jewellery, aesthetics, high-ticket retail. Recognition beats accumulation.
Figure 4 — The Loyalty Mechanic Selection Matrix™. Frequency and basket variability determine the mechanic; everything else is a layer on top. (Original PushNotice framework diagram.)
Three design rules that survive contact with a real counter
1. The reward must be reachable inside the customer's natural visit cycle. A ten-stamp card at a café someone visits twice a week pays out in five weeks — that works. The same card at a barber visited every six weeks pays out in fifteen months, which is not a loyalty program, it is a filing cabinet. Divide your reward threshold by the real visit frequency and ask whether anyone would wait that long.
2. A cashier must be able to explain it in one sentence. If your staff cannot describe the program while making a coffee, customers will never understand it. Complexity in the rules is paid for in staff time, every transaction, forever.
3. Decide the expiry policy before launch, not after. Unexpired balances accumulate as an open-ended liability. Expiry is legitimate and common — but it must be disclosed at enrolment and communicated before it bites, or it converts a loyal customer into an annoyed one.
- Frequency and basket variability determine the mechanic. Everything else is a layer.
- Divide your reward threshold by real visit frequency — if the wait exceeds a few months, redesign.
- If a cashier can't explain it in one sentence, it is too complex.
- Set expiry policy before launch and disclose it at enrolment.
Launching tiers with too few members. A "Gold tier" that three people reach is not aspirational — it is invisible. Run a single flat mechanic until you have enough active members for the top tier to be a visible minority rather than a rounding error.
11. POS loyalty program examples by business type
The right mechanic follows the visit pattern. High-frequency, low-ticket businesses (coffee, bakery, lunch) want stamps. Variable-ticket retail wants points. Appointment businesses (salon, spa, groomer) want visit-based rewards with a rebooking nudge. Multi-site and franchise operations want one customer identity across every location, which is the case POS-agnostic architecture exists to serve.
Everything below is an illustrative strategy showing how the architecture applies to a business type. None of it describes a specific named customer, and none of it contains measured results. Where a number appears, it is a plainly hypothetical parameter for a worked example.
| Business | Customer behaviour | Mechanic | POS data needed | Example reward | Key KPI |
|---|---|---|---|---|---|
| Coffee shop | 2–5 visits/week, near-identical ticket | Stamps (8–10) | None — counter scan is enough | Free drink of equal or lesser value | Visits per member per month |
| Restaurant | Monthly, variable party size | Spend-based points | Transaction amount | £10 off at 500 points | Repeat rate within 60 days |
| Retail store | Irregular, wide basket range | Points + seasonal tiers | Amount, optionally category | Early access to sale + points multiplier | Member share of total revenue |
| Salon | Every 4–8 weeks, appointment-driven | Visit points + rebooking nudge | Visit date | Free treatment add-on at 6 visits | Rebooking rate before leaving |
| Gym | Recurring membership, attendance varies | Membership card + attendance streaks | Check-in event | Guest pass at a 12-session streak | Monthly active members / churn |
| Spa | Occasional, high ticket | Tiers | Amount | Complimentary upgrade at tier 2 | Annual spend per member |
| Pet business | Predictable cycles (grooming, food) | Visit stamps + reorder reminder | Visit date, optionally product | Free groom at 6; food reorder prompt | Cycle adherence rate |
| Bakery | Daily or weekly, small ticket | Stamps | None — counter scan | Free item at 10 | Weekday visit frequency |
| Franchise | Same brand, independent operators | Central points, local redemption | Location + amount | Brand-wide reward, honoured anywhere | Cross-location redemption rate |
| Multi-location group | Customers use 2+ sites | Unified points across all sites | Location + amount | One balance, any site | Multi-site member percentage |
Two worked examples in more depth
Architecture: POS untouched. A wallet stamp card carries a unique QR code. The barista scans it on a tablet beside the till.
Mechanic: 9 stamps, 10th drink free. One stamp per visit, maximum one per day — a simple, explainable anti-abuse rule.
Wallet implementation: The pass shows stamps earned and stamps remaining. The balance change is the notification; a change message on the stamp field surfaces "8 of 9 — one to go" on the lock screen.
Notification strategy: Reserve deliberate broadcasts for genuinely new information — a reward about to expire, a new seasonal drink, a closure. The earning itself is already communicating.
KPI: average visits per member per month, compared before and after enrolment for the same customers.
Architecture: POS-agnostic by necessity. Neither vendor's native loyalty can span the other's tills, so the loyalty layer sits outside both. Sites on the POS with an accessible API use a webhook for automatic earning; the third site scans at the counter. Members see one balance regardless.
Mechanic: Spend-based points with a two-tier structure once the member base is large enough to make the top tier meaningful.
Wallet implementation: One pass design, location field indicating home store, balance and tier on the card.
Notification strategy: Segment by home store so a message about one site does not go to customers who never visit it.
KPI: percentage of members transacting at more than one site — the specific value this architecture creates.
- Match the mechanic to the visit pattern, not to what sounds impressive.
- High-frequency, low-ticket businesses need no POS data at all — a counter scan is sufficient.
- Mixed-POS estates make POS-agnostic architecture mandatory, not optional.
- Pick one KPI per program that would actually change your behaviour if it moved.
Buying, costing and proving it
A buyer's checklist, thirty questions vendors should be able to answer, an honest treatment of pricing models, and a framework for calculating return.
12. POS loyalty software: what to look for
Evaluate in this order: how the customer is identified at your counter, whether your data is exportable, how the program survives a POS change, then features. Most buyers do it backwards — features first, exit last — and discover the constraint that mattered only after they have migrated their customer list into it.
| Criterion | What to verify | Priority |
|---|---|---|
| Customer identity | How is a customer recognised at your counter, in your workflow, with your staff? Watch it happen before you buy. | Critical |
| Exportability | Can you export customers, identifiers and balances yourself, at any time, without asking support? | Critical |
| Migration & portability | What happens to the program if you change POS? If you change loyalty vendor? | Critical |
| POS compatibility | Named integration, generic barcode, import, or nothing? Get the specific answer, not "works with most POS." | Critical |
| Apple Wallet support | Real passes with remote updates, or a screenshot of a card? | High |
| Google Wallet support | Native Google Wallet objects, or an Android-shaped web page? | High |
| Staff usability | How many taps per transaction? Can a new hire do it unsupervised on day one? | High |
| Loyalty rules | Points, stamps, tiers, caps, exclusions, expiry — configurable without support tickets? | High |
| Data synchronisation | Latency, retry behaviour, and what happens to points if the sync fails | High |
| Segmentation | Can you target by visit recency, spend, tier and location — or only broadcast to everyone? | Medium |
| Notifications | What triggers a message, what the limits are, and whether you control frequency | Medium |
| Automation | Lapsed-customer triggers, reward-earned messages, expiry warnings | Medium |
| Analytics | Enrolment, active members, repeat rate, redemption rate — and can you export the raw numbers? | Medium |
| Multi-location | One balance across sites, per-site reporting, per-site permissions | Medium (critical if multi-site) |
| APIs & webhooks | Documented, accessible to you, and not partner-gated | Medium |
| Customer UX | How many steps from "interested" to "card saved"? Count them yourself on your own phone. | High |
| Privacy | What is collected by default, and can you turn fields off? | Medium |
| Security | Access controls, staff permissions, audit trail on manual balance edits | Medium |
| Pricing model | What meter grows fastest as you succeed? Model it at 3× your current size. | High |
Run the counter test before you sign anything: take a real transaction, at a real till, with a real staff member, at your busiest hour, and count the seconds the loyalty step adds. A program that adds noticeable delay at peak will quietly stop being used within weeks, no matter how good the dashboard is.
- Identity, exportability and portability outrank every feature on the list.
- Ask for the specific POS answer, not "works with most POS systems."
- Count the taps at the counter, at peak, with a real staff member.
- Model the pricing meter at three times your current size before you sign.
13. Thirty questions to ask before buying POS loyalty software
The questions that actually predict regret are about failure and exit, not features: what happens when the integration fails, how duplicate customers are handled, whether you can export balances, and what remains yours if you leave.
Integration and POS fit
- Does this work with my specific POS — and does "work with" mean an integration, or a scan at the counter?
- Is the integration real-time, near-real-time, or batch? What is the actual latency in minutes?
- Who builds and maintains the integration — you, me, or a third party?
- Does the integration require my POS vendor's approval, and how long does that take?
- What happens to earning if the integration fails for a day? Are events queued, retried, or lost?
- Can staff award or correct points manually when something goes wrong?
- Does the loyalty step require any new hardware?
Customer identity and data
- How is a customer identified at checkout, step by step?
- How do you handle the same person enrolling twice — is there duplicate detection or merging?
- What is the minimum data a customer must give to join?
- Can I turn off collection of fields I do not need?
- Can I export my full customer list, with identifiers and current balances, on demand?
- In what format is that export, and is it self-service or a support request?
- Where is customer data hosted, and what is your deletion process on request?
Wallet and customer experience
- Can customers use Apple Wallet, and is it a real pass with remote updates?
- Can customers use Google Wallet, and is it a native Google Wallet object?
- How many steps from seeing a QR code to having the card saved?
- What does the customer see when their balance changes, and can I control it?
- What notification limits apply, and are they yours or the platform's?
- Can customers redeem a reward at checkout without staff doing arithmetic?
Operations, scale and fraud
- Can I run this across multiple locations with one balance per customer?
- Can I run different rules or rewards per location?
- What staff permissions exist, and is there an audit trail on manual balance changes?
- How is loyalty fraud prevented — earning caps, one-scan-per-day rules, redemption verification?
- What happens if a customer loses their phone or deletes the pass?
Commercials and exit
- What exactly am I billed on — locations, members, transactions, messages, or a flat plan?
- What does this cost at three times my current volume?
- Are there implementation, integration, onboarding or migration fees?
- What is the contract term and notice period?
- If I leave, what do I keep — and what happens to my customers' saved wallet cards and balances?
Question 30. A vendor that answers it clearly and without defensiveness is telling you they expect to keep you by being good. A vendor that gets vague is telling you where their retention strategy actually lives.
14. POS loyalty costs and total cost of ownership
POS loyalty is priced in five common ways — flat subscription, per location, per member, per loyalty event, and usage or message volume — plus one-off implementation and integration fees. The published-price end of the market runs from free tiers to roughly $25–$200 per month; the enterprise end publishes nothing and quotes on request. The meter that matters is the one that grows fastest when your program succeeds.
The pricing models
| Model | You pay for… | Predictability | Risk |
|---|---|---|---|
| Flat monthly subscription | Access to the platform | High | Plan ceilings you may outgrow |
| Per location | Each site, each month | High | Scales linearly with expansion, not with value |
| Per member / per contact | Size of your customer database | Medium | Success is punished; inactive members still bill |
| Per loyalty event / transaction | Each enrolment, earn or redemption | Low | Your best month is your most expensive month |
| Usage / message volume | Campaigns or notifications sent | Medium | Encourages under-communicating, or surprises you |
| Enterprise / quoted | A negotiated bundle | Medium | No public benchmark to negotiate against |
Published, self-serve pricing exists — but mostly at the independent end of the market. Loopy Loyalty publishes $25, $69 and $95 per month tiers. PassKit publishes "plans from $39.50/month" on a platform-fee-plus-usage model. Stamp Me publishes $49, $79 and $199 per month. PushNotice publishes Free, $29 and $79 per month plans with an Agency tier quoted on request.
Among POS vendors, disclosure is patchy. Square's US pricing page lists Square Free at $0, Square Plus at $49 per location per month and Square Premium at $149 per location per month, with "loyalty rewards program" listed as a feature under Plus and Premium; Square's Canadian site still publishes a visit-banded loyalty price — CA $60 / $100 / $140 per calendar month, per location, across three bands of loyalty visits — so the visit-metered model has not disappeared, it has simply stopped being uniform across markets. Toast's pricing page marks loyalty as available with an add-on where "additional fees may apply" and publishes no figure for it. Lightspeed lists in-store and online loyalty inside its published Retail plans (Basic $89, Core $149, Plus $289 per month) but publishes no standalone price for loyalty itself. Clover's pricing pages did not render to automated retrieval, so no Clover figure is quoted here.
The enterprise loyalty platforms publish nothing. Paytronix, Punchh, Como and Fivestars/SumUp Connect all quote on request. Verify every figure above at the vendor's own site before relying on it — pricing in this category changes without notice and varies by country.
Total cost of ownership over your evaluation horizon (use 24 months):
TCO = Software + Integration + Implementation + Staff training + Maintenance + Migration + Reward cost
Software — the subscription, priced at your expected size in month 24, not today's.
Integration — build or connector fees, plus any partner-programme cost, plus developer time at your real hourly rate.
Implementation — setup, pass design, rule configuration, signage and enrolment materials.
Staff training — hours × wage × number of staff × turnover multiplier. In hospitality and retail this is the line most often set to zero and most often wrong.
Maintenance — the ongoing cost of keeping an integration alive when either side updates; add a monthly allowance even if you expect none.
Migration — importing an existing customer list in, and the estimated cost of getting it out again later.
Reward cost — the actual margin cost of rewards redeemed. This is the largest line for most programs and the one most frequently left out of the software comparison entirely.
A two-site business, 24-month horizon. Software $79/month = $1,896. No integration (counter scanning) = $0. Implementation, design and signage = $400. Staff training, 8 people × 1 hour × $15, twice over two years for turnover = $240. Maintenance = $0. Migration in and out, estimated = $300. Reward cost: assume 400 rewards redeemed over two years at $2.50 marginal cost = $1,000. Two-year TCO ≈ $3,836, of which the software is under half. Every number here is invented for the purpose of demonstrating the method. Substitute your own.
- Five common meters; the dangerous ones scale with your success rather than your capacity to pay.
- Published pricing is concentrated among independent wallet and loyalty tools; enterprise platforms quote on request.
- Reward cost is frequently the largest TCO line and is routinely excluded from software comparisons.
- Price the plan you will need in month 24, not the plan you need this week.
15. How to calculate POS loyalty ROI
Estimated incremental contribution = (incremental visits × contribution per visit) + (incremental spend per visit × visits) + retained margin from reduced churn + reactivated customer margin − reward cost − software cost − implementation cost. It is a framework for structuring an estimate, not a promise of a result — the honest version depends on a baseline you measure before you launch.
Estimated incremental contribution =
(ΔVisits × contribution per visit)
+ (ΔSpend per visit × total member visits)
+ Retention value (churn avoided × margin per retained customer)
+ Reactivation value (lapsed customers returned × margin)
− Reward cost (redemptions × marginal cost)
− Software cost
− Implementation cost
The framework only works if you capture a baseline first. Before launch, record: average visits per customer per month, average transaction value, and the share of revenue from repeat customers. Without those three numbers, every ROI figure produced afterwards is decoration.
Figure 5 — The Loyalty ROI Framework™. Four sources of value, three costs, one net figure — all of it dependent on a pre-launch baseline. (Original PushNotice framework diagram.)
A café with 500 enrolled members. Baseline (measured before launch): members averaged 4.0 visits/month; average ticket £4.20; contribution margin 65% = £2.73 per visit.
After six months, suppose member visits average 4.6/month. ΔVisits = 0.6 × 500 × 6 months = 1,800 extra visits × £2.73 = £4,914. Suppose average ticket is unchanged: ΔSpend = £0. Retention and reactivation: not separately measured, counted as £0 to stay conservative.
Costs: 260 free drinks redeemed × £1.40 marginal cost = £364. Software 6 × £24 = £144. Implementation = £250.
Estimated incremental contribution ≈ £4,156.
The honest caveats: members self-select — the people who join a loyalty program were probably already your better customers, so some of that 0.6-visit lift would have happened anyway. Seasonality is not controlled for. The only rigorous version of this measurement compares enrolled and matched non-enrolled customers over the same period. Treat the output as an estimate with a wide error bar, not a result.
- Four value sources, three costs, one net estimate.
- Capture visits, ticket and repeat share before you launch, or the ROI number is meaningless.
- Self-selection inflates naive before/after comparisons; a matched non-member group is the fix.
- Count reward cost at marginal cost, not retail price.
Valuing redeemed rewards at menu price. A free coffee is not a £4.20 cost; it is the cost of the cup and the beans. Overstating reward cost makes healthy programs look unprofitable and kills them prematurely.
16. Common POS loyalty mistakes
The most expensive mistake is switching POS unnecessarily. The most common is designing a rewards program without designing the counter workflow. The most persistent is launching with no measurement baseline, which makes it impossible to tell later whether the program is worth keeping.
| Mistake | What it looks like | Fix |
|---|---|---|
| Switching POS unnecessarily | A six-month migration to get a rewards feature | Add a loyalty layer to the POS you have |
| Collecting too much data | A six-field signup form that customers abandon at the counter | Ask for the minimum; enrich later if the customer stays |
| Over-complicated rewards | Tiers, multipliers, exclusions and blackout days at launch | One rule, one sentence. Add complexity only after adoption |
| Weak customer identification | Staff ask for a phone number, customers refuse, nothing is recorded | Make identification one scan the customer initiates |
| No staff training | Half the team never mentions the program | Train on the one-sentence pitch and the one-tap workflow; refresh with turnover |
| No expiration strategy | Balances accumulate for years as an open liability | Set expiry at launch, disclose it, warn before it applies |
| Excessive notifications | Three promotions a week; pass deletions climb | Let balance changes do the talking; broadcast only genuinely new information |
| No segmentation | Every message goes to everyone, including today's customers | Segment by recency and location at minimum |
| No measurement | "It feels like it's working" | Baseline before launch; review one KPI monthly |
| Vendor lock-in | Customer list and balances only visible inside one dashboard | Verify self-service export before you enrol anyone |
| Poor migration planning | Existing paper-card holders are abandoned mid-card | Honour existing progress; convert with a transition offer |
| No fallback when the integration fails | A sync outage silently loses a day of points | Manual award capability, plus a queue-and-retry policy you have actually tested |
Treating loyalty as a marketing project rather than an operations one. The rules, the design and the campaigns are the easy half. The hard half is a workflow that a tired member of staff performs correctly a hundred times a day. Design that first.
Launching and staying portable
A four-week plan from strategy to launch, the portability checklist that protects you from your next POS decision, and architecture recommendations by business size.
17. A 30-day POS loyalty migration and launch plan
Week 1 is strategy and baseline measurement. Week 2 is technical setup — pass design, rules, and whatever connection you are using. Week 3 is testing with real staff and real transactions. Week 4 is launch and the first round of tuning. The single most-skipped step is week 1's baseline, and skipping it costs you the ability to prove anything in month six.
Week 1 — Strategy and baseline
- Decide the mechanic using the Loyalty Mechanic Selection Matrix™ (Section 10).
- Write the reward rule in one sentence a cashier could say out loud.
- Record your baseline: average visits per customer per month, average transaction value, repeat-revenue share.
- Decide the identification method at the counter and walk through it physically.
- Set the expiry policy and the earning cap (for example, one stamp per customer per day).
- Confirm what data you will collect at enrolment, and what you will not.
- Choose one KPI you will review monthly.
Week 2 — Technical setup
- Build the pass design: logo, colours, the fields the customer needs to see, barcode format.
- Configure earning rules, reward thresholds, caps and expiry.
- Set up whichever connection applies: counter scanning, scheduled import, webhook or API.
- Import an existing customer list if you have one, and de-duplicate it.
- Create enrolment assets: counter QR code, receipt line, window sticker, email footer.
- Write the three messages you will actually send: welcome, reward-earned, reward-expiring.
- Set staff permissions and enable the audit trail on manual balance edits.
Week 3 — Testing
- POS test: run a full transaction including the loyalty step. Time it at simulated peak.
- Wallet test: save the pass on both an iPhone and an Android device. Confirm it renders correctly.
- Update test: change a balance and confirm the pass updates on both devices.
- Notification test: confirm the lock-screen message appears and reads correctly on both platforms.
- Reward validation: earn a reward end to end and redeem it at the till.
- Data validation: export your customer list and check identifiers and balances are correct and complete.
- Failure test: disconnect the integration deliberately and confirm staff can still award points manually.
- Staff training: every team member enrols themselves, earns, and redeems once.
Week 4 — Launch and optimise
- Soft-launch for two or three days with staff enrolling regulars they know by name.
- Put the QR code where customers already wait — the till, the card machine, the receipt.
- Migrate paper or plastic card holders: honour existing progress and give a small transition bonus.
- Watch enrolment rate daily; if enrolment is much lower than you expected, the problem is almost always placement or the staff ask, not the reward.
- Review at day 30 against your week-1 baseline and adjust one variable only.
Migrating paper-card holders is the highest-yield hour of the whole launch. Someone carrying a half-full punch card has already shown you the behaviour you want. Honour their stamps, convert them in person, and you start with an engaged cohort instead of an empty database.
- Four weeks: strategy and baseline, setup, testing, launch and tuning.
- Test the failure path, not just the happy path.
- Test the pass on both an iPhone and an Android handset — they behave differently.
- Convert paper-card holders in person; they are your most engaged starting cohort.
18. Can you change POS later?
Yes — if you designed for it. A loyalty program survives a POS change when the customer identifier, the balance data and the customer's saved card all live outside the POS. If those three things live inside your POS vendor's product, a POS change is a loyalty restart: new cards, lost balances, and a re-enrolment campaign you will not enjoy running.
This is where the argument in this article stops being theoretical. Businesses change POS for reasons that have nothing to do with loyalty — a processor dispute, an acquisition, a new site format, a vendor sunsetting hardware, a price rise. When that day comes, the question is not whether your loyalty program is good. It is whether it is attached.
Score one point for each item you can answer "yes" to today. This is the checklist to run before you sign, not after.
| # | Portability question | Why it matters |
|---|---|---|
| 1 | Is the customer identifier owned by the loyalty layer, not generated by the POS? | A POS-generated ID dies with the POS, taking the link to every historic visit with it |
| 2 | Can you export customers, identifiers and balances yourself, without a support ticket? | Self-service export is the difference between leaving and being released |
| 3 | Is the export in an open format (CSV or JSON) with stable column names? | A PDF report is not an export |
| 4 | Do the loyalty rules live in a system you can reconfigure independently? | Rules encoded in POS settings are rebuilt from scratch on migration |
| 5 | Is the customer's card in Apple Wallet or Google Wallet rather than the POS app? | A wallet pass can be updated to point at a new backend; a POS app cannot |
| 6 | Does the wallet pass survive if the loyalty backend changes? | Ask specifically: can the pass be re-pointed, or must customers re-save? |
| 7 | Is the integration a documented connector rather than a bespoke build? | Bespoke integrations are rebuilt; connectors are reconnected |
| 8 | Is there any API or webhook access you could use to migrate data yourself? | Your escape hatch when the export UI is inadequate |
| 9 | Is your contract term shorter than your POS commitment? | Otherwise the loyalty contract dictates the POS decision |
| 10 | Have you actually run an export in the last 90 days and opened the file? | Untested exports fail exactly when you need them |
8–10: a POS change is a reconnection project measured in days. 5–7: a POS change costs you some history and some rebuilding — plan a month. 0–4: a POS change is a loyalty restart. Fix items 1, 2 and 5 first; they carry the most weight.
Portability is not uniform across vendors, and it is worth checking rather than assuming. Toast publishes a support article explicitly titled "Export Toast Loyalty Data for Third-Party Use," documenting a self-serve export from its reporting section — the clearest published export path we found for a POS-native loyalty product. Shopify documents CSV export of customers, though loyalty balances live in whichever third-party app you use. Lightspeed documents customer-data export for Retail; whether loyalty balances appear as a column in that export is not documented. Square documents CSV report export generally and states that loyalty reporting is viewable from Square Dashboard, with its Loyalty API as the documented programmatic route to balances. Clover publishes no loyalty or rewards API resource in its API reference. Confirm current behaviour with your own vendor before relying on any of this.
- A loyalty program survives a POS change when identifier, balances and the saved card all live outside the POS.
- Self-service export in an open format is the single most important portability property.
- A wallet pass is portable in a way a POS app screen is not.
- Run the export once, now, while nothing is wrong.
19. Best POS loyalty architecture by business type
Small single-site businesses should use whatever requires no integration. Growing and multi-location businesses should own the customer layer outside the POS. Franchises must, because franchisees will never standardise. Enterprises should treat loyalty as an integration decision with a formal exit plan.
| Profile | Recommended architecture | Why |
|---|---|---|
| Small business, one site | POS-agnostic, counter scanning, wallet pass | Zero integration cost, works with any POS, launches in a day, and nothing is stranded if the POS changes |
| Growing SMB (2–5 sites) | POS-agnostic with one customer database; add a webhook where the POS supports it | One balance per customer across sites matters more than automation; add automation where it is cheap |
| Multi-location (6+) | POS-agnostic, integrated where possible, with per-site reporting | Staff turnover makes manual steps fragile at scale; automate the earning, keep identity central |
| Franchise network | POS-agnostic, mandatory, with central governance and local redemption | Franchisees choose their own POS and will not migrate for head office; only the loyalty layer can be standardised |
| Enterprise | Integrated loyalty platform, formal API contract, documented exit plan | At this scale integration is affordable — but so is lock-in. Contract for data return explicitly |
| DTC brand + physical retail | POS-agnostic with online enrolment and one identity across both | The customer is the same person in both channels; the wallet pass is the bridge that makes them one record |
| No mobile app, no plans for one | Wallet-first, barcode-identified | The wallet is the app you do not have to build, and it is already installed |
| Existing app with real usage | Loyalty in the app and a wallet pass | The pass reaches the customers who rarely open the app |
20. PushNotice and POS loyalty
PushNotice can act as the wallet and customer-engagement layer of a POS loyalty program — layers 4 and 5 of the POS Loyalty Layer Model™, with loyalty logic and a customer database alongside. It sits beside your existing POS rather than replacing it. We do not claim a native integration with any named POS system, because we do not have one to claim.
Having spent this guide arguing that the loyalty layer should be separable from the POS, it would be poor form to now describe our own product as something it is not. Here is the accurate version.
What PushNotice does
PushNotice is a wallet marketing platform. Businesses design a pass — a loyalty or stamp card, a membership or store card, a coupon, an event ticket, or a generic pass — and customers save it to Apple Wallet or Google Wallet with one tap, with no app to download and no account to create. Every pass carries a scannable barcode or QR code, which is what makes it work at a point of sale: the code can be scanned by whatever scanner is already at your counter, with no special hardware and no dependency on which POS you run. The platform includes a customer database, tagging and segmentation, campaign broadcasts with targeting and scheduling, an analytics dashboard covering installs and engagement, and white-label workspaces for agencies managing multiple clients. Published plans start at a permanently free tier and run to $79/month for Pro, with an Agency tier quoted on request.
Notifications work the way both wallet platforms intend: a push triggers the device to fetch the latest pass, and the updated pass content is what appears on the lock screen. Once installed, passes are stored on the device and work offline.
What PushNotice does not do — stated plainly
| Capability | Status | Detail |
|---|---|---|
| Apple Wallet passes | Yes | Built on Apple's PassKit framework; remote updates and lock-screen delivery |
| Google Wallet passes | Yes | Android users receive the Google Wallet version of the same link automatically |
| Loyalty / stamp cards | Yes | A core pass type |
| Membership cards, coupons | Yes | Core pass types |
| Works at any POS via barcode | Yes | Every pass carries a scannable code readable by standard scanners |
| Named native POS integrations | No | We do not currently publish an integration with any named POS system. If you need automatic earning driven by POS transactions, ask us about your specific setup rather than assuming |
| Public developer API / webhooks | Not published | No public developer API or webhook documentation is published at the time of writing. Do not assume programmatic access without checking with us first |
| Customer database & segmentation | Yes | Tagging and segmentation available on Pro; tracking of installs and engagement across plans |
| Multi-location / multi-client | Yes | Workspaces — 1 on Free and Starter, 5 on Pro, white-label on Agency |
| Enterprise POS integration projects | Talk to us | Not a published capability; a conversation, not a checkbox |
Where PushNotice fits the architecture in this guide is the loose-coupling end: POS → your customer and loyalty data → wallet pass → customer notification, with identification at the counter handled by scanning the pass. That is the right fit for a business that wants a modern loyalty card in Apple Wallet and Google Wallet without an integration project, and the wrong fit for a business that requires points to post automatically from an enterprise POS with no human step. Both of those are legitimate requirements. Only one of them is ours.
If your POS already includes loyalty in a plan you pay for, you run one site, and you have no intention of changing POS — use it. If you need certified NFC tap-to-earn on enterprise terminals, you need a platform with a certification programme and terminal partnerships. If you need deep programmatic control over pass issuance at very high volume, a developer-first wallet infrastructure platform is a better foundation. Saying so is the point of writing an honest guide.
21. POS loyalty vs mobile app loyalty vs wallet loyalty
POS-native loyalty has the lowest customer friction at the till and the highest lock-in. App loyalty has the richest capability and the highest install barrier. Wallet loyalty has the lowest joining friction and the best portability, but it depends on an identification step at the counter that the other two can automate.
| Dimension | POS-native loyalty | Mobile app loyalty | Wallet loyalty |
|---|---|---|---|
| Customer friction to join | Give a phone number at the till | Download, register, verify | Scan a QR, one tap to save |
| Install requirement | None | App store download | None — wallet is pre-installed |
| Friction at the counter | Lowest — built into the till flow | Open app, find code | Open wallet, show code |
| Maintenance | Vendor's problem | Yours — two platforms, ongoing | Platform's problem |
| Notification capability | Usually email/SMS bolt-on | Full push, rich formats | Lock-screen pass updates, with platform limits |
| Customer reach | Only customers who transact at that POS | Only customers who installed | Anyone with a phone |
| Development cost | None | High and recurring | Configuration only |
| Loyalty visibility between visits | Invisible — lives in the POS | Visible if the app is opened | Visible in the wallet, updated remotely |
| Cost shape | Bundled or per location | Build + maintain + platform | Subscription, often flat |
| Portability if you change POS | Program ends | Unaffected | Unaffected |
| Best for | Settled single-site businesses | Brands where ordering and payment are in-app | Everyone else, and anyone who might change POS |
22. The future of POS loyalty
The direction of travel is loyalty becoming less coupled to the till and more coupled to the customer: wallet-native cards, first-party data as the durable asset, real-time balance updates as the default, and privacy constraints tightening what can be collected. The hype worth ignoring is anything promising personalisation that your data volume cannot actually support.
Wallet-native loyalty is becoming the default form factor. Both Apple and Google continue to invest in the pass surface, and each release has widened what a loyalty pass can display and how it can be presented. The practical consequence for merchants is that the wallet card improves without you doing anything — check each platform's current developer release notes rather than relying on a snapshot like this one.
First-party customer data becomes the durable asset. As third-party tracking continues to erode, a consented list of customers who have chosen to carry your card is one of the few marketing assets that does not depend on a platform's permission. That raises the stakes on portability: an asset you cannot export is an asset you are renting.
Real-time is becoming the expectation, not the differentiator. Customers who see a balance change immediately on a payment card increasingly expect the same from a loyalty card. Batch programs will still work; they will just feel older.
AI personalisation is real but over-sold at small scale. Predictive reward targeting needs volume to work. A café with 400 members does not have enough signal for a model to beat a well-designed rule like "hasn't visited in 21 days." Be sceptical of personalisation claims until you have thousands of active members and months of history.
Privacy-first design is becoming a constraint, not a virtue signal. Expect tighter consent requirements and greater scrutiny of behavioural profiling. Programs designed on minimal data will age better than programs designed on maximal collection.
POS-independent architecture is the structural trend underneath all of it. Businesses that separated customer identity from the till are the ones able to adopt each of the above without a migration. That is not a prediction; it is just what layering does.
23. The PushNotice POS Loyalty Architecture Benchmark 2026
This is a PushNotice editorial evaluation of loyalty architecture categories against nine documented criteria. It is not independent third-party research, it contains no survey data, and it scores architecture patterns rather than ranking named products.
We do not have proprietary industry research on POS loyalty, and we are not going to invent any. What follows is a PushNotice editorial evaluation: a structured assessment of the four architecture categories against nine criteria drawn from documented technical requirements — vendor API documentation, Apple and Google wallet documentation, and published export capabilities, all cited in the Sources section. Scores are our editorial judgement of the category, expressed on a 1–5 scale. They are reasoning made explicit, not measurement. Individual products within a category will vary.
| Criterion | POS-native | POS-integrated | POS-agnostic | Standalone |
|---|---|---|---|---|
| POS independence | 1 | 2 | 5 | 5 |
| Integration flexibility | 1 | 4 | 4 | 1 |
| Wallet support | 3 | 3 | 5 | 4 |
| Data portability | 2 | 3 | 5 | 4 |
| Customer identity ownership | 2 | 3 | 5 | 5 |
| Automation of earning | 5 | 5 | 3 | 1 |
| Segmentation depth | 2 | 4 | 4 | 3 |
| Analytics joined to sales | 5 | 4 | 2 | 1 |
| Implementation simplicity (5 = simplest) | 5 | 2 | 4 | 5 |
| Unweighted total (max 45) | 26 | 30 | 37 | 29 |
How to read this responsibly. The totals are unweighted, which means they are almost certainly wrong for your business. Weight the criteria yourself. A single-site café that will never change POS should weight "automation of earning" and "implementation simplicity" heavily, at which point POS-native wins outright. A franchise network should weight "POS independence" and "customer identity ownership" at triple, at which point POS-agnostic wins by a wider margin than shown. The value of the table is the criteria list, not the arithmetic.
Our disclosed bias. PushNotice sells a product that sits in the POS-agnostic category, which scores highest here. We have tried to counteract that by scoring the categories where POS-native genuinely wins — automation and joined analytics — at the maximum, and by scoring our own category's weakest points honestly. Read the criteria, apply your own weights, and discount our judgement accordingly.
24. Downloadable resources
Ten companion resources turn this guide into a working toolkit: a vendor comparison spreadsheet, an RFP template, integration and portability checklists, an ROI calculator, a planning worksheet, a migration checklist, a data mapping template, the architecture diagram, and a vendor scorecard.
A pre-built grid with the 19 criteria from Section 12 as rows and blank vendor columns, with scoring and weighting built in.
For: owners and operations leads shortlisting 3–6 vendors. Why link to it: it is the only comparison template that scores portability and exit alongside features.
Download the comparison sheet →A ready-to-send request for proposal covering integration method, latency, data ownership, export, security, fraud controls, support and exit terms.
For: multi-location and franchise buyers running a formal process. Why link to it: free RFP templates for this category barely exist.
Download the RFP template →Every question to ask your POS vendor and your loyalty vendor before committing, including failure handling, retries and manual fallback.
For: whoever will own the integration. Why link to it: it is the practical companion to any POS API documentation.
Download the integration checklist →The ten-point scored checklist from Section 18, as a one-page PDF you can complete during a vendor demo.
For: anyone signing a loyalty contract. Why link to it: it names a risk the category systematically under-discusses.
Download the portability checklist →A spreadsheet implementation of the Loyalty ROI Framework™, with baseline capture fields and a matched-cohort comparison tab.
For: owners and finance. Why link to it: it models selection bias instead of ignoring it.
Open the ROI calculator →One page to define mechanic, threshold, expiry, caps, identification method, enrolment channels and the single KPI.
For: first-time program designers. Why link to it: it forces the counter workflow decision before the rewards decision.
Download the worksheet →The 30-day plan from Section 17 as a task list, including the failure test and the paper-card conversion step.
For: whoever runs the launch. Why link to it: it includes the tests most launches skip.
Download the migration checklist →A field-by-field map from POS fields to loyalty fields to wallet pass fields, with a privacy-weight column per field.
For: technical implementers and privacy reviewers. Why link to it: it connects integration design to data minimisation in one artefact.
Download the mapping template →The POS Loyalty Layer Model™ and the POS-agnostic flow as editable, attribution-licensed SVG and PNG.
For: consultants, agencies, analysts and educators. Why link to it: reusable diagrams earn citations on their own.
Download the diagrams →The nine benchmark criteria as a weighted scorecard, so you can apply your own weights instead of ours.
For: committees and multi-stakeholder decisions. Why link to it: it makes a subjective decision auditable.
Download the scorecard →Reference
Fifty-two questions answered, our methodology and disclosures, and the primary sources behind every verified claim in this guide.
25. Frequently asked questions
The three questions that come up most: yes, you can almost always add loyalty without changing your POS; no, Apple Wallet and Google Wallet do not connect to a POS by themselves; and yes, a properly designed program survives a POS change — but only if the customer identifier, the balances and the saved card all live outside the POS.
Basics
What is a POS loyalty program?
A POS loyalty program is a customer rewards program connected to a point-of-sale system, so that purchases made at checkout can identify a customer and earn or redeem rewards. The POS supplies the fact that a purchase happened; the loyalty system holds the customer record, the rules and the balance. The connection can be a cashier scanning a barcode or an automated software integration.
How does POS loyalty work?
Every POS loyalty program follows five steps: the customer enrols and is issued an identifier; that identifier is presented and captured at the counter; the purchase or visit is attributed to their record; the loyalty rules calculate points, stamps or tier changes; and the new balance is shown back to the customer. Only the identification step has to happen at the counter.
Can I add loyalty without changing my POS?
Yes. In most cases you can add a loyalty layer that runs alongside your existing POS without replacing or modifying it. The simplest architecture requires no software connection at all: the customer shows a barcode or QR code, a staff member scans it, and the loyalty platform records the visit. Nothing about the POS changes.
Does loyalty software have to replace my POS?
No. A POS is the system of record for transactions — items, prices, tax, tender, stock. A loyalty program is the system of record for customers — identity, rules, balances. Those are different jobs and they do not need to be in the same product. Any vendor telling you a POS change is required for loyalty is describing their product boundary, not an architectural constraint.
What is the difference between POS loyalty and standalone loyalty?
POS loyalty ties earning and redemption to the checkout transaction, either through a staff-performed scan or a software integration. Standalone loyalty operates independently of the POS entirely — customers are tracked manually or through a separate channel. POS loyalty produces cleaner data and less staff effort; standalone loyalty is simpler but harder to keep accurate.
What is POS-agnostic loyalty?
POS-agnostic loyalty keeps the customer record, the rules and the balance in a platform that sits outside the POS, so the program works with any point-of-sale system and survives a POS change. It connects as loosely or as tightly as your operation needs — from a barcode scan at the counter to a real-time API integration.
Do I need a loyalty program at all?
Only if repeat business matters to your economics. If most of your revenue comes from one-time visitors — a motorway service station, a tourist site — a loyalty program is a poor investment. If a meaningful share of revenue comes from people who could reasonably return within a month, it is one of the cheapest retention levers available.
Integration
How does POS loyalty integration work?
There are seven common methods: counter scanning with no integration at all; manual CSV import; scheduled batch import; webhooks pushed from the POS; a real-time API; middleware or an iPaaS connector between the two systems; and a POS-native integration published in the POS vendor's marketplace. They differ in latency, effort, and whether they work with any POS.
Can loyalty work with any POS system?
Barcode-based loyalty works with any POS, because it does not touch the POS at all — it works alongside it. Automated integration works only with POS systems that expose an accessible API or webhooks, and several POS vendors gate that access behind a partner approval process. Confirm your specific POS's capability before designing around automation.
What POS data does loyalty software need?
At most: a customer identifier, a transaction identifier for de-duplication, the purchase amount, the date and time, and the location. Most programs need far less. A stamp card needs only 'customer X visited on date Y.' Collect the minimum your reward rule requires — every extra field is a privacy obligation and a dependency that can break.
Do I need an API to run POS loyalty?
No. An API enables automatic earning, but a barcode scan at the counter achieves the same customer experience without one. APIs matter most when you want points to post without a human step, or when you want customers to redeem rewards directly at checkout.
What is the difference between real-time and batch synchronisation?
Real-time means the balance updates within seconds of the sale — the customer sees it before they leave. Batch means transactions are collected and processed on a schedule, usually nightly. Real-time is required for same-visit redemption and points-per-dollar earning. Batch is perfectly adequate for stamp cards and visit counts, and it fails more gracefully because a missed batch can simply be re-run.
What happens if my POS integration fails?
That depends on the design, which is why it is worth asking before you buy. A well-built integration queues events and retries them, so a temporary outage catches up. A poorly built one silently drops the events, and customers lose points they earned. Always confirm that staff can award points manually as a fallback.
Can loyalty work across multiple POS systems?
Only POS-agnostic loyalty can. A POS vendor's native loyalty feature runs on that vendor's POS and cannot span a competitor's tills. If you operate sites on different POS systems — common after an acquisition, and normal in franchising — a POS-independent loyalty layer is the only architecture that gives every customer one balance.
Does POS loyalty require new hardware?
Usually not. If your loyalty program identifies customers by barcode, you need a barcode scanner or a phone camera, both of which most businesses already have. New hardware is only required for NFC tap identification, which needs a certified reader on both Apple's and Google's protocols.
How does a POS know a customer is a loyalty member?
It generally does not — something else tells it, or tells the loyalty platform. The four common methods are: a barcode or QR code on the customer's wallet pass being scanned; a phone number or member ID looked up at the till; an NFC tap on a certified terminal; or a match against an online order record. This is the customer identity layer, and it is the part most often overlooked in planning.
Wallet
Can customers use Apple Wallet for POS loyalty?
Yes. Apple Wallet's storeCard pass style is described by Apple as appropriate for store loyalty cards, discount cards and points cards. The pass can carry a member identifier, a scannable barcode, a balance and a tier, and it can be updated remotely so the balance changes without the customer doing anything. Apple Wallet does not connect to your POS by itself — identification and synchronisation still have to be provided.
Can customers use Google Wallet for POS loyalty?
Yes. Google Wallet's Loyalty API provides a loyalty class as the shared template and a loyalty object per customer, with native fields for a points balance, a secondary balance, a rewards tier, an account identifier and a barcode. The object is updated server-side through Google's REST API. As with Apple, the wallet is a container — it does not talk to your POS on its own.
Does Apple Wallet or Google Wallet integrate with my POS automatically?
No, and this is the most important accuracy point in the category. Both wallets are containers for passes. They have no knowledge of your point-of-sale system and no automatic connection to it. Two things must be provided by you or your loyalty platform: an identification step at the counter, and a synchronisation step that updates the pass after the balance changes.
How does an Apple Wallet loyalty card update?
Your loyalty platform hosts a pass web service. When a balance changes it sends a push to every device registered for that pass — Apple's documentation specifies an empty JSON dictionary as the payload, so the push carries no content. The device then fetches the updated pass from your web service. Apple also documents that push notifications for pass updates work only in the production environment.
How does a Google Wallet loyalty card update?
The pass object lives on Google's servers. Your platform calls the REST API to update or patch the loyalty object, and the change applies to that holder without a per-device handshake. Google documents that changes to a class propagate immediately across all objects that reference it, so a single class edit affects everyone holding that card.
Will the customer get a notification when their balance changes?
Only if you set it up that way. On Apple, a field must carry a change message — Apple states you need to provide a value for the system to show a change notification. On Google, notifications fire either from a message added with the notify option, or from an update where the notify preference is set and the changed field is on Google's allow-list, which for loyalty includes the points balance and the rewards tier.
Are there limits on wallet notifications?
Google publishes a hard limit: a maximum of three messages that trigger a push notification in any 24-hour period, and a maximum of ten messages on the object. Apple does not publish an equivalent numeric cap, but alerts only fire on fields that have changed and that carry a change message. In practice both platforms are designed to keep pass notifications meaningful rather than promotional.
Can a wallet pass send location-based notifications?
On Apple, a pass can list up to ten locations and up to ten beacon identifiers, but Apple describes relevance as passive — it surfaces the pass on the lock screen when the customer is nearby, it does not post a notification. On Google, the locations field exists but Google's own reference marks it as not currently supported for triggering geo notifications.
What barcode formats work on a wallet loyalty card?
Apple Wallet supports QR, PDF417, Aztec and Code 128. Google Wallet supports barcodes on the loyalty object and, where certified, NFC reading via Smart Tap. QR is the safest default because virtually every modern scanner and phone camera reads it.
Can customers tap their phone instead of scanning?
Technically yes, but it requires certification on both platforms. Apple's Value-Added Services protocol requires an NFC certificate from Apple, a VAS-certified reader, and POS software that supports VAS modes. Google's Smart Tap requires certification, an eight-digit collector ID, a public-key exchange, and specific fields enabled on the loyalty class and object. Barcodes need none of this.
Can loyalty work without a mobile app?
Yes — and for most businesses it should. Apple Wallet is pre-installed on every iPhone and Google Wallet is available on most Android phones, so a customer can save a loyalty card in one tap with no download and no account creation. Building a mobile app purely so customers can show a barcode is an expensive solution to a cheap problem.
What happens if a customer deletes their wallet pass?
Their balance is not lost — it lives in your loyalty platform, not on the phone. They can re-save the pass using the same enrolment link or QR code and their record is intact. This is one of the practical advantages of keeping the customer record outside the wallet and outside the POS.
Choosing
What should I look for in POS loyalty software?
In order of importance: how the customer is identified at your specific counter; whether you can export customers, identifiers and balances yourself at any time; what happens to the program if you change POS; and only then features like segmentation, automation and analytics. Most buyers evaluate that list backwards.
What are the best POS loyalty options?
There is no single best option — the honest answer depends on your architecture. If your POS includes loyalty in a plan you already pay for and you run one site with no plans to change, use it. If you run multiple POS systems, might change POS, or want the card in Apple Wallet and Google Wallet, use a POS-agnostic platform. Compare within the category that matches your situation rather than across categories.
Should I use my POS vendor's built-in loyalty?
If you run one location, have no plans to change POS, and loyalty is already included in your plan — yes. It has the smoothest staff workflow and reporting joined to sales. The cost is deferred rather than avoided: on the day you change POS, the program and its balances generally do not come with you. Price that in on day one.
Is POS-native or POS-agnostic loyalty better?
Neither is universally better. Native is smoother to operate and more expensive to leave. Agnostic requires slightly more coordination and is dramatically cheaper to change. The deciding question is whether you might run a different POS in the next few years — and whether you would accept losing your customer balances if you did.
How do I know if a vendor really integrates with my POS?
Ask for the specific integration method, not a logo on a page. Get answers to four questions: is it an API, a webhook, a file import, or a scan? What is the latency in minutes? Who built and maintains it? And does it require approval from my POS vendor? A vendor who cannot answer these is describing a marketing claim, not an integration.
Can I run loyalty across multiple locations?
Yes, and this is where POS-agnostic architecture is most valuable. A central customer database means one balance per customer regardless of which site they visit, with per-site reporting on top. If your locations use different POS systems, a POS-independent loyalty layer is the only way to achieve this.
Cost
How much does POS loyalty software cost?
It varies enormously by model. Published, self-serve prices in the independent wallet and loyalty market run from free tiers to roughly $25–$200 per month. POS vendors are less consistent: Square lists loyalty as a feature within paid plans in the US and publishes visit-banded loyalty pricing in some other markets, while Toast, Lightspeed and Clover publish no standalone loyalty price. Enterprise loyalty platforms publish nothing and quote on request. Verify current pricing directly with each vendor.
How is POS loyalty usually priced?
Five common meters: a flat monthly subscription; per location; per member or contact; per loyalty event such as an enrolment, earn or redemption; and usage or message volume. Enterprise deals are quoted. The meter that matters is the one that grows fastest as your program succeeds — model it at three times your current size before you sign.
What is the total cost of ownership of a POS loyalty program?
Software plus integration plus implementation plus staff training plus maintenance plus migration plus the actual margin cost of rewards redeemed. In many small programs the reward cost is the largest single line, which is why comparing software subscription prices alone can be misleading. Training is the line most often set to zero and most often wrong, particularly in businesses with high staff turnover.
Are there hidden costs in POS loyalty?
Three recur. First, staff time at the counter, multiplied by every transaction, forever. Second, integration maintenance when either system updates. Third, the cost of leaving — extracting your customer list and balances, and re-enrolling customers if their saved card cannot be carried over. None of these appear on a pricing page.
Is free loyalty software worth using?
For a small single-site business, often yes — a free tier is a legitimate way to prove the concept before committing. Check two things before you rely on it: the member ceiling at which you would have to upgrade, and whether you can export your customer data from the free tier. A free plan you cannot leave is not free.
ROI
How do I measure loyalty ROI?
Estimate incremental contribution: incremental visits multiplied by contribution per visit, plus any lift in spend per visit, plus retention and reactivation value, minus reward cost at marginal cost, software cost and implementation cost. It only works if you record a baseline — average visits, average ticket, and repeat-revenue share — before you launch.
What KPIs should I track for a POS loyalty program?
Pick one primary KPI and a few supporting ones. Primary candidates: visits per member per month, repeat rate within a defined window, or member share of total revenue. Supporting: enrolment rate as a percentage of transactions, active member percentage, redemption rate, and pass retention. More than four metrics and nobody reviews any of them.
Why do before-and-after loyalty comparisons overstate results?
Because of self-selection. The customers who join a loyalty program tend to be the ones who were already visiting most often, so some of the apparent lift would have happened anyway. The rigorous fix is to compare enrolled members against a matched group of non-enrolled customers over the same period, rather than comparing members against their own past.
How long before a POS loyalty program shows results?
Long enough for a typical customer to complete two or three visit cycles. For a café that is weeks; for a salon visited every six weeks it is several months. Judging a program before one full reward cycle has completed tells you about enrolment, not about retention.
Data
What customer data should I collect?
The minimum your reward rule needs. A pseudonymous member identifier is often enough for a stamp card. Add a first name for personalisation, day and month of birth if you run a birthday reward, and one contact channel with recorded consent. Itemised purchase histories carry real privacy weight and should only be collected with a clear purpose.
How do I prevent loyalty fraud?
Four controls cover most of it: an earning cap such as one stamp per customer per day; redemption verification so a reward can only be used once; staff permissions with an audit trail on manual balance edits; and monitoring for anomalies such as a single member earning at implausible frequency. Real-time balance updates also close the window that batch processing leaves open.
Can I export my customer data?
You should verify this before you enrol a single customer. Ask whether export is self-service or a support request, whether it is in an open format such as CSV or JSON, and specifically whether loyalty balances are included or only customer records. Export capability varies sharply by vendor — Toast, for example, publishes a documented self-serve loyalty export, while some platforms publish no loyalty export path at all.
What happens to my data if I leave the vendor?
Ask this in writing before signing. The answers you want: you can export everything yourself at any time; the export includes identifiers and balances; and there is a defined retention and deletion period after termination. Vagueness here is informative — it usually indicates where the vendor's retention strategy actually lives.
Migration
What happens if my business changes POS later?
If your loyalty program is POS-native, it generally ends with the POS — balances and enrolments do not transfer to a competitor's system. If it is POS-agnostic, a POS change is a reconnection: the customer identifiers, balances and saved wallet cards are unaffected, and only the integration (if you have one) is re-pointed.
How do I migrate from paper or plastic loyalty cards?
Honour existing progress — if someone has six stamps on a paper card, give them six on the digital one. Convert customers in person at the counter while their card is in their hand, and add a small transition bonus. People carrying a half-full punch card have already demonstrated the behaviour you want; they are your best starting cohort, not an afterthought.
How long does it take to launch a POS loyalty program?
With no integration — a wallet pass identified by barcode — a functional program can be live in a day, and a well-tested one in about four weeks including baseline measurement, staff training and a soft launch. With a POS integration that requires vendor approval, add the vendor's partner and certification timeline, which can run to months.
Do I have to re-enrol customers if I change loyalty platforms?
Sometimes. Balances and customer records can be exported and imported, but the saved wallet pass usually points at the platform that issued it. Ask each vendor directly whether an existing pass can be re-pointed to a new backend or whether customers must save a new one — this single answer is often the largest hidden cost of switching.
PushNotice
Does PushNotice integrate with my POS?
We do not currently publish a native integration with any named POS system, and we are not going to imply one. What PushNotice provides is a wallet pass carrying a scannable barcode or QR code, which can be read by whatever scanner is already at your counter regardless of which POS you run. If you need automatic earning driven directly by POS transactions, ask us about your specific setup rather than assuming.
26. Methodology, EEAT & disclosure
This guide is published by PushNotice, a company that sells a product in the category it describes. Verified vendor facts come from primary documentation and public pricing pages, dated at the point we checked them. Architecture guidance is general and applies regardless of what you buy. Examples are labelled as hypothetical. Nothing in this guide is a customer case study, and no statistic here is invented.
Disclosure
PushNotice publishes this article and PushNotice sells a wallet marketing platform that can act as the wallet and customer-engagement layer of a POS loyalty program. That is a commercial interest and it should shape how you read us. Three things we have done to keep the guide useful anyway: we state plainly where POS-native loyalty is the better answer; we disclose our bias in the benchmark and score the criteria where our category is weakest honestly; and we state explicitly that we publish no native POS integrations rather than implying otherwise.
Source policy
Where a technical claim is made about Apple Wallet or Google Wallet, it comes from Apple's or Google's own developer documentation. Where a claim is made about a POS vendor's pricing, API, or export capability, it comes from that vendor's own pricing page, developer documentation or support article. We have not cited third-party SEO articles or affiliate roundups for any factual claim where a primary source exists.
Fact-checking approach
Every vendor-specific claim in this guide was checked against a primary source in August 2026 and is dated in the text. Where a vendor's page could not be retrieved reliably, or where a figure is published in some markets and not others, we say so rather than filling the gap with an estimate. Specifically: no Clover pricing figure is quoted here because Clover's pricing pages did not render to automated retrieval; Square's US loyalty tiering is described from its published plan pages, with the note that Square's site is client-rendered and worth confirming in a browser; and no vendor's loyalty price is quoted where the vendor does not publish one.
What is deliberately absent
There are no invented statistics in this guide. No industry-average uplift percentages, no "loyalty members spend X% more" claims, no customer counts and no case studies. Every number that appears is either a cited vendor figure, a documented platform limit, or a plainly labelled hypothetical used to demonstrate a calculation method. Where we could have quoted an impressive-sounding statistic without a source, we left the space empty instead.
Editorial review
This guide was reviewed by the PushNotice Editorial Team for accuracy, for fair treatment of competing architectures, and specifically to confirm that no capability is claimed for PushNotice that is not published on pushnotice.io. Bracketed placeholder markers in the text indicate items to confirm against live product data before publication.
Update policy
This page is reviewed at least quarterly and whenever a cited vendor changes its pricing, API or export behaviour materially, or when Apple or Google change wallet loyalty capabilities. The canonical URL always holds the current version. Corrections are welcome via the PushNotice contact page and are made in the text rather than silently.
27. About the author
Sajid Ali is the Founder and CEO of PushNotice, where he leads the company's category strategy and brand voice around wallet marketing. His focus areas are wallet marketing, customer retention, digital loyalty and brand strategy. Author profile: pushnotice.io/blog/authors. LinkedIn: linkedin.com/in/sajid-ali-wajid.
Reviewed by the PushNotice Editorial Team, which checks platform claims against primary documentation, verifies that competing approaches are represented fairly, and confirms that recommendations follow buyer fit rather than commercial preference.
Cite this guide
- APA: Ali, S. (2026). POS Loyalty Program: Add Loyalty Without Switching POS. PushNotice. https://pushnotice.io/blog/pos-loyalty-program
- MLA: Ali, Sajid. "POS Loyalty Program: Add Loyalty Without Switching POS." PushNotice, 14 Aug. 2026, pushnotice.io/blog/pos-loyalty-program.
Related guides
28. Sources
All sources below are primary — platform or vendor documentation and published pricing pages. Retrieved August 2026. Vendor pricing and API terms change without notice; verify at the source before relying on any figure.
Apple — Wallet and PassKit
- Apple Developer — Pass (pass styles including
storeCard; locations and beacons limits; relevance). developer.apple.com/documentation/walletpasses/pass - Apple Developer — Adding a web service to update passes (registration, push with empty payload, production-only push). developer.apple.com/documentation/walletpasses/adding-a-web-service-to-update-passes
- Apple Developer — PassFieldContent (
changeMessagerequirement for change notifications). developer.apple.com/documentation/walletpasses/passfieldcontent - Apple Developer — Pass barcodes (QR, PDF417, Aztec, Code 128). developer.apple.com/documentation/walletpasses/pass/barcodes
- Apple Developer — Loyalty passes (NFC certificate, VAS-certified readers, POS software requirements). developer.apple.com/wallet/loyalty-passes
- Apple Developer — What's new in Wallet. developer.apple.com/wallet/whats-new
Google — Wallet Loyalty API
- Google for Developers — How classes and objects work (loyalty class and object; class changes propagate to all objects). developers.google.com/wallet/retail/loyalty-cards/overview/how-classes-objects-work
- Google for Developers — LoyaltyObject reference (
loyaltyPoints,secondaryLoyaltyPoints,accountId, locations note). developers.google.com/wallet/reference/rest/v1/loyaltyobject - Google for Developers — Trigger push notifications (
TEXT_AND_NOTIFY; maximum of 3 push-triggering messages per 24 hours). developers.google.com/wallet/retail/loyalty-cards/use-cases/trigger-push-notifications - Google for Developers — NotificationSettingsForUpdates (allow-listed fields for update notifications). developers.google.com/wallet/reference/rest/v1/NotificationSettingsForUpdates
- Google for Developers — Smart Tap overview and collector identifiers (certification, 8-digit collector ID, key exchange). developers.google.com/wallet/smart-tap
- Google for Developers — Save to Google Wallet on the web (signed JWT save link; 1,800-character safe length). developers.google.com/wallet/retail/loyalty-cards/web
POS vendors — pricing, APIs and data export
- Square — Pricing (US plan tiers and loyalty inclusion). squareup.com/us/en/pricing · Loyalty squareup.com/us/en/software/loyalty · Loyalty (Canada) squareup.com/ca/en/loyalty
- Square Developer — Loyalty API overview (permissions, subscription requirement, program configured in Dashboard). developer.squareup.com/docs/loyalty-api/overview
- Toast — Pricing (loyalty as an add-on, no published figure). pos.toasttab.com/pricing
- Toast Developer Guide — API overview and integration development process (partner approval, certification review). doc.toasttab.com/doc/devguide/apiOverview.html
- Toast Support — Export Toast Loyalty data for third-party use. support.toasttab.com — Export Toast Loyalty Data
- Clover Developer Docs — API reference overview and webhooks (no loyalty or rewards resource documented). docs.clover.com/dev/reference/api-reference-overview
- Lightspeed — Retail pricing lightspeedhq.com/pos/retail/pricing · O-Series Loyalty and Payments API (account-manager-gated access) o-series-support.lightspeedhq.com
- Shopify — POS features (no native loyalty listed) shopify.com/pos/features · Import and export customers help.shopify.com — export customers
Third-party loyalty platforms — published pricing
- Loopy Loyalty — Pricing. loopyloyalty.com/pricing
- PassKit — Pricing. passkit.com/pricing
- Stamp Me — Pricing. stampme.com/pricing
- PushNotice — Plans. pushnotice.io/#pricing
Privacy
- UK Information Commissioner's Office / EU GDPR — Article 5(1)(c), the data-minimisation principle. ico.org.uk — the data protection principles
All vendor pricing, API terms and export capabilities described in this guide reflect the state of each vendor's public documentation in August 2026 and may have changed. Verify at the source before relying on any specific figure. Nothing in this guide is legal, tax or financial advice.