Apple Wallet vs Google Wallet for loyalty programs in 2026: the merchant guide — Stampo

If you're a small merchant launching a digital loyalty program in 2026, you'll see most vendors say "supports Apple Wallet and Google Wallet" on the marketing page. That sentence hides a long list of practical differences that decide whether your customers actually add the card at the counter, whether your push notifications get seen, and how much friction your barista or cashier deals with on the Android side.

This article is the side-by-side: adoption, merchant setup, customer add-flow, push notification limits, and which one to launch with first.

We make Stampo, a digital loyalty card SaaS in the standalone wallet-pass category. We ship Google Wallet today and Apple Wallet is rolling out post-Apple-Developer KYC. We have a bias toward both wallets being good — the bias doesn't change the table below.

The 30-second answer

For a merchant in 2026:

Apple Wallet is more polished, more visible to the customer (sits next to their boarding passes), and has the higher engagement rate when customers do add the card. The constraint is merchant-side setup: Apple requires the merchant (or their SaaS vendor) to have an Apple Developer Program account, which takes 1–4 weeks of KYC to approve.
Google Wallet is faster to launch for a merchant (no Apple Developer KYC required from the SaaS side; merchants enrol via the SaaS without their own developer account in most cases). Adoption is lower than Apple Wallet on a like-for-like customer base, and the visual polish on the pass itself is slightly less refined in 2026.

Most merchants should launch on both simultaneously through their SaaS, with Google Wallet shipping immediately and Apple Wallet shipping once the SaaS's Apple Developer setup is done. If your SaaS hasn't done Apple's KYC yet, ship Google-only first — don't wait.

Adoption: who carries which wallet

The market is split roughly 50/50 between iPhone and Android in the US and EU as of 2026, with country-level variation. Iphone share is higher in the US, UK, Australia, Switzerland; Android share is higher in Eastern Europe, Asia, Latin America. A café in Paris and a café in Warsaw have different wallet-adoption skews — pick accordingly if you can only launch one wallet.

Apple Wallet usage is broader than people assume because it ships with every iPhone, is preinstalled, and is increasingly the default UI for boarding passes, event tickets, and payment cards. Customers who already use Apple Pay are very likely to add a loyalty card to Apple Wallet on first contact. Apple's own numbers from WWDC 2025 implied ~85% of iPhone users have used Apple Wallet at least once.

Google Wallet usage is narrower than people assume on Android. Google Wallet was relaunched in 2022 as a successor to Google Pay, and adoption is uneven — heavy in markets where Google Pay had strong NFC payment penetration, lighter elsewhere. Customers in some markets need to install Google Wallet first; in others it's pre-installed on the Android device. This is the friction point most "Apple vs Google" articles miss.

The practical implication: if your customer base is iPhone-heavy (premium retail, design-led café in a city centre), the Apple Wallet launch is more important. If it's Android-heavy (mass-market retail, lower price points), the Google Wallet launch matters more — and you need to test the Android add-flow on at least three real Android devices before going live.

Customer add-flow: side by side

How does a customer actually add the loyalty card to their wallet? This is the step that decides whether your counter QR converts at 80% or 30%.

Apple Wallet add-flow (iPhone)

Customer scans the merchant's counter QR with their iPhone camera.
Phone opens the merchant's landing page in Safari.
Landing page shows an Add to Apple Wallet button.
Customer taps it; Apple Wallet opens; customer taps Add in the top-right.
Card is in their wallet, accessible from the lock screen.

Total time: ~10 seconds. No app install. Works on every iPhone since iOS 6.

Google Wallet add-flow (Android)

The add-flow on Android has two paths depending on the SaaS implementation:

The good path (what well-built tools do):

Customer scans the counter QR with their Android camera or Chrome.
Phone opens the merchant's landing page.
Landing page UA-detects Android and 303-redirects directly to the Google Wallet save URL.
Google Wallet opens (or prompts to install if not present).
Customer taps Save.
Card is in their Google Wallet.

Total time: ~15 seconds if Google Wallet is already installed. ~60–90 seconds if it isn't and the customer has to install it first.

The bad path (what some legacy tools still do):

Customer scans the QR.
Lands on a generic web page.
Page tries to open Google Pay (the old payment app) first.
Customer's phone may or may not have Google Pay.
Customer ends up confused and abandons.

This bad path is the #1 customer-side friction cited in reviews of older standalone wallet-pass tools. It's the reason Android conversion rates are often half the Apple Wallet rates, even after controlling for wallet-installed rates. If you're picking a SaaS vendor, ask specifically how the Android add-flow works — and test it on an Android device that doesn't have Google Wallet pre-installed.

Merchant setup: what each wallet requires

Apple Wallet — merchant setup

For Apple Wallet, the SaaS vendor (or you, if building in-house) needs:

Apple Developer Program membership — $99/year, requires KYC verification that typically takes 1–4 weeks
Pass Type ID + signing certificate — generated in the Apple Developer Portal once the account is approved
A signed .pkpass file generated per customer per loyalty card

If you're using a SaaS, the vendor handles all of this — but the vendor's own KYC has to be approved first. This is why some SaaS tools say "Apple Wallet rolling out" — they're waiting on Apple's review of their developer account.

You as the merchant do not need your own Apple Developer account when using a SaaS vendor.

Google Wallet — merchant setup

For Google Wallet, the SaaS vendor needs:

A Google Cloud project with Google Wallet API enabled
A service account with permissions to issue passes
Issuer ID approved by Google (usually faster than Apple — days, not weeks)

You as the merchant do not need a Google Cloud project when using a SaaS vendor.

The asymmetry: Apple's KYC is slow but rare (1–4 weeks once per SaaS vendor), Google's onboarding is fast but additional fields are sometimes requested mid-process. Net practical result: any SaaS that's been in the market for >6 months has both done. Newer SaaS tools may have shipped Google Wallet first and Apple Wallet "rolling out" — Stampo is an example of this in mid-2026.

Push notifications: limits, deliverability, and merchant control

Both wallets support push notifications tied to the pass itself — that is, you can update the pass content and the user gets a lock-screen notification on their phone.

Apple Wallet push notifications

Sent via Apple Push Notification service (APNs), which is the same backbone that delivers all iOS notifications
High deliverability, low complaint rate
Notifications are tied to a pass update — you change the stamp count, the customer's lock screen shows a notification
Apple is strict about misuse: spammy notifications get the merchant's certificate rate-limited
Customers can disable notifications per pass without uninstalling the pass

Google Wallet push notifications

Sent via Google's push infrastructure (FCM-derived)
Similar mechanics: tied to pass updates
Slightly less restrictive on misuse, but Google Wallet's UI is less notification-prominent than Apple Wallet's
Geofence-based notifications are supported on both wallets, but require additional setup and merchant location data

For a loyalty program, the killer use case is the "haven't seen you in three weeks" nudge — both wallets support this natively when you update the pass, no separate marketing tool needed. Most merchants don't need a paid email module on top of wallet notifications.

Visual polish and customer experience

Honest assessment:

Apple Wallet has had eight more years of design polish than Google Wallet. Passes look better, the lock-screen integration is more prominent, the haptic feedback on add is satisfying. iPhone users who use Apple Wallet for boarding passes treat loyalty cards as a natural extension of the same surface.
Google Wallet is solid but visibly newer. The pass surface is functional. Lock-screen prominence is lower. The brand isn't as established as a "wallet" in the way Apple Wallet is.

For a design-led café or a premium retail brand, this difference is worth ~$0 in real revenue terms but matters for brand consistency. Pick the SaaS that supports both, ship both, don't obsess over the differential polish.

Which one to launch with first

A decision matrix by merchant shape:

Your shape	Launch first
iPhone-skewed customer base (US, UK, design-led café, premium retail)	Apple Wallet, then Google Wallet within 2 weeks
Android-skewed customer base (mass-market retail, lower price point)	Google Wallet, then Apple Wallet when SaaS ships it
Mixed customer base, single launch only	Whichever your SaaS supports today, ship the other when ready
Pre-launch and not sure yet	Both simultaneously through a SaaS that ships both
Already on Stampo today (June 2026)	Google Wallet is live, Apple Wallet rolling out post-KYC

The general rule: don't wait for both to launch a loyalty program. A counter QR that adds a card to Google Wallet for Android users and shows a "coming soon" message for iPhone users is still better than no counter QR at all. You can always send a "your loyalty card is now in Apple Wallet — re-add here" nudge to existing customers when the second wallet ships.

What this means for your SaaS choice

When picking a digital loyalty card vendor, ask:

Do you ship both Apple Wallet and Google Wallet today? "Rolling out" is honest if the SaaS is < 6 months in market. "Rolling out" for 18 months is a red flag.
What's the Android add-flow? Direct save URL = good. Routing through Google Pay install = bad. Ask for a demo on an actual Android device.
What's your push notification policy? Some vendors throttle aggressively. Some don't. For a loyalty program with monthly "haven't seen you" nudges, you want enough headroom for ~12 push messages per customer per year.
Can I customise the pass design fully? Some vendors lock down logo / colour / hero image at lower tiers. Stampo, Loopy, and Magic Stamp all ship full customisation at entry tier.
What happens to the card if I cancel the subscription? Cards should keep working for existing customers but stop being updateable. Some vendors deactivate passes entirely — make sure you know which.

Why we built Stampo to ship both

We're shipping Google Wallet first and Apple Wallet rolling out because Apple's developer KYC is the longest single-vendor approval step in this category. We didn't want to delay the entire product launch on Apple's review window.

The trade-off: merchants who launch on Stampo today have Google Wallet live and Apple Wallet queued. For a single-location indie café in Bangkok or Berlin, this is fine — start with Android customers, add iPhone customers in week 4 when the Apple Wallet ships. For a US-based premium café where 75% of customers are iPhone, this is harder — wait for Apple Wallet to ship before launching, or run a smaller pilot on the Android side first.

Our Android funnel uses the direct Google Wallet save URL (the good path described above), not the legacy Google Pay routing — which is the #1 counter-friction we observed in competitor reviews.

If you want to test the Stampo Google Wallet flow today, open a 14-day trial, no card on file. Apple Wallet ships in 4–6 weeks.

FAQ

Should I use Apple Wallet or Google Wallet for my loyalty program?

If your customer base is mixed (most are), you should support both. If you can only support one, pick the wallet that matches your customer base's phone skew — Apple Wallet for iPhone-heavy markets, Google Wallet for Android-heavy markets.

Does Apple Wallet work on Android?

No. Apple Wallet is iOS-only. The equivalent for Android is Google Wallet. A proper SaaS vendor will ship both — and the loyalty card itself lives on each customer's phone in whichever wallet they use.

Is Google Wallet pre-installed on Android phones?

Mostly yes, but not universally. Recent Android devices ship with Google Wallet pre-installed; older devices may need to install it from the Play Store. The Android add-flow needs to handle both cases gracefully.

Can a customer add the same loyalty card to both wallets?

Practically no — the customer has one phone, on one OS, with one wallet. The pass file format differs between Apple (.pkpass) and Google (Google Pay API JSON), and the customer add-flow goes through one or the other based on the device's OS.

How much does Apple Wallet integration cost the merchant?

Nothing directly, when you use a SaaS vendor. The vendor pays the $99/year Apple Developer fee for their issuer certificate. You as the merchant pay the SaaS subscription only.

How do wallet notifications work for loyalty?

Both Apple Wallet and Google Wallet send a lock-screen notification when the pass content changes — for example, when a stamp is added or a reward is unlocked. Most loyalty SaaS tools also support a "manual push" feature for sending marketing nudges to inactive customers.

Does Stampo support Apple Wallet?

Google Wallet is live as of June 2026. Apple Wallet is rolling out post-Apple-Developer KYC, expected in 4–6 weeks. The Google Wallet flow uses the direct save URL (skipping the Google Pay install step that confuses customers on competing tools).

If you want a hands-on tour of how a counter QR add-flow looks in practice, open a Stampo trial — the Google Wallet flow is live today and the Apple Wallet flow ships soon. Or if you want the full picture of digital loyalty for your business, start with the worth-it pillar.

Information accurate as of June 2026. Apple and Google wallet APIs are updated regularly — verify current capabilities with each vendor's developer documentation before building in-house.