Free resource · use it on this page
POS Loyalty Architecture Diagram
The five-layer POS Loyalty Layer Model and the POS-agnostic earn and redemption flows, expressed as reference tables you can map your own stack onto.
How to read this diagram
The POS Loyalty Layer Model describes any POS-plus-loyalty stack as five layers stacked from the till upward: the POS layer, the integration layer, the loyalty engine, the wallet layer, and the customer touchpoints. The core claim of the model is that loyalty does not live inside the POS. The POS records sales; everything above it can be added, swapped, or removed without touching the till.
Each layer talks only to the layers directly above and below it. That separation is what lets you add a loyalty program to a POS you already own: the integration layer adapts to whatever the POS can emit, and nothing higher up needs to know which POS is underneath. It is also what protects you later, because a vendor at one layer can be replaced without rebuilding the others, provided the customer records and balances are exportable.
Read the layer table top to bottom to see where each responsibility sits, walk the two data flows to see how a single sale becomes a lock-screen update and how a reward comes back down to the till, then use the worksheet at the end to redraw the diagram with your own vendors in each box.
The POS Loyalty Layer Model
Five layers, from the till upward. The right-hand column names the one decision you actually own at each layer; everything else is implementation detail.
| Layer | What it does | Typical occupants | The decision you own |
|---|---|---|---|
| 1. POS layer | Records the sale: basket total, line items, tender type, timestamp, till or location ID. The system of record for transactions, and only transactions. | Cloud POS, legacy countertop terminal, ecommerce checkout, self-serve kiosk, or a mix across locations. | Keep it. The entire model exists so this layer is never replaced for the sake of loyalty. Your only job here is to find out what it can emit: app marketplace, public API, webhooks, e-receipts, or nothing. |
| 2. Integration layer | Moves transaction data up and out of the POS, and carries redemption commands back down. The adapter between whatever your POS speaks and whatever your loyalty engine expects. | Native POS marketplace plugin, webhook or API bridge, middleware connector, card-linked feed from the payment processor, e-receipt parser, or a manual side-by-side flow. | Which pattern to use (see the matrix below). This is a freshness-versus-effort trade: how fast must a sale reach the engine, and how much building or vendor cost will you accept to get there. |
| 3. Loyalty engine | Owns customer identity, the earning rules, and the balances. Resolves who the customer is, applies points or stamps or tiers, and stores the result. The system of record for customers. | A loyalty SaaS, the loyalty module built into the POS itself, or a custom service sitting on your CRM or database. | Where the customer record lives and whether you can leave with it. Before signing anything, confirm you can export customers with their current balances in an open format. |
| 4. Wallet layer | Turns a balance into something the customer carries: a pass in Apple Wallet or Google Wallet that updates when the balance changes and can surface messages on the lock screen. | A wallet-marketing platform, or the loyalty engine's own built-in pass feature if it has one. | Static or personalized. A static coupon-style pass is cheap but never changes; a personalized pass shows this customer's balance and updates after every visit. Decide which experience you are actually promising. |
| 5. Customer touchpoints | Every moment the customer sees or uses the program: enrollment, the earn confirmation, the reward reminder, the redemption itself. | Lock-screen pass updates, the pass face itself, a QR code at the till, in-store signage, email or SMS as fallback channels. | Which moments you design deliberately. Most programs need only three done well: a frictionless enrollment, an earn confirmation that lands before the customer leaves, and a reward reminder that brings them back. |
Data flow A: the earn loop, from sale to lock screen
The upward flow. One transaction climbs all five layers. The whole loop should complete before the customer reaches the door; anywhere it stalls, find the layer and you have found the bottleneck.
- 1
The sale closes at the POS
The POS layer records basket total, line items, tender type, timestamp, and location. Nothing loyalty-specific happens here, which is the point: the till behaves exactly as it did before the program existed.
- 2
Identity attaches to the transaction
A phone number given at the till, a pass barcode scanned, a card-link token matched, or a staff lookup. No identity means no loyalty for that visit. This is the weakest joint in every stack, so decide the mechanism before choosing any vendor.
- 3
The integration layer forwards the transaction
A webhook fires, a plugin pushes the event, a connector polls on an interval, or a processor feed delivers it later. Note the real freshness of your chosen pattern here; it caps how fast every later step can be.
- 4
The loyalty engine resolves the customer
The identity key is matched to one customer record, or a new record is created. Enforce one evolving record per person: merging phone, email, and pass identifiers into a single customer, never spawning duplicates per channel.
- 5
The earning rules run
Points per amount spent, a stamp per qualifying visit, or tier progress. Write down the edge cases before launch: refunds, split tenders, discounted items, and whether a second visit within minutes counts as one visit or two.
- 6
The balance writes and the wallet layer is notified
The engine commits the new balance and calls the wallet layer through an API or event. If these two systems are separate vendors, this handoff is a real integration; budget for it explicitly.
- 7
The pass updates on the phone
The wallet platform pushes the change: the pass face shows the new balance, optionally with a lock-screen notification. If this lands while the customer is still holding their coffee, the program feels alive; if it lands tomorrow, it feels like paperwork.
Data flow B: the redemption loop, from reward to till
The downward flow. Redemption is where architectures fail in public, at a busy counter, so every step needs a single unambiguous authority.
- 1
The engine flags a reward as earned
A balance crosses the threshold. The wallet layer flips the pass into its reward state so the customer can see, without opening any app, that something is waiting.
- 2
The customer presents the pass at the till
The barcode or QR on the pass is the redemption credential. It must be scannable in poor light on a cracked screen in under two seconds, which argues for a code, not a tap-through app flow.
- 3
The redemption is validated
Either the POS scan hits the engine's API, or staff visually confirm the pass state. Pick exactly one validation authority. Two parallel authorities is how the same reward gets honored twice.
- 4
The discount applies at the POS
As a line-item discount, a promo code, or a manual price override, depending on what the POS supports. Decide this per POS during vendor selection; it is the most commonly forgotten requirement in demos.
- 5
The engine marks the reward redeemed
The decrement must be atomic with validation: validated and marked in one operation, so a network hiccup or a fast second scan cannot redeem the same reward twice.
- 6
The pass re-renders and the loop closes
The pass returns to its base state showing the reset balance, ideally with a confirmation moment. The customer leaves having watched the full cycle work, which is the strongest enrollment ad the program will ever run.
Integration layer patterns: the matrix
Six ways to build layer 2, ordered roughly from freshest to most manual. Freshness figures are the mechanical property of each pattern, not vendor benchmarks; verify against your own POS.
| Pattern | How the sale reaches the engine | Typical freshness | Watch out for |
|---|---|---|---|
| Native POS plugin | Installed from the POS vendor's app marketplace; the POS pushes transaction events directly to the loyalty engine. | Seconds. | Only exists where the POS has a marketplace and the engine has built for it. You inherit the plugin's data model and its update schedule. |
| Webhook or API bridge | The POS cloud back office fires webhooks on each completed sale, or the engine pulls via the POS API. | Seconds to minutes. | Webhooks drop silently. You need retries plus a daily reconciliation job that compares POS transaction counts to engine transaction counts. |
| Middleware connector | A middleware or automation platform polls the POS, transforms the payload, and posts to the engine. | Minutes, set by the polling interval. | Per-task pricing scales with transaction volume, and you have added a third vendor to the chain whose outages become your outages. |
| Card-linked feed | The customer enrolls a payment card; the processor's transaction feed is matched to that token. | Minutes to hours, feed-dependent. | Cash and unenrolled cards are invisible, so earn coverage is partial by design. Basket detail is usually absent: amounts, not items. |
| E-receipt parsing | The engine reads the POS-generated digital receipt, either forwarded by the customer or via an email integration. | Minutes to hours. | Parsing breaks whenever the receipt template changes, and any flow that asks the customer to forward something loses most of them. |
| Side-by-side, no integration | Staff scan the customer's pass QR or enter a phone number into a separate loyalty screen next to the till. | Immediate, but entirely manual. | Lives or dies on staff compliance during the rush. Captures visits, not baskets, so amount-based rules are off the table. Honest and cheap; know what you are giving up. |
Worksheet: redraw the diagram for your stack
Fill in one line per box. When every field has a concrete answer, you have your own version of the diagram and a vendor-selection brief in the same page. Print it and put it in front of every demo.
Your POS layer
Name the POS and version at each location, and record which it offers: app marketplace, public API, webhooks, e-receipts, or none.
Your integration pattern
Pick one row from the matrix above and write the freshness you expect in minutes. If different locations need different patterns, say so now, not after signing.
Your loyalty engine
Name it and state where the customer record lives. Confirm in writing that customers plus balances export in an open format like CSV.
Your wallet layer
Static coupon pass or personalized live-updating pass. Note who controls the pass design and branding, and whether Apple and Google are both covered.
Your three touchpoints
Choose the three moments you will design first: usually enrollment, earn confirmation, and reward reminder. Everything else waits.
Your identity key
Phone, email, pass serial, or card token. Pick one primary key, define how the others merge into it, and never let two channels create two customers.
Your earn-to-phone latency target
Write a number in seconds or minutes. The honest test: does the pass update before the customer is out the door? Measure it during the pilot, not after launch.
Your failure owner
Name the person who notices when the integration stops flowing, and the reconciliation cadence, for example a daily compare of POS sales count versus engine transaction count.
Reusing this model
The POS Loyalty Layer Model and both data flows are free to reproduce in client decks, courses, internal documentation, and published analysis. Attribute it as the POS Loyalty Layer Model by PushNotice, and link to this page where the format allows. No permission request is needed for attributed use.
If you adapt the model, say so: label your version as adapted, keep the five layer names intact so readers can trace it back, and change the parts your context genuinely requires. A model only stays citable if every copy in the wild still means the same thing.
From the guide: POS Loyalty Program: Add Loyalty Without Switching POS
This resource accompanies the full article — worth reading before you commit to a tool.