Strategy

Why wallet passes beat loyalty apps

Every app you ask a customer to download is a tax on joining. The wallet is already on their phone, it never needs an update, and it never churns.

· 5 min read

Somewhere in your organization, someone has proposed building an app. The reasoning sounds solid: an app means a direct channel, push notifications, a branded home on the customer's phone. The problem is that the reasoning describes the destination and skips the journey, and the journey is where loyalty programs die.

The download is the drop-off

Before a customer sees a single screen of your app, you are asking them to find it in an app store, wait for it to install, create an account, verify an email, and grant notification permissions. Each step loses people. The customers who make it through are your most devoted, the ones who would have joined anyway. The customers you actually built the program for, the occasional visitors you want to see more often, are exactly the ones who won't finish the funnel.

A wallet pass skips the funnel entirely. Every iPhone ships with Apple Wallet. Every Android phone has Google Wallet. Joining your program is one tap on a link, whether it comes from a receipt, a poster, an email, or the checkout itself. There is nothing to install, no account to create, and nothing to remember.

This changes where you can afford to ask. An app download is a big ask, so programs save it for committed customers and dedicated campaigns. A pass is a small enough ask to put everywhere: on the receipt after every purchase, at the end of online checkout, on the poster by the door. Post-purchase enrollment, inviting the customer to join in the seconds after they pay, only works because the yes costs one tap. That is the moment app-based programs structurally cannot capture, and it is where pass-based programs win their members.

Apps decay. Passes don't.

An app is a liability the day it ships. It needs updates for every new OS release, engineering time for every new feature, and store review for every fix. When customers stop opening it (and most do), the operating system quietly offloads it.

A pass has none of that overhead. It renders in the wallet the platform maintains, so it inherits every OS update for free. When you change your logo, adjust a reward tier, or fix a typo, the pass updates in every customer's wallet within seconds. Nobody has to download anything, because there is nothing to download.

The decay shows up in budgets, too. An app is a standing engineering cost: a team, a backlog, a release cadence, two app stores to keep happy. A pass program is an integration: connect it to your CRM once, and the pass becomes a projection of data you already maintain. The member earns points, the pass moves. The tier changes, the pass follows. The ongoing cost of keeping ten thousand passes correct is the same as keeping one correct, which is the kind of economics loyalty programs are supposed to have.

The channel you were promised, without the app

The honest case for an app was never the app itself; it was the push channel. Here is the part that surprises most teams: wallet passes have that channel too. A pass can put a message on the lock screen, update its own contents in real time, and even surface itself when the customer is near your store.

The economics are different, too. SMS costs money per message and email fights the promotions tab. Pass notifications are part of how wallets work: there is no per-message fee, and the message lands on the lock screen, not in a folder.

The channel also behaves differently because it is attached to something useful. An app's push permission is granted once, grudgingly, and revoked at the first annoying message. A pass message rides on an object the customer chose to keep: the thing that holds their points and gets them through the till. Messages that arrive on the pass inherit that standing. It is a channel that is hard to abuse and easy to keep, which is the opposite of most.

The moment of use is faster

Picture the till. An app user unlocks their phone, finds your app, waits for it to load, navigates to their member code, and holds the screen at the scanner while the queue watches. A pass user double-clicks the side button and taps. Where the terminal supports NFC (Apple VAS and Google Smart Tap), identification happens in the same tap as payment. Where it doesn't, the pass shows a barcode that works with the scanners you already own, and either route identifies the member just as well.

Either way, the pass wins on the metric that decides whether people actually use your program: effort at the moment of use.

When an app is still the right call

We build pass infrastructure, so you might expect us to say "never build an app." That would be too neat. If your product genuinely needs rich interaction, such as ordering ahead, managing subscriptions, or browsing a catalog, an app can earn its place. But that is a product decision, not a loyalty decision. Membership, identification, rewards, and messages do not need an app. They need to be in the pocket, ready, with zero friction.

Start with the pass. If your customers later ask for more than a pass can do, build the app then, for the engaged audience the pass built you. The two are not rivals; a pass in every member's wallet is the best install audience an app could ask for. It is also a distribution channel in the literal sense: a pass can link straight into your app, and on iPhone a pass associated with your app can offer the install right from the pass, without a trip to the App Store. Every member is one tap from your app at the exact moment the pass has given them a reason to want it.

The short version

  • Every install step loses the casual customers your program exists to convert.
  • Passes live in wallets that ship with the phone, so joining is one tap, from any receipt, poster, or checkout.
  • Updates and lock-screen messages are built in, with no per-message fees and no app to maintain.
  • At the till, a pass is faster than an app: tap or scan, whichever your hardware supports.

Your brand does not need another icon on the home screen. It needs to be in the wallet, ready when the customer is. That is the program Stell runs for you: one platform issuing and updating passes across Apple Wallet and Google Wallet, wired to the systems you already have. See how it works.

Questions

Common questions

Does a customer need to install anything to use a wallet pass?

No. Apple Wallet ships with every iPhone and Google Wallet is on Android, so the pass has a home before the customer joins. Joining is one tap on a link from a receipt, a poster, an email or the checkout itself. There is no account to create and nothing to remember.

Can a wallet pass send push notifications without an app?

Yes. A pass update can put a message on the customer's lock screen, because that is part of how wallets work rather than a separate channel you have to build. There is no per-message fee, and the message lands on the lock screen instead of in a promotions folder.

Is a pass cheaper to run than an app?

The cost shapes are different. An app is a standing engineering commitment: a team, a backlog, a release cadence and two app stores to satisfy. A pass program is an integration you connect to your existing systems once, after which keeping ten thousand passes correct costs the same as keeping one correct.

What if we already have an app?

The two work together rather than competing. A pass can link straight into your app, and on iPhone a pass associated with your app can offer the install from the pass itself. A member base carrying your pass is the best install audience your app could ask for.

Do we still need NFC terminals for a pass to work?

No. Where terminals support NFC, identification happens in the same tap as payment. Where they do not, the pass shows a barcode that works with the scanners you already own. Both are first-class ways to identify a member.

More on wallet strategy

All articles
Next step

See what this looks like on a pass.

You have read how it works. The next pages show it on the terminals merchants already run, and the merchants running it.