---
title: "Loyalty Points App: Wallet, QR and Point Grants | FLUIDS"
description: "How to build a loyalty points app: a points wallet and ledger, QR customer identification, receipt-linked grants, and why points must stay loyalty, not money."
url: https://fluids.digital/blog/loyalty-points-app
language: en
---
[Home](https://fluids.digital/) [Blog](https://fluids.digital/blog) Loyalty points apps

[Offers, coupons & loyalty](https://fluids.digital/blog#offers-loyalty)

# Building a loyalty points app: wallet, QR identification and merchant point grants

[FLUIDS Digital](https://fluids.digital/about) Published 1 November 2026 7 min read

The short answer

A loyalty points app gives each customer a wallet whose balance is calculated from a ledger of point transactions. At the counter, staff identify the customer by scanning a QR code from the app, record points against a specific receipt, and later accept points when the customer spends them. Design points as a reward that cannot be bought, cashed out or transferred like money: payment and stored-value services in Saudi Arabia are regulated by the Saudi Central Bank (SAMA), so confirm your design with qualified counsel.

## Key takeaways

- Store every point movement as a ledger entry and derive the balance from it; never edit a balance directly.
- A QR token in the customer's app lets staff find the right wallet without asking for a phone number at the counter.
- Linking each point grant to a receipt makes grants traceable and lets the system reject the same receipt twice.
- Separate the permission to grant points from the permission to redeem them, so one staff member cannot do both unchecked.
- Unredeemed points are commonly recorded as a liability in the merchant's accounts, and stored-value services in Saudi Arabia are regulated by SAMA; keep points as loyalty, not money, and confirm both with your accountant and counsel.

## How a loyalty points app works

A loyalty points app works like a small ledger. Every time a customer earns or spends points, the system writes a transaction with the amount, the reason, the merchant, the branch and the person who recorded it. The balance the customer sees is the sum of those transactions, not a number someone typed in.

That design choice sounds technical, but it decides whether the programme can be trusted. If a balance is stored as a single editable field, a wrong grant or a disputed redemption leaves no trace. With a ledger, every point can be explained: where it came from, when, and who approved it. Corrections are new entries, not silent edits.

Around the ledger, a loyalty app needs three experiences:

- **The customer wallet:** the current balance and a readable transaction history, so the customer can check what they earned at each visit.
- **The counter workflow:** identify the customer, record points against a purchase, or accept points the customer wants to spend.
- **The merchant's records:** statements and transaction views that let the owner review what staff did across branches.

T-CODE, the offers and loyalty app FLUIDS built, follows this structure: a loyalty wallet with a points balance and transaction history on the customer side, and point statements and transaction views on the merchant side.

## Identifying the customer at the counter with a QR code

A quick and reliable way to find a customer's wallet at the counter is a QR code shown in the customer's app and scanned by staff. Asking for a phone number works, but it is slower, invites typing mistakes and exposes personal data to anyone standing nearby.

A typical counter flow looks like this:

1. **The customer opens their loyalty card** in the app, which displays a QR code.
2. **Staff scan it** from the merchant app on a phone or tablet at that branch.
3. **The server resolves the token** to the customer's wallet and returns only what staff need: a name or initials and the current balance.
4. **Staff record the action:** a point grant with the receipt details, or a redemption.
5. **Both sides see the result:** the customer's history updates, and the transaction appears in the merchant's records.

In T-CODE, the customer has a card that can be identified by a QR token, and the merchant can look up the customer before recording points. As a general design rule, the QR code should carry a token rather than the customer's phone number or account ID. A token that can be rotated or expired means a screenshot shared on social media does not become a permanent key to someone's wallet.

Decide what staff are allowed to see after a scan. A balance and a first name are usually enough; full contact details rarely belong on the counter screen.

## Granting points against a receipt

Points should be granted against a specific purchase, identified by its receipt. A grant without a receipt is just a number someone chose; a grant linked to a receipt number and purchase details can be checked later against the till and the merchant's own sales records.

In T-CODE, the merchant records points against a purchase with receipt information, and the merchant side distinguishes the permission to grant points from the permission to redeem them. Staff can be assigned to a branch and given counter access without receiving the owner's full management role.

Whatever product you build, a points ledger usually needs these transaction types, each with its own rules:

| Transaction | What it records | Key safeguard |
| --- | --- | --- |
| Grant (earn) | Points added for a purchase | Linked to a receipt; the same receipt cannot earn twice |
| Redemption (spend) | Points used for a reward or order | Balance checked on the server at the moment of spending |
| Adjustment | A correction by an authorised person | Requires a reason and is never a silent edit |
| Reversal | Undoing a grant after a refund or error | Points back to the exact original transaction |
| Expiry (if used) | Points removed under a published rule | Rule shown to the customer before it applies |

The table is a design checklist, not a list of T-CODE features. Which types you need depends on your refund policy and whether points expire. What matters is that every type writes to the same ledger, carries the staff member and branch, and appears in the merchant's statement.

## Spending points: from a menu to a confirmed sale

Customers need something worth spending points on, and the counter needs a clear way to accept them. One clean pattern is a point-based order: the customer builds a cart from the merchant's menu in the app, and staff confirm it at the branch.

T-CODE supports this. A merchant organises menu categories and items, including items specific to a branch. The customer prepares a point-based cart for a shop branch and receives a code and QR token for the order. At the counter, the merchant looks up the cart, reviews its lines and the points it uses, and then confirms the sale. Preparing a cart and confirming a sale are separate steps.

Keeping those steps separate protects both sides. The customer's balance is not reduced just because they built a cart they might abandon. The merchant does not hand over an item until the points are actually deducted. And a log of each confirmation answers the inevitable question, "who confirmed this order, and when?"

## Keep points as loyalty, not money

Points feel like a marketing feature, but they carry financial and regulatory weight. Two questions deserve attention before launch: how the merchant accounts for points, and whether the design starts to look like stored money.

**Accounting.** When a customer earns points with a purchase, the merchant has generally promised a future reward. Under IFRS 15, the international standard on revenue from contracts with customers, points that give the customer a material right are generally accounted for as a separate performance obligation: part of the sale price is allocated to the points and recognised as revenue later, as the points are redeemed or are expected to lapse unused. Which standards apply, and how, depends on the business, so the merchant's accountant should decide the treatment. What the software must provide is the data: points issued, redeemed, reversed and expired, by merchant, branch and period.

**Regulation.** Payment and stored-value services in Saudi Arabia are regulated by the Saudi Central Bank (SAMA). A programme where customers earn points through purchases and spend them only on rewards from the merchant is very different from a wallet that accepts cash top-ups, lets users send balances to each other or pays balances out in cash. The further a design moves towards the second, the more likely it is to raise licensing questions.

- Do not let customers buy points with money.
- Do not allow cash-out or transfer of points between customers.
- Do not describe points as a currency or a balance in riyals.
- Publish clear terms: how points are earned, what they can be used for and whether they expire.

This is general product guidance, not legal or accounting advice. Confirm the design of any points programme with qualified counsel and an accountant before launch, especially if several unrelated merchants will share one points programme.

## Decisions to make before you build

The technology of a points app is well understood. The hard part is the policy, and it should be settled in the scope document:

- **Single merchant or many.** A programme for one chain is simpler than a shared programme across unrelated merchants, where you must decide who funds a reward earned at one shop and spent at another.
- **Earning rule.** Points per purchase, per visit or per item, and whether each merchant sets its own rule.
- **What points buy.** Menu items, discounts or specific rewards, and at which branches.
- **Expiry.** Whether points expire, and how customers are told in advance.
- **Staff controls.** Who may grant, who may redeem, and whether large grants need an owner's approval.
- **Fraud review.** Reports that flag unusual patterns, such as many grants by one staff member to the same customer.

Loyalty works differently by industry. A salon may reward visits, a clinic must be careful how it rewards treatment, and a café may let customers spend points on menu items. Our guides to a [salon loyalty card](https://fluids.digital/blog/salon-loyalty-card) and a [clinic loyalty programme](https://fluids.digital/blog/clinic-loyalty-program) cover those cases, and the [multi-branch merchant guide](https://fluids.digital/blog/multi-branch-merchant-app) explains staff permissions in detail.

FLUIDS builds loyalty and offers products as [custom software](https://fluids.digital/custom-software) or as part of a [marketplace platform](https://fluids.digital/marketplace-platforms), with scope, price and timeline agreed in a written proposal. The [T-CODE case study](https://fluids.digital/projects/tcode) shows how wallet, QR identification and point orders fit together in one app.

Built by FLUIDS

## T-CODE

![T-CODE — A coupon discovery app connecting shoppers and merchants — nearby offers on a map, in one experience.](https://fluids.digital/images/projects/tcode/04.webp)

A coupon discovery app connecting shoppers and merchants — nearby offers on a map, in one experience.

[Read the T-CODE case study](https://fluids.digital/projects/tcode)

## Frequently asked questions

**Are loyalty points the same as money?**

They should not be. Points earned through purchases and spent only on rewards are a loyalty tool. If customers can buy, transfer or cash out points, the programme may start to resemble a stored-value service, which in Saudi Arabia is regulated by SAMA, so confirm the design with counsel.

**How does a merchant identify a customer in a loyalty app?**

Usually by scanning a QR code shown in the customer's app. The code carries a token that the server resolves to the customer's wallet, which is faster and more private than asking for a phone number.

**How do you stop staff from granting points to friends?**

Link every grant to a receipt, reject duplicate receipts, record which staff member and branch made each grant, separate grant and redeem permissions, and review unusual patterns in the merchant's statements.

**Do loyalty points have to expire?**

Not necessarily; it is usually a business decision. If points expire, the rule should be published before customers earn them and shown clearly in the wallet, and the merchant's accountant should know how expiry affects their records.

**Can FLUIDS build a loyalty points app for our business?**

Yes. We start with your earning and spending rules, branches and staff roles, then scope the customer wallet, counter workflow and merchant records. Scope, price and timeline are agreed in a written proposal before development.

## Further reading

- [Saudi Central Bank (SAMA)](https://www.sama.gov.sa/)
- [T-CODE case study](https://fluids.digital/projects/tcode)

In this article

How a loyalty points app works Identifying the customer at the counter with a QR code Granting points against a receipt Spending points: from a menu to a confirmed sale Keep points as loyalty, not money Decisions to make before you build Questions

Planning a similar product? We design, build and launch it, and you own the code.

[Discuss your project on WhatsApp](https://wa.me/966559508798?text=Hi%20FLUIDS%2C%20I%20read%20your%20article%20%22Loyalty%20points%20apps%22%20and%20would%20like%20to%20discuss%20a%20similar%20project.)

Related development services

## From the idea to a working product

- [Custom software development](https://fluids.digital/custom-software)
- [Marketplace platform development](https://fluids.digital/marketplace-platforms)
- [MVP scope checklist](https://fluids.digital/mvp-development/scope)

Offers, coupons & loyalty

## Keep reading

[### Multi-branch merchant roles Multi-branch merchants: staff roles, branch visibility and point permissions](https://fluids.digital/blog/multi-branch-merchant-app) [### Coupon app development How to build a coupon and local offers app](https://fluids.digital/blog/coupon-app-development) [### Salon loyalty cards Digital loyalty cards for salons: visit-based rewards that run themselves](https://fluids.digital/blog/salon-loyalty-card) [### Clinic loyalty programmes Loyalty programs for private clinics: points on visits and in-app rewards](https://fluids.digital/blog/clinic-loyalty-program)

## Turn the idea into a written scope

A short call to understand your users and workflow, then a written proposal covering scope, timeline and price before development starts.

[Start on WhatsApp](https://wa.me/966559508798?text=Hi%20FLUIDS%2C%20I%20read%20your%20article%20%22Loyalty%20points%20apps%22%20and%20would%20like%20to%20discuss%20a%20similar%20project.)