In brief
A wallet pass is a loyalty card issued into Apple Wallet or Google Wallet instead of opened in a browser. It sits beside the customer's boarding passes and tickets, works without a tab or a search, and updates itself when staff record a visit — which is the one format that can show a changed stamp count without the customer opening anything.
What a wallet pass actually is
Apple Wallet and Google Wallet are already on the phone. They hold boarding passes, event tickets, transit cards, and — if a business issues one — loyalty cards.
A wallet pass is not an app and not a screenshot. It is a small signed file the business issues to that one customer, which the wallet stores and keeps up to date. The signature is what makes the wallet trust it, and it is why a pass cannot be forged by editing a saved image.
The practical difference from a browser card is that the customer stops needing to remember where the card was. It is in the wallet, next to the plane ticket, reachable from the lock screen.
The three formats, side by side
Every digital loyalty card is one of three things, and they differ mainly in what the customer has to do before the first stamp.
| Browser card | Wallet pass | Dedicated app | |
|---|---|---|---|
| To join | One tap | One tap, then accept a prompt | Store search, download, account |
| To find it later | Link, tab, or bookmark | It is in the wallet | Home screen icon |
| Works on any phone | Yes | iPhone or Android only | Only supported versions |
| Updates when stamped | On open | By itself | By itself |
| Can reach a lock screen | No | Yes, on a changed pass | Yes, fully |
| Survives a cleared browser | No | Yes | Yes |
Read down the “to join” row before the rest of the table. It is the row that decides how many people are on the card at all, and every other advantage is worth nothing to a customer who never joined.
What the pass buys you, and what it costs
The gain is retrieval and persistence. A paper card gets lost, a browser card gets lost in a tab history, and a pass does not — it stays in a place the customer already opens for other reasons. Clearing browsing data removes a bookmark and leaves a pass alone.
The second gain is the one worth understanding properly. Because a pass is a live copy rather than a picture, the stamp count on it changes when staff record a visit, and a changed pass can appear on a lock screen. That is not a marketing channel — you cannot write a message into it — but it is the difference between a customer who forgot they were two visits away and one who is reminded by the phone in their hand.
The cost is the prompt. Adding a pass asks the customer to confirm something while a queue forms behind them, and some will decline. A browser card asks for nothing. This is a real trade, not a formality, and it is why the sensible arrangement is to offer both rather than to pick.
Apple Wallet and Google Wallet are not one thing
They look equivalent to a customer and are not equivalent to a business.
Apple Wallet takes a signed pass file. Updates are pushed to the device, and the pass on the phone keeps talking to the address that was written into it when it was issued.
Google Wallet works through Google’s API, and the pass is an object held on Google’s side that the business updates.
Two consequences matter to you as a merchant, and neither is visible in a feature list. The first is that a provider can support one wallet and not the other, so “wallet passes” on a pricing page is worth one question. The second is that both require credentials from Apple and Google that have to be maintained — a provider is signing on your behalf, and that is a dependency you inherit rather than manage.
When a wallet pass is the wrong choice
When your customers are on old phones. Wallet support is broad but not universal, and a customer whose phone cannot add the pass needs the browser card to exist.
When the prompt costs you more than the pass returns. A very fast counter with a long queue is exactly where the extra confirmation hurts most. If joining is the thing you are short of, optimize joining.
When you want to send messages. A pass updates; it does not carry a campaign. Email or SMS with consent you collected properly is the channel for that, and a pass is not a substitute.
When a pass is the only option offered. Any setup that requires a wallet excludes a share of your customers. The format should widen who can join, not narrow it.
The NeoLoyal approach
The browser card remains the default, because it is the format with the fewest steps between a poster and a joined customer. The wallet pass is offered on top of it: an add-to-wallet button appears when a customer joins, and again on the card itself, for both Apple Wallet and Google Wallet.
When authorized staff record a qualifying visit, the pass updates with the new count. Stamps are still issued and redemptions still confirmed by your team at the counter — the pass reflects the count, it never changes it.
If a customer declines the pass, or their phone cannot hold one, nothing is lost. They keep the same card in the browser, in their NeoLoyal wallet alongside cards from other businesses, and it works the same way.