Apple Wallet vs Google Wallet for loyalty cards
Both wallets can put a message on a customer's lock screen. Neither takes arbitrary push text, and only one caps you at three a day. What that means.
On this page
- The short answer
- What actually happens when you send a message
- Apple: the notification is a side effect
- Google: the notification is the point
- The two differences that actually matter
- 1. Google caps you at three a day
- 2. Google controls the presentation
- Location relevance: the one that needs no send
- Side by side
- What this means for a small business
- What Passumo does with this
- Frequently asked questions
- Where to go next
If you are choosing how to run a loyalty program, the question is not which wallet has the better developer API. It is whether the card you hand out can bring somebody back through the door on a quiet afternoon.
Both wallets can now do that. Comparisons written even a year ago will tell you Google Wallet cannot send notifications; that stopped being true, and Google’s own documentation was last updated on September 1, 2026 to describe exactly how it works. What is left is a narrower and more useful difference: how much control each platform gives you over the message, and how often you are allowed to send one.
Key takeaways
- Both wallets support developer-triggered messages that surface on the lock screen. The old “Apple can, Google cannot” framing is out of date.
- Neither lets you push arbitrary free text directly. Apple’s notification is a side effect of a pass field changing; Google’s is an explicit message you author and send.
- Google caps notification-triggering messages at three per pass per 24 hours and controls how the notification looks. Apple documents no equivalent cap.
- Both support up to 10 merchant locations, so a card can surface when a customer is nearby without you sending anything at all.
The short answer
Run one program across both. The split in any given shop follows the local phone market, and dropping half your customers to simplify a send is a bad trade.
The practical difference is a ceiling, not a capability: on Google you get three notifying messages per customer per day, and Google decides how they are presented. On Apple you get more room and more control over the wording, but you have to change something on the card to say anything at all.
What actually happens when you send a message
The two platforms arrive at the same customer experience by opposite routes, and the route explains the constraints.
Apple: the notification is a side effect
Apple’s push payload is, literally, an empty JSON dictionary. It carries no text. It only tells the device that its pass is stale, and the device then re-fetches the pass from your server.
The device compares the new version against the old one. If a field has changed
and that field carries a changeMessage, iOS shows that message on the lock
screen. So the notification text is a property of the card, not of the push.
This is why sending a campaign on Apple means writing the message onto the pass
first. Passumo puts it in a “Latest news” field with a changeMessage of %@,
which renders the message verbatim, then fires the silent push. Wallet
re-fetches, notices that field changed, and shows the line.
It also explains a nice property: because only changed fields fire, a stamp added the next morning does not replay yesterday’s campaign.
Google: the notification is the point
Google works the way you would expect. You call addMessage on the customer’s
loyalty object with messageType: TEXT_AND_NOTIFY, and Google adds the message
to the pass and triggers a push notification for it. Tapping it opens Wallet on
the pass with a “View Message” callout.
You can address a whole loyalty class or one individual object, which is the difference between a broadcast and a message to one person:
| Sent to | Example | |
|---|---|---|
| Class | Everyone holding the card | “Double stamps today” |
| Object | One customer’s pass | “One more stamp and the tenth is on us” |
Google also has a separate mechanism for progress: set notifyPreference to
notifyOnUpdate and changing loyaltyPoints.balance will notify on its own,
which is closer to how Apple behaves.
The two differences that actually matter
1. Google caps you at three a day
You may send a maximum of 3 messages that trigger a push notification in a 24 hour period.
Go over it and the API returns a QuotaExceededException; the documented
remedy is to use the plain TEXT message type for anything further, which
updates the card without notifying.
Apple documents no equivalent limit. Its guidance is a best practice rather than a quota: send only to devices registered for that pass, and only when the pass has actually changed.
In practice this ceiling should never bind. Three notifications to one customer in a day is already well past the point where the card gets deleted. One well-timed message beats four ignored ones. Treat the cap as a guard rail confirming a limit you should be imposing on yourself anyway.
2. Google controls the presentation
Google’s documentation is explicit that the push notification the user sees on the lock screen is controlled by Google Wallet. You author the words; the container is theirs.
Apple gives you more say, because the text is a field on a pass you generate, but you buy that control by having to change a field to trigger anything.
Neither platform, it is worth being clear, lets you send arbitrary free text straight to a phone. They differ in which half of the job you own.
Location relevance: the one that needs no send
Both platforms let a pass carry up to ten merchant locations, and both can surface the card when the customer is near one.
For a single-site shop this is quietly the most valuable notification you have, because it fires when the customer is closest to acting on it and it costs nothing per send. It is also the one mechanism that does not depend on you composing a campaign at the right moment.
Two caveats worth knowing. The customer must have notifications enabled for their passes. And on Google, nearby notifications require the customer to have granted precise, always-on location access to the Wallet app, a permission plenty of people decline. Treat location as a bonus that reaches some of your list very well, not as blanket coverage.
Side by side
| Apple Wallet | Google Wallet | |
|---|---|---|
| No app download | Yes | Yes |
| Remote balance updates | Yes | Yes |
| Lock-screen notification | Yes | Yes |
| Developer-triggered message | Yes, via a field change | Yes, via TEXT_AND_NOTIFY |
| Message to one customer | Yes | Yes, on the object |
| Who controls presentation | You, through the pass | Google Wallet |
| Documented daily cap | None | 3 notifying messages / 24h |
| Merchant locations | 10 | 10 |
| Cost to the customer | Free | Free |
What this means for a small business
Very little, day to day, which is the honest answer.
You write one campaign and it goes to everyone. The mechanism underneath differs and the ceiling differs, but the message a customer sees on a Tuesday afternoon looks much the same on either phone. The decisions that change your results are not on this page: they are how long the card is, what the reward is, and which hour you aim the promotion at.
Where the difference does show up is if you plan to message people often. A three-a-day ceiling on Google is invisible to a shop sending one considered message a week. It is immediately binding for one sending four a day. That shop has a bigger problem than the cap.
What Passumo does with this
One card design, issued to both wallets. Balances sync to both on every scan.
A campaign written once goes out down whichever path each platform provides:
the pass-field route on Apple, TEXT_AND_NOTIFY on Google. You do not pick a
mechanism, and you do not maintain two programs.
The certificates, signing keys and update servers each platform requires sit underneath. What is left for you is the part worth your attention: what the card says, where it triggers, and how often you are willing to interrupt someone.
Frequently asked questions
Can I send a promotional message to someone with a Google Wallet loyalty
card?
Yes. Google supports developer-triggered messages using TEXT_AND_NOTIFY,
which adds the message to the pass and triggers a push notification. Google
limits notifying messages to three per pass per 24 hours, and the customer must
have notifications enabled.
Can I message one customer rather than everyone? Yes, on both. Google supports messages on an individual loyalty object as well as on the class; Apple’s messages are per-pass by nature. That is what makes “one more stamp and the tenth is on us” possible as a targeted send rather than a broadcast.
Does a customer need Apple Pay or Google Pay set up? No. Wallet passes and payment cards are separate. Somebody who has never added a bank card can still hold a loyalty pass.
Which should I prioritize? Neither. Issue to both, and choose the wallet your customer already uses rather than making them choose yours.
Is the old advice that Google Wallet cannot notify simply wrong now? Yes. It was true for long enough that a lot of published comparisons still say it, and Google’s own FAQ page still carries a line to that effect, but the loyalty-card notification documentation supersedes it.
Where to go next
The notification mechanism is a smaller input into your results than the card itself. What a stamp card is actually for covers the economics, and how many stamps a card should have covers the arithmetic. Writing a message people do not delete covers the three notifications a day you should not be sending. Getting the pass onto the phone in the first place is the counter QR code.
If you want the card in both wallets without touching either API, that is what Passumo does, and there is a worked example for cafés.
Sources: Google Wallet loyalty card push notification guide (updated September 1, 2026) and generic pass notification guide; Apple’s Wallet Developer Guide: Updating a Pass and PassKit framework reference.