Apple Wallet vs Google Wallet loyalty cards: what differs and what to do about it
You do not get to choose which phone your customers carry. The useful question is what changes between the two, and how to design one card that works on both.
The same idea, two sets of rules
Both wallets hold a loyalty card as a live object rather than a picture: it shows the customer’s name and progress, carries a code your staff scan, updates when something changes and can raise a notification. On an iPhone it lives in Apple Wallet, which every iPhone has. On Android it lives in Google Wallet, which comes on most Android phones and is a free download on the rest.
Behind the scenes they are built differently. Apple passes are signed files that the phone downloads and refreshes from your server. Google cards are records that live on Google’s side, in two layers: a class (the design shared by every card of one programme) and an object (one customer’s card). That difference explains most of what follows.
How each one draws your card
Apple gives you more control over the look. You choose the background, the text colours, the logo and a wide strip image across the middle, which is where most loyalty cards show their stamps. Field labels and values sit on the front in a fixed grid, and anything longer goes on the back.
Google is stricter. It takes your logo, a background colour and a wide hero image, and draws the rest in its own layout. It also adjusts colours to keep text readable, so the colour you picked may come out a shade darker or lighter on the phone. Design for Google first if you want the two to look alike, then let Apple show a little more.
- Keep the logo simple and legible at a very small size.
- Put progress (stamps, points, balance) in the image or the first field, not in small print.
- Do not rely on an exact brand colour on Android.
Notifications and location
On an iPhone, a card raises a lock-screen notification when one of its fields changes and that field carries a change message. In practice that means the message has to say something new each time: Apple stays silent if the text is the same as last time. Google Wallet shows messages attached to the card and can notify the customer when a new one arrives.
Both can bring the card up near your venue. Apple lets a pass name a handful of locations (up to ten) and the iPhone decides when to show it on the lock screen. Google has its own location features. In both cases the phone, not you, decides the moment, which keeps it from feeling like an advert.
Approval: the step that catches people out
Apple does not review passes. Once you have a developer account and a signing certificate, every correctly signed pass works on every iPhone.
Google does review. A new issuer account starts in demo mode, where only the issuer’s own test users can save a card; everyone else sees an error. You ask Google for publishing access, and until it is granted your Android customers cannot save the card at all. We learnt this the hard way. If you build it yourself, request publishing access before you print anything.
What to do
- Issue both. One QR code, and the page it opens offers Apple Wallet on an iPhone and Google Wallet on Android.
- Design once, for the stricter of the two, and check it on a real phone of each kind before launch.
- Write messages that change every time, or Apple will not alert anyone.
- Give staff one way to scan both: the code on the card is the same idea on either phone.
A platform like TAPPI issues both from the same design and the same QR code, which is the main reason businesses use one rather than build it. Whatever you use, test on an Android phone and an iPhone before the first customer does.