In brief
Paper cards cost per unit and cannot be corrected. Browser cards cost nothing and can. Wallet passes do both and also reach the lock screen. The choice is mostly about what happens when you change the offer.
The short answer
There are three ways to make a loyalty card and they are not variations on a theme. A paper card is printed, costs money per unit and lives in a wallet. A browser card is a link, costs nothing and lives at a URL the customer bookmarks. A wallet pass is an Apple or Google Wallet object that sits beside the boarding passes.
Pick on one question: what happens the day you change the offer? Paper says “honour both versions for a year”. The other two say “it changed on everyone’s phone at once”.
Making a paper loyalty card
Still the most common answer to how to make loyalty cards, and for a shop with fifty regulars and no interest in software it is a defensible one.
What you need: a business-card-sized design with ten or twelve boxes, your name, the offer in one sentence, and an expiry policy. A rubber stamp with a shape nobody else has. A box behind the counter.
What it costs: a per-unit print price times the number you hand out, and you will hand out more than you think because people lose them. Plus a reprint every time anything changes.
Where it breaks:
- You cannot count what is outstanding. Every card handed out is an unknown liability. You will never know how many people are on stamp nine.
- The stamp is the only security. Anyone with a similar stamp, or a friend on shift, can fill a card. This is the entire reason paper programs get quietly cancelled.
- A change means two programs. Move from ten stamps to twelve and you are running both for a year, arguing about it at the counter.
- It is invisible between visits. A card in a drawer at home is a card that never brings anyone back.
Paper is cheap up front and expensive to be uncertain about. If you are testing an offer on ten regulars for two weeks, print paper — that is exactly the right use of it, and it is step three of building a program. If you are running it for a year, do not.
Making a browser-based card
The card is a page. The customer scans a QR code on the counter, gives the minimum you need to identify them again, and gets a link. No app store, no download, no install prompt.
What you need: a QR poster and something to hold the ledger.
What it costs: the poster, printed once, and whatever the software costs. Nothing per customer.
Where it breaks:
- The link has to survive. A customer who clears their browser or changes phone needs a way back in. Ask how they re-find their card before you commit to a tool.
- It is not on the lock screen. A bookmark is easy to forget in a way a wallet pass is not.
The advantage that outweighs both: enrolment has no cliff. The gap between “willing to join” and “joined” is where most loyalty programs lose their customers, and an app download in that gap loses most of them. A scan and one field does not.
Making a wallet pass
An Apple Wallet or Google Wallet pass. Same enrolment as the browser card, but the card ends up in the wallet app the customer already uses.
What you need: the same QR poster, plus software that can issue and update passes. Apple and Google do not charge merchants for this.
What it costs: nothing per pass.
Where it breaks:
- It has to update. A pass showing a stale balance is worse than no pass. Updating a pass after each scan is the part vendors differ on — ask specifically.
- Two platforms. Apple and Google are separate systems with separate requirements. From the counter it should look like one thing.
What it buys: the balance is on the phone the customer already unlocks forty times a day, and it can carry a location trigger. That is the closest a small business gets to being remembered without sending anything.
The comparison, in one table
| Paper | Browser | Wallet pass | |
|---|---|---|---|
| Cost per customer | Per unit | £0 | £0 |
| Enrolment friction | Lowest | Low | Low |
| Business can see balances | No | Yes | Yes |
| Customer sees balance between visits | Only if they look | If they bookmark | On the phone |
| Change the offer | Reprint, honour both | Instant | Instant |
| Fraud resistance | Weak | Depends on validation | Depends on validation |
| Works with no signal | Yes | No | Pass shows; scan needs signal |
The part that matters more than the card
Whichever you make, the card is only half the artifact. The other half is who is allowed to add to it.
A card the customer can increment themselves is not a loyalty card, it is a form. If scanning your own code adds a stamp, the program is worth exactly what an honour system is worth. The stamp has to be applied by someone on your side of the counter — that is what staff validation means, and it is the single feature that separates a rewards card program from a spreadsheet with a logo.
The second half is the qualifying rule the card enforces: one stamp per customer per day, or per transaction, or per amount. Decide it before you print anything, because it is the sentence that has to fit on the card.
If you are starting a rewards card program from scratch
Sequence that avoids the expensive mistakes:
- Print twenty paper cards and run the offer for two weeks. You are testing the offer, not the medium.
- Fix the threshold and the qualifying rule based on what happened.
- Then choose the digital form, because now the rule it has to enforce is settled.
- Put one poster on the counter and have staff say one sentence.
The order matters because step one is the only cheap way to be wrong. Everything after it is permanent in a way paper is not — which is, oddly, the strongest argument for using paper first and never again.