How do you implement a loyalty app in a retail chain, from programme rules to POS and CRM integration?

Sources checked on 11 November 2026.

This guide is for the person in a chain of physical stores (with or without ecommerce) who is responsible for the loyalty programme, sales or IT and has to prepare a loyalty app implementation. It describes the decisions to make before choosing a vendor and the order of work.

The short version: the app is only one of the layers. Underneath it you need a programme system that receives receipts from the tills, grants and deducts points according to written rules, handles returns and passes the customer profile to the CRM. The till integration and the exception rules cannot be assessed without checking the specific systems, so it is worth starting with a pilot in one store.

Each mechanic needs different data from the systems. Before the first screen is designed, write down which mechanics you launch first and what information each of them needs.

The rules also include details that finance will ask about later: when points become available (immediately or after the return period), when they expire, who funds a reward in a franchise store and how to round points on discounted items.

Identification at the till decides whether the programme works in a physical store. You have several options, and they can be combined:

• A QR code or barcode in the app, scanned by the till scanner.
• A phone number typed by the cashier or by the customer on a terminal.
• A card in the phone's wallet (Apple Wallet, Google Wallet) carrying the customer code.
• A plastic card for customers who will not install the app.

A card in the phone's wallet does not require opening the app. Apple describes store cards and coupons as pass types in the Wallet Passes documentation; the pass content can be updated through your own server.

On Android, Google Wallet supports loyalty cards through the Google Wallet API (REST API and Android SDK). A card can be issued from an app, a website, an email or a text message.

Before you choose, check in one store whether the till scanners read codes from a phone screen and in which field the POS stores the customer identifier.

The programme system learns about a purchase from the receipt. When and in what form the receipt reaches it depends on the till software, and a chain with franchise stores may run several different POS systems.

Ask the POS vendor and the IT team these questions before the integration is estimated:

1. Exchange mode: does the till send the receipt immediately or in batches after the day closes?
2. Offline operation: what does the till do without a connection, and how does it fill in the data later?
3. Data scope: does the receipt include lines, categories, discounts and the store, or only the total?
4. Coupons at the till: can the POS check a coupon online and mark it as used?
5. Returns and corrections: how is a return linked to the original receipt and the customer identifier?
6. Several systems: do all stores, including franchise stores, use the same POS?

Decide which system is the source of truth for the customer profile: the programme system, the CRM or the online store. The other systems should take the profile from one place; otherwise the same customer will appear in several versions with different consents.

Design acceptance of the programme terms and marketing consents as separate fields in the app and separate records in the data. Record when and in which channel the customer gave or withdrew each consent; agree the wording of consents and the legal bases for processing with your data protection officer or a lawyer.

On iOS the app needs permission to send notifications. In its guide on asking permission to use notifications, Apple recommends asking in a context that explains their purpose rather than automatically on first launch. The same guide describes provisional authorization: quiet notifications then appear only in the Notification Center history, and the user decides whether to keep them.

On Android 13 (API level 33) and higher, posting notifications (except exempt categories) requires the POST_NOTIFICATIONS permission granted by the user. The Android notification runtime permission guide explains what the app can do after each user choice.

A customer balance should not be a single number overwritten on every purchase. It is safer to record each operation separately, with its source and reason, and to calculate the balance from the history. Then every complaint can be explained and a wrong operation can be reversed with an opposite one. A hypothetical example, not a client project:

Such a ledger also shows finance the value of unused points, that is the liability towards customers. Accounting decides how to recognise it, but the data must come from the programme system.

The order below moves the till integration to the start of the project, because its scope cannot be assessed without checking the specific POS. Each stage ends with a result that can be checked before moving on.

1. Rules and data: written mechanics, exceptions, the source of truth for the profile and the list of systems to integrate.
2. POS integration trial in one store: a receipt, a return and a coupon travel from the till to the programme system.
3. App MVP: sign-up, customer code, balance and history, coupons, consents, notifications.
4. Pilot in one or a few stores, with cashier training and a channel for reporting problems.
5. Roll-out to the chain store by store, checking the data from each POS.
6. Maintenance: iOS and Android updates, new campaigns, integration monitoring and handling of points complaints.

The implementation cost follows from the scope, not from the number of screens. The estimate depends on the factors below:

• The number and type of POS systems, and whether they have a ready API.
• The number of mechanics at launch and the complexity of their exceptions.
• Identification channels: app, phone wallet cards, plastic cards.
• Additional integrations: CRM, online store, ERP, messaging tool.
• Operations panel for marketing and customer service: campaigns, points corrections, complaints.
• Maintenance after launch: updates, monitoring and new campaign development.

If you are still checking whether the programme makes economic sense, start with the guide on loyalty apps and repeat purchases, and come back to this article when planning the implementation.

These materials let the scope be assessed without guessing. You do not need all of them; a missing answer is also useful information.

1. The list of POS systems in the chain, with the vendor name and whether an API is available.
2. A description of the launch mechanics: points, tiers, coupons, with return and expiry rules.
3. A sample till receipt (without personal data), with the fields it contains.
4. Where customer data and consents are stored today: CRM, online store, spreadsheets.
5. The number of stores and the pilot plan: which store and who on your side owns it.