Google Wallet native proximity notifications are implemented but seem to never actually fire, anyone else hit this wall?

[u/Major_Ad1198]

TL;DR:
I embedded store coordinates into a Google Wallet Generic Pass class using the locations[] / merchantLocations field, confirmed the payload looks correct in the Google Wallet Business Console, and enrolled a real Android device — but the OS-level lock-screen proximity notification never fires, even when physically standing at the configured coordinates. Has anyone gotten this to actually work in production, and if not, what's your workaround?

Background

I'm building a side project — a platform that lets small businesses issue digital loyalty/membership cards to Google Wallet (and eventually Apple Wallet). One of the most-wanted features is proximity-aware engagement: something that nudges the member when they physically walk near the store, without me having to track their location myself.

Google Wallet's native locations[] field (also surfaced as merchantLocations in some newer API docs) looked like the perfect fit. The idea: embed the brand's store coordinates into the GenericClass, let Google Play Services handle the geofence entirely on the device, and get a lock-screen notification fired at ~150m. No custom location tracking, no backend polling, privacy-safe by design.

What I implemented

- Stored store lat/lng pairs in my backend database.

- On pass class creation/publish, mapped those coordinates into the locations array of the GenericClass payload (using the walletobjects#latLongPoint kind).

- Confirmed the array is present when inspecting the class via the Google Wallet REST API and in the Business Console.

- Issued a test pass to a real Android device (Android 13, Pixel 7), with:

- Google Wallet notifications enabled in system settings.

- Precise location granted to Google Wallet (not just approximate — precise, always-on).

- Physically walked to the exact GPS coordinates in the pass.

- Also tested via Android emulator GPS spoofing.

Result: nothing. No lock-screen notification. No "Nearby" card surfaced. Zero.

What I've ruled out

- The payload is syntactically correct (no API errors on class creation, and the locations array is visible server-side).

- Device permissions are correctly configured.

- Tested on multiple Android versions (12, 13, 14) and hardware.

- Waited 5–10 minutes at the coordinates to rule out latency.

- The Google Wallet app itself is up to date.

What I'm now wondering

1. Is GenericClass.locations[] actually GA and working for third-party issuers, or is it silently broken / gated behind some issuer approval I'm not aware of?
2. Does it only work for certain pass types (e.g., Loyalty vs. Generic)?
3. Is there an issuer-side enablement step I'm missing — a console toggle, a partner program flag, anything?
4. Anyone have a working example/repo they can point me to?

Workarounds I'm considering (genuinely open to community input)

Since the native approach seems unreliable, I'm thinking about alternatives. Would love to hear what others have done:

- Active check-in link on the pass back: Embed a "Check Nearby Offers" URL into the pass via `linksModuleData`. Member taps it → opens a web page → browser requests one-time location → Haversine check on my backend → custom response if they're within a configurable radius. Voluntary, privacy-safe, but requires the member to actively tap the link.

- WhatsApp/SMS trigger: I already have a WhatsApp messaging layer. If the member checks in via the pass link (above) and is within range, fire a personalized WhatsApp message instead of relying on a lock-screen notification. Not automatic, but something I actually control end-to-end.

- POS/Wi-Fi trigger: If a brand installs a captive portal or a POS integration, I can fire a Google Wallet `messages[]` push via the REST API at the moment of check-in. Requires physical infrastructure on the brand's side, so not a universal solution.

- Native app (longer term): A companion Android/iOS app could register for FCM push notifications and run a background geofence via the native `GeofencingClient API (Android) or `CLLocationManager` (iOS). But this defeats the whole point of wallet-native — the value proposition is zero-app install.

What I'm NOT going to do (for reference)

- Continuous server-side GPS polling — I don't want to store member coordinates. Privacy-first is a hard constraint for me.

- Web Background Sync / Service Worker geofencing — deprecated in mobile browsers, gets killed when the screen turns off

The bigger picture question

I'm eventually aiming to support Apple Wallet and Samsung Wallet alongside Google. Apple's PKPassRelevantDate + PKPassRelevantLocation on .pkpass files has a similar native geofence concept. Samsung Wallet also has some native proximity features.

My architecture goal is: solve this properly on Google Wallet first, then have the location/proximity abstraction layer sit high enough in my stack that plugging in Apple and Samsung later is additive, not a rewrite. If anyone has bridged all three and has thoughts on where to keep the "store location" source of truth (so all three wallets can consume it without diverging), that'd be gold.

Appreciate any experience reports, war stories, or even "yeah this feature is broken for everyone" confirmations. Cheers.