Notes from the counter
For the customer, almost nothing: both are already on the phone, both cost nothing, and a card is added from a link with no account and no download. For whoever issues the card the two platforms differ in ways that matter — what you must hold to sign a pass, and, more than anything else, what makes a phone show a notification.
Last updated 26 August 2026
For the customer, the difference is nearly nothing
Both wallets ship with the phone. Neither can be uninstalled by accident, neither asks for an account before a card can be added, and neither charges the person holding the card. Adding one is a link, a preview, and a button — no download, no password, no email address unless the card asks for one.
That similarity is the reason wallet cards work at a counter at all. The question "which wallet do you use?" never has to be asked: one link decides for itself which pass to hand over.
What it takes to issue one
This is where the platforms stop resembling each other, and it is the part that decides whether a small business builds this itself.
An Apple pass is a signed file. Producing one needs an Apple Developer Program membership, currently 99 US dollars a year, and a pass type identifier with its certificate. The certificate expires and has to be renewed, and passes signed with a lapsed one stop being accepted.
A Google pass is a record on Google's servers, referenced by a signed link. It needs a Google Wallet issuer account and a service account key to sign with. There is no annual fee, but issuer accounts are reviewed before they can send to the public.
Supporting both means holding both sets of credentials, keeping both current, and building each pass twice — the formats share nothing. It is the single largest reason a shop that wants a wallet card uses something that already has them.
Neither wallet has a way to send a message
This surprises nearly everyone, and it is the most consequential difference on the page: there is no notification API in either wallet. Nothing can push a message to a pass holder directly.
What both platforms have instead is a notification derived from a change to the pass itself. The pass is updated; the phone is nudged to come and fetch it; and whether anything appears on the screen depends on rules each platform sets.
- Apple raises an alert only for a field that carries a change message and whose value has actually changed. Update a pass without changing such a field and the phone updates in silence.
- Google raises one only for a message entry explicitly marked to notify. The same update without that marking is applied quietly.
- Neither reaches a phone that has not registered for updates — usually one that has never opened the pass since it was added.
The practical consequence is that a message is a change to a card someone is carrying, not a broadcast. It is worth designing around rather than working around: the reason a wallet card can send anything at all is the same reason it cannot send very much.
Barcodes, and why the format is not cosmetic
Both wallets can render QR, PDF417, Aztec and Code 128. Which one a card should use is decided by what will read it, not by which looks best on the screen.
A card scanned by a phone can use anything. A card that has to be read by an existing till scanner is constrained by that hardware — a laser scanner reads Code 128 and will not read a QR code at all, and the format has to be chosen before the cards are issued rather than after.
Which one to support
Both, in practice. A shop cannot know which phone the next customer is carrying, and a loyalty card that works for half a queue is worse than none — it makes staff ask a question at the till that has no good answer.
The decision that actually matters is not Apple against Google. It is whether issuing to both is something worth building and maintaining, or something to be handed to whatever already does it.