Apple Wallet vs Google Wallet: what your customers see

Documentation says what a phone is meant to do, and nobody tests every handset. Check anything you depend on with a real phone of each kind.

Staff do one thing for both cards: scan the code. native.cards gives each issued card its own code, a QR code unless you change it. The lists of formats matter only if your own barcode equipment must also read the card. In that case stay with QR, PDF417, Aztec or Code 128, which both lists carry without iOS 27.

Apple's advice to card issuers is that a card that cannot be scanned "shouldn't result in a blocked customer". It tells them to show the ID on the card "so it can be entered manually" and to train staff for that. By default a native.cards loyalty card shows the member ID under the code, and the Counter accepts it typed. Settle these four cases in advance.

The card looks wrong to the person serving. A colleague with an iPhone may never have seen your Google card, with its round logo, its differently cropped picture and its text in a colour Google chose. Show the team both cards once.

There is no card to scan. An Android phone older than Android 9, or one without Google Play services, cannot run Google Wallet. Some customers never tap the button to add the card. The membership does not depend on the card: in the words of the Issued Cards page, "their membership works without one". Staff type a member ID or a phone number, read the name back and press Yes, continue. Someone without a card rarely knows their member ID, so the phone number is what helps. You hold one only if your join form asked for Phone or staff added it at the counter.

The customer holds out a watch. Both companies say a card saved on the phone also appears on a paired watch. Apple says a watch "shows less information and fewer images than on iPhone", and that the line of text under the code "isn't displayed for watchOS". Google says that on a watch "certain passes with dense bar or QR codes may not scan properly". If a watch will not scan, ask for the phone.

The phone is new and the card is missing. Nothing is lost, because the balance was never on the phone. It is kept in your program. The customer signs in to your Business page with their email and a 6-digit code and adds the card again.

You design once. native.cards builds an Apple version and a Google version from that one design. Compare in the card designer puts the two next to each other, each with its own controls. Some differences cannot be designed away:

• Apple's version has three colour settings. Google's has one, Card colour, and the designer notes that Google picks the text colour.
• Apple has its strip where Google has a hero image.
• Google arranges values in Rows on the card: "Up to three rows, with one, two or three values in each."

How to design a Wallet Card customers recognise covers those decisions.

In native.cards a notification's Headline takes up to 80 characters and its Message up to 500. Google recommends far less for what shows in the notification itself: a title under 29 characters, a body under 40 before it is expanded and under 80 after, "to prevent truncation for users with small devices or increased font sizes". So get the point in before the 29th character of the headline and the 40th of the message. Treat the rest as detail.

The composer previews both phones, under Android and iPhone. Its captions state the difference: "Android shows it as a Google Wallet notification and keeps it on the card." and "On iPhone the updated card shows it on the lock screen and keeps it in the card’s details." You set how long it stays under Keep it on the card for. On either phone, "Members can turn notifications off." How often should you send notifications? covers what is worth sending.

Neither Wallet decides whether a customer can pass your card to someone else. Apple gives the issuer a switch for the Share button. Google asks the issuer for a preference. In native.cards every card is built the same way: the Apple card without the Share button, and the Google card for one person on their own devices. A Digital ID, boarding pass or travel pass stays on one device.

A family that wants to pool what it earns does not share a card. Each person joins and holds their own, and a Family Account pools what they earn.

For September 2026, StatCounter put Android at 55.23% and iOS at 44.75% of mobile web page views in Malaysia. That measures browsing across the country. It does not count phones, and it says nothing about your own customers. As an example with made-up numbers: if 300 members followed those shares, about 166 would carry the Google card and 134 the Apple one. A card in only one Wallet would leave well over a hundred of them without one.

There is nothing to turn on: both Wallets come with your account once native.cards approves your business, and you do not need Apple or Google developer accounts. Once your card design is published, customers can add the card. The Business page is built to show each phone the button for its own Wallet.

Your own split is on Issued Cards, which counts the active cards issued for Apple Wallet and for Google Wallet. The two figures are not equally complete. Apple's comes with the number "registered on a device", which the page calls "Apple's signal that the card was added". Google's carries the note "Saved-card total unavailable".