Google Wallet for business owners: how it really works (and why it's underrated)

70% of smartphones sold in France run on Android. And yet, when people talk about a digital loyalty card, everyone thinks first of Apple Wallet. That is a strategic mistake. Here is how Google Wallet actually works on the business owner's side in 2026, what it can do, what it cannot do, and why you can no longer afford to ignore it.

Why Google Wallet is the forgotten market for business owners

When a business owner calls me for the first time, they often say: "I'd like a card in the iPhone Wallet". Fair enough, that's the image they have in mind (the little card that pops up on the lock screen when you walk into the café next door). But behind that image lies a statistical truth we forget:

• Android = 69.5% of smartphones in France (market share Q4 2025, Kantar Worldpanel).
• iOS = 29.8%. The rest is HarmonyOS and unidentified devices.
• Among affluent urban under-35s, the iPhone climbs back up to around 45%. But as soon as you step outside central Paris and look at the average clientele of a restaurant, a hairdresser or a bakery, Android crushes everything.

In concrete terms: if you only have an Apple Wallet card and you offer nothing to Android customers, you're leaving roughly two thirds of your clientele without a solution. You give them a free coffee verbally and call it a "loyalty programme", which is exactly the situation a digital card is meant to get you out of.

The problem is that Google Wallet is less visible than its Apple cousin. Nobody advertises for it, you hear less about it in the press. But the tool is there, it works, and on some points it's even simpler to set up than Apple Wallet for the business owner.

Google Wallet vs Google Pay: yes, it's the same thing now

A quick clarification before we go further, because this question comes up at every meeting. Google has muddied the waters a lot over the past few years:

• 2018-2022: two apps coexist, Google Pay (payment) and Google Pay (loyalty cards, tickets, etc.). Not clear, even for Google.
• Mid-2022: Google Wallet officially replaces Google Pay in France. The app is now called "Wallet" (blue icon with a wallet).
• 2024-2026: Google Wallet is built natively into Android 11+. On nearly every phone sold in the European Union, the app is preinstalled and configured by default.

For a business owner, that means three things: (1) the API that lets you generate loyalty cards is now called the Google Wallet API (formerly the "Google Pay API for Passes"), (2) the same API handles loyalty cards, gift cards, event tickets and boarding passes, and (3) every Android customer already has the wallet installed, which completely removes the friction on the install side.

How a Google Wallet loyalty card works (on the customer's side)

Let's spend two minutes in the shoes of a customer who has never used Google Wallet in their life. Here is exactly what happens when they scan your "Add your loyalty card" QR code with their Android phone:

1. The QR code sends them to a web page (mobile-first, hosted by your provider). This page detects that they're on Android and shows a big "Add to Google Wallet" button.
2. They tap it. The browser calls the signed URL https://pay.google.com/gp/v/save/<JWT> which contains a token signed with the loyalty programme (your logo, your colours, the customer's data).
3. Google Wallet opens automatically (native deeplink). The customer sees a preview of the card with a "Save" button.
4. They tap "Save". The card is added to their wallet, in under 5 seconds, with no account creation, no password, no download.

From then on, the card lives its life in Google Wallet. It shows up on the lock screen when the customer passes near your shop (if you've set up the zones), it appears at the top of the wallet during NFC payment, and it can receive push notifications directly from the server.

On the business side: creation, updates, push notifications

Here's the technical part you never read on sales pages, but which is worth understanding so you don't get taken for a ride. To issue a Google Wallet card, you need four building blocks:

• A Google Issuer Account: an issuer account, manually reviewed by Google (2 to 5 business days). One account per legal entity.
• A class (Loyalty Class): the definition of your programme's template: logo, colours, the structure of the fields displayed, the mechanic (stamps, points, tiers).
• An object (Loyalty Object): the individual instance of the card for each customer: card number, name, current balance.
• A Google Cloud service account: the technical credentials (JSON key) that let the business owner's server sign the add JWTs and call the REST API to update the cards.

Once this setup is in place, updating a card is a simple authenticated HTTPS request. You change the stamp balance, the message text, or a promotional offer, and Google propagates it to every Android phone the card is installed on. Propagation happens via Firebase Cloud Messaging (FCM), the same infrastructure that powers push notifications for every Android app.

In concrete terms, this means Google Wallet notifications are just as reliable as a regular app notification. No black box, no dodgy queue: if the phone is on and connected, the notification arrives within a few seconds. It's often even faster than Apple Wallet, which goes through the APNs servers with a send frequency that Apple sometimes throttles.

To go further on push, I've covered this topic in a dedicated article: push notifications in Wallet for restaurants, what really works.

Google Wallet vs Apple Wallet: a table of practical differences

Since I spend my life comparing the two in business audits, here's the honest summary of what changes between the two wallets, from the point of view of a French business owner who wants a loyalty card:

The big takeaway: the two technologies do broadly the same thing for the business owner, but with different plumbing. The real question isn't "which one to choose", it's "how do I offer both automatically, without asking every customer for their phone model".

On the Apple question, I've written a specific guide: Apple Wallet loyalty card for restaurants, the complete guide. It complements this one.

Why ignoring Google Wallet means losing 70% of your customers

I still see a lot of providers (and a lot of business owners tinkering on their own with free tools) who only offer Apple Wallet, because it's simpler on the technical side (signing a .pkpass is the classic tutorial exercise). That's a glaring mistake:

• The Android customer scans the QR code and lands on "Download Apple Wallet". They're lost. At best they try to muddle through, at worst they give up and hold it against you.
• Word of mouth is asymmetric: the Android customers who couldn't install the card say nothing, they just forget your programme.
• Your best potential customers are on Android. The average loyal customer of a neighbourhood business (not necessarily the trendy type from a hip district, more like the couple of forty-somethings from down the road) is statistically on Android in 2 cases out of 3.

If you want to quickly test what a card that works on both operating systems looks like, with no technical thinking on your side, you can start a free trial: adding the card works on iOS as well as on Android, with no configuration from you. Start the free trial (no commitment, no bank card required).

Not sure whether your clientele is more iOS or Android? I'll help you decide

Step by step: creating your Google Wallet card

If you want to do this yourself (out of technical curiosity, or because you're a developer), here is the real sequence, without oversimplifying:

1. Create a Google Cloud project: go to console.cloud.google.com, create a new project (for example "wallet-cornercafe"), enable the Google Wallet API.
2. Request an Issuer Accountvia the Google Pay & Wallet Console. You fill in a form (company name, registration number, website, description of the programme), and Google approves it in 2 to 5 days.
3. Create a service account in the Cloud project, download its JSON key, and link this account to the Issuer Account by granting it the "Wallet Object Issuer" role.
4. Define the Loyalty Class via an API call or the web interface. This is where you put your logo, your colours (hero, header, background), the display structure (a "stamps" field, a "VIP level" field, etc.).
5. Generate a signed JWT on the server every time a customer asks to add their card. The JWT contains the Loyalty Object data (card number, first name, initial balance).
6. Set up the updates: on every change (new stamp, new offer), your server calls the Google Wallet REST API to patch the Loyalty Object. Propagation is automatic.

That represents roughly 2 to 4 weeks of development for someone discovering the API, plus the Google approval delay. It's doable, but it's rarely cost-effective compared to a subscription to a turnkey tool. To understand the full mechanics of a modern digital loyalty card, I'd recommend first reading the 2026 guide to the digital loyalty card.

The Samsung, One UI and Knox case: everything works the same (almost)

Samsung accounts for around 35% of the French Android install base. Legitimate question: does Google Wallet work as well on a Galaxy as on a Pixel?

Answer: yes, 99% of the time. Google Wallet is preinstalled on every Samsung sold in France since 2022 (One UI 4 and above). It coexists with Samsung Wallet, Samsung's in-house equivalent, but the two don't interfere: the user chooses which one to add their card to. In 95% of cases, the "Add to Google Wallet" deeplink points natively to the Google app and not to Samsung Wallet.

The only small pitfall is on older Samsungs (One UI 3 and below, released before 2021), where the Google Wallet app isn't preinstalled and has to be downloaded. But this population represents less than 4% of the install base in 2026, and it's in free fall. For the rest (Samsung Knox, enterprise configurations, secondary accounts), no impact: Google Wallet cards are stored in the main user's Google account and work just like on any Android device.

The real pitfalls of Google Wallet (the ones nobody tells you about)

To be fully honest, here's what can go wrong with Google Wallet, whether during integration or in use:

• The manual review of the Issuer Account can be a pain. Google sometimes asks for several rounds back and forth (screenshot of the site, proof of domain, a sample card). For a business owner on their own, that's a real barrier. Going through an already-approved provider skips this step.
• Clickable links in notifications are limited. Unlike a native app, you can't put a "Book now" button that opens an external page directly from the notification. The tap opens the card, and the card can display a link, which is one more step than in native Android.
• Geofencing is less fine-grained than Apple's. 10 zones maximum, no Bluetooth beacons. For a single-location business that's fine, for a chain of 30 shops on a single programme it's not enough.
• Push send frequency is "reasonable". Google doesn't impose a strict limit, but from one notification per week per card, you start to see uninstall rates rise. As everywhere, content beats frequency.
• The visual preview differs slightly from Apple. The Google Wallet card is more "Material Design" (square, with more pronounced shadows), whereas Apple Wallet is more minimalist. You have to accept that the same programme displays differently on iOS and Android.

None of these pitfalls is a deal-breaker. But it's important to know them so you're not disappointed on arrival. To sum up: Google Wallet is technically younger than Apple Wallet (which has existed since iOS 6 in 2012), but it caught up on the essentials in 2024-2025, and it even has some advantages (FCM faster than APNs, a free Issuer Account where Apple charges $99/year).

Should you choose, or do both? The recap

A trick question, but a simple answer: you should do both, automatically, with no thinking required from the customer.

The good experience is this: the customer scans a QR code, the page detects their operating system (User-Agent), and offers them the right Wallet with no questions asked. iPhone leads to Apple Wallet, Android to Google Wallet. No middleman, no choice to make, no possible confusion.

That's the principle of a modern loyalty card, and it's what sets a "real" Wallet card apart from a web page that imitates a card. I've explained this difference in detail here: loyalty card with no app, why it's become the norm. And for the concrete step on the customer's side, here's the walkthrough to add the card to Apple and Google Wallet. If you'd rather see the product for real, discover the Pépite Pass digital loyalty card.

If you want to test it in real conditions, I can set up a demo card in your name (with your logo, your colours, your stamps), iOS and Android, in under 24h. You install it on your own phone, you see how it works, and we talk. Book the demo.

6 key takeaways

• 70% of your customers are on Android. Ignoring Google Wallet means ignoring the majority of your clientele.
• Google Wallet replaced Google Pay in 2022. One app, one API, preinstalled on every recent Android device.
• On the business side, the mechanics are: Issuer Account leads to Loyalty Class, then Loyalty Object, then a signed JWT. Push via Firebase Cloud Messaging.
• Technically simpler to integrate than Apple Wallet (no $99/year certificate), but Google approval takes longer (2 to 5 days).
• Differences with Apple Wallet: faster FCM notifications, but more limited geofencing, and less rich clickable links.
• The right approach is to offer Apple Wallet AND Google Wallet automatically, without making the customer choose.

A digital card without Google Wallet in 2026 is a shaky card. You can ignore it, but you pay for it in lost Android customers, in notifications never received, and in a loyalty programme that never really takes off.