Wallet Loyalty Card or Mobile App: What Should a Business Build?

A loyalty card is not a reason to install another app

Picture a customer buying flowers on the way home. They want to collect a reward and leave, not choose a password while a queue forms behind them. A wallet pass may fit that moment much better than a dedicated app. Now picture the same customer arranging recurring deliveries, changing an address and following an order. A card alone will not provide that experience.

The useful comparison is not which format looks more impressive. It is what the customer needs to do between visits and what the business must keep consistent behind the scenes. This guide is for businesses choosing a channel, not consumers looking for somewhere to store plastic cards.

Our starting position is deliberately simple: do not commission an app solely to display a barcode. Equally, do not stretch a wallet card into a complicated service just to avoid building the right interface. The examples below are illustrative planning scenarios, not reported client results.

What a wallet card does, and what it does not

An issuer-created loyalty pass can carry a customer reference, a scannable code and information about a program. Apple and Google provide ways to distribute and maintain passes, but the details differ. The Google loyalty-card overview is a useful introduction to its own platform, not a promise that the same setup works everywhere.

The pass is one presentation of a customer relationship. It does not, by itself, decide which purchases earn points, handle returns or settle a dispute about a missing reward. Those rules still need a reliable system and someone responsible for them.

A dedicated application gives you more control over a complete journey: browsing products, choosing a service, booking, paying, reviewing history or contacting support. That control brings work of its own. Sign-in, updates, accessibility, account recovery and customer service remain part of the product after the first launch.

Choose the smallest channel that completes the job

Use this table to narrow the first release. It is a planning framework, not a feature guarantee for every provider.

A hybrid can be sensible without being the first version. If you cannot yet describe a meaningful task that requires the app, test the simpler channel first. For the mechanics behind either choice, use our loyalty app development guide.

The real test happens at the till

Imagine a florist offering one stamp for each qualifying visit. In a pilot, the cashier scans the customer's pass and the system records a completed purchase. The next visit earns another stamp. That sounds easy until the customer returns an item, the cashier scans twice or the connection drops halfway through.

Write down which event earns the stamp and how it is linked to the transaction. A scan should not automatically mean a completed purchase. A repeat notification from the till should not issue another reward. If the reward is reversed, staff need a reason they can explain without guessing.

Square's guide to managing loyalty points provides a concrete example of points and adjustments in one provider's system. Your own till may behave differently. Ask for a demonstration using your actual configuration rather than accepting “we integrate with POS systems” as a complete answer.

The useful acceptance test is a short sequence: purchase, duplicate scan, return, correction and another purchase at a second branch. Keep the customer balance visible to support throughout it. A beautiful card cannot compensate for a balance that changes unpredictably.

Offline display is not offline redemption

A customer may be able to open a saved card without a fresh connection. That does not prove the till can authorize a reward safely while disconnected. The displayed balance may be older than the central record, or a reward may already have been used elsewhere.

Decide whether an offline visit is recorded for later reconciliation, refused politely or handled through an approved staff procedure. Do not let each branch invent a different answer. The important distinction is between showing an identifier and authorizing something with value.

Similarly, displaying a barcode is not the same as supporting contactless loyalty. Apple's loyalty-pass guidance describes additional requirements for contactless experiences, including compatible readers and point-of-sale software. A terminal accepting contactless payments is not sufficient evidence that your planned loyalty interaction works.

Check reach before promising convenience

“Everyone already has a wallet” is a weak product assumption. Check the devices your customers actually use, the countries where the service will run, platform availability and your provider's eligibility requirements. Google's availability page separates supported features; consult the relevant country rather than treating one market as universal.

Offer a reasonable alternative when saving a pass is unavailable or unwanted. Depending on the program, that could be a web account, a physical card or staff-assisted lookup with suitable identity checks. The fallback should not expose another customer's balance just because two people share a name.

Keep payment support separate from loyalty support in the project brief. A restriction or capability affecting one does not automatically describe the other. Confirm the exact flow on real devices before printing a large batch of checkout signs.

One customer, one balance, several ways to reach it

The stable part of the system should be the customer account and reward history, not the visual card. A pass identifier, app login and till reference need a deliberate mapping. Otherwise, someone who installs the app after saving a pass may accidentally receive a second account.

The same principle matters when changing suppliers. Ask what can be exported: customer identifiers, transaction history, balances, outstanding rewards and the version of the rules under which they were earned. Do not assume an export of email addresses is enough to reconstruct a loyalty program.

Our CRM and ERP integration guide explains the broader ownership problem. For this decision, keep it concrete: who can correct a balance, who approves the correction, and where is the reason recorded?

Notifications are not a guaranteed retention strategy

A pass can be useful without sending frequent messages. An accurate balance and quick checkout may already solve the problem. Wallet update and notification behavior depends on the platform, configuration and user settings; it is not an unrestricted replacement for every app messaging feature.

The same restraint applies to a dedicated app. More control over messaging does not mean people welcome more interruptions. Tie a reminder to something understandable, such as a usable reward or a booked service, and provide the required choices for the relevant market.

The vendor comparison from Punchd is worth reading for the wallet-first argument. It sells that approach, so treat its preference as a perspective to test, not independent proof of better results. Measure your own program using retention goals rather than borrowing a promised conversion rate.

Run a pilot that can disprove your first choice

Choose a small operating area and one reward rule. Watch customers save the pass or enter the application, retrieve it at the next visit and redeem a reward. Include people who need larger text, have an older phone or do not want to create another account.

Record failed scans, staff corrections, unresolved balances and time spent explaining the process. Separate successful enrollment from a later qualifying visit. A saved card is not evidence that someone returned because of the program.

Compare with a relevant baseline where possible, and record other changes such as a seasonal promotion. A small, self-selected pilot cannot establish causal retention uplift. It can still reveal whether the workflow is understandable and reliable.

Before deciding to expand, ask staff what went wrong. A repeated need to manually find customers may matter more than the number of passes issued. That is a product finding, not a reason to hide the result.

When a dedicated app becomes the better choice

An app earns its place when the recurring task extends beyond identifying the customer. A restaurant may need repeat orders and collection slots. A salon may need appointment changes and service history. A learning business may need lessons and progress. In each case, loyalty supports the service rather than replacing it.

For appointment-heavy products, compare the requirements with our booking app guide. Avoid rebuilding an adequate mobile website only to obtain a home-screen icon. Keep the wallet pass as a quick identification route if it still helps.

At Appfyl, the useful starting point for a scope discussion is the customer journey, existing systems and failure cases. The project brief collects those details for review; it does not display an instant quote. Bring the pilot findings and unresolved integration questions, not just a list of screens.

Questions people ask