Apple Wallet vs Google Wallet for loyalty cards

If you are issuing loyalty cards, you do not choose between Apple Wallet and Google Wallet, your customers already chose, by buying a phone. What matters is knowing where the two behave differently so nothing surprises you after launch.

Do I need to support both wallets?

Yes. Any enrolment link that offers only one wallet will silently fail for roughly half your customers, and they will not tell you: they will simply not have a card.

A correctly built enrolment page detects the device and shows the right button, with the other available as a fallback. Loonine does this automatically; if you are evaluating another platform, open its demo link on both an iPhone and an Android phone before believing the marketing page.

How do the two platforms compare?

What are the practical gotchas?

1. In-app browsers. Links opened inside some social apps block card installation. The fix is to open in Safari or Chrome, and a good enrolment page says so rather than leaving the customer stuck.
2. Desktop links. Cards install on phones. A customer who opens the link on a laptop sees nothing useful, so the message must reach them on the device they carry.
3. Field limits. Apple's template allows a fixed number of fields. A card design that relies on six data points will be truncated, so design for the constraint rather than against it.
4. Update latency. Pushes are usually seconds but are not guaranteed instant. Never build a flow where staff wait for the customer's screen to refresh before serving them.

Which one gets better engagement?

Neither platform has a decisive engagement advantage for loyalty cards. Reported wallet push open rates around 90% are quoted for wallet cards generally rather than for one platform, and the variation between businesses is far larger than the variation between wallets.

What does move engagement is relevance: a card that surfaces on the lock screen when the customer is near your shop is opened; a card that pushes a generic message on a Tuesday afternoon is dismissed.

How does a card update on each platform?

On both platforms the update is pushed by the operating system rather than fetched by an app, which is why a wallet card can change while the customer's phone is in their pocket. The mechanism differs slightly and the practical behaviour is nearly identical.

Apple Wallet registers each installed card with the issuing server. When the business changes something, the server signals Apple's push service, the phone requests the new version, and the card updates in place, usually within seconds. Google Wallet works against the card object stored on Google's side: the business updates the object through the API, and Google propagates it to every device holding that card.

The consequence for a business is the same in both cases: you never reissue a card. Changing the reward, the design or the stamp count updates every card already in circulation, including the ones on phones that are currently switched off.

What are the design limits?

Apple enforces a fixed card template with a set number of labelled fields, while Google allows somewhat more layout freedom, but both are far more constrained than a web page, and designing against the constraint produces better cards than fighting it.

The practical rule is that a loyalty card should communicate two things at a glance: whose card it is, and how close the customer is to the reward. Anything else competes with those two and usually loses. Business name, stamp count, reward text: that is a complete card.

Test in dark mode before launching. A logo with a transparent background and dark lettering disappears entirely on a dark card, and this is the single most common design mistake in the category.

Do customers need an account?

Apple Wallet requires no account at all: the card installs on the device with no sign-in. Google Wallet requires the phone to be signed in to a Google account, which is true of essentially every Android phone in normal use but is worth knowing as a failure mode.

Neither platform requires the customer to create an account with you or with the loyalty provider. This is the core privacy advantage of wallet loyalty over an app: there is no password, no email verification, and no profile beyond the identifier the business already needed.

What about other wallets?

Apple Wallet and Google Wallet cover effectively the entire smartphone market that a local business will encounter, and supporting both is sufficient. Other wallet apps exist, and none of them is worth engineering for in this context.

The one situation worth knowing about is newer Huawei devices shipped without Google Mobile Services, which cannot install Google Wallet cards. These are rare in most markets and more common in some. If a customer's phone cannot hold a card, a paper card remains the right answer for that customer.

Why did the card fail to install?

Installation failures cluster into four causes, and all four are on the customer's side rather than the platform's, which means a good enrolment page can pre-empt every one of them.

The in-app browser case is the one that costs real enrolments, because it fails silently: the customer taps, nothing visible happens, and they conclude the card does not work. An enrolment page that detects the situation and says "tap the share icon, then Open in Safari" recovers most of them.