You have probably experienced it without knowing what to call it. You arrive at the airport, glance at your phone, and the boarding pass is already sitting on the lock screen — you never opened Wallet, never searched for it, never tapped anything. The phone worked out that you were at the right place and put the right card in front of you.
That behaviour is called pass relevance, and it is not reserved for airlines. Any wallet pass — a loyalty card, a stamp card, a membership, an event ticket — can carry the coordinates of your shop and surface itself when the customer walks near. This is what people mean when they search for "Apple Wallet geofencing", and it is one of the most misunderstood features in the whole wallet ecosystem. Here is what it actually does, what Apple and Google actually allow, and the limits that nobody puts in the sales deck.
Geofencing on a Wallet Pass Is a Suggestion, Not a Message
The single most useful thing to understand: location relevance and push notifications are two completely different mechanisms, and businesses constantly confuse them.
A push is something you send. You change the pass on your server, the wallet fetches the update, and a line of text you wrote appears on the customer's lock screen. You choose the moment and the words. We covered that channel in detail in our guide to wallet push notifications.
Location relevance is something the phone does on its own. You bake a list of coordinates into the pass when you issue it. From then on, the device — not your server — decides when the customer is near one of those places and surfaces the pass. No request leaves the phone, no message is sent, and you never learn that it happened. It is the difference between calling someone and leaving a business card in the doorway they walk through.
That distinction matters because it sets expectations. Geofencing does not let you say something new. It puts a card the customer already chose to keep exactly one glance away at the moment they are standing outside your door.
The Keys That Make an Apple Wallet Pass Location-Aware
In the pass file itself (the pass.json inside a .pkpass bundle), four keys do the work.
locations — an array of up to ten objects, each holding a latitude, a longitude, and optionally an altitude. Ten is a hard ceiling in Apple's specification: one pass can be relevant at ten places, not eleven.
relevantText — the line shown on the lock screen when the pass surfaces. It sits on each location entry, so different branches can say different things. Apple's own documentation gives the example "Store nearby on 1st and Main", which tells you the intended register: a helpful orientation, not a slogan.
maxDistance — the maximum distance in metres from a location at which the pass is considered relevant. The important nuance is in Apple's wording: the system uses the smaller of your value and its own default distance. You can tighten the radius, never widen it. Set 50 metres for a kiosk inside a mall and you get 50 metres; set 5,000 metres hoping to blanket a city and you get whatever Apple's default is.
beacons — an array of Bluetooth Low Energy beacon identities (a proximity UUID with optional major and minor values), each with its own relevantText. Beacons solve what GPS cannot: floor-level precision indoors, a specific counter inside a mall, or a stand at an exhibition. They cost hardware and installation, which is why most businesses start with coordinates.
There is a time-based sibling worth knowing while you are in the file: relevantDates, an array of date intervals that make a pass surface at the right moment rather than the right place. (The older single relevantDate key is deprecated in favour of it.) Location and time together are what make an event ticket appear on the lock screen the evening of the show at the venue — and the same pairing works for a Friday brunch offer or a class pack.
Google Wallet: The Field Most Guides Still Recommend Is Deprecated
This is where a lot of published advice — and a lot of AI-generated summaries — is quietly out of date.
Google Wallet classes used to carry a locations array of LatLongPoint objects. That field is now marked deprecated in Google's own API reference, with an explicit note that it is not supported for triggering geo notifications. Passes built against it will validate and do nothing.
The current field is merchantLocations: a maximum of ten per class, and anything beyond ten is rejected. Google's documentation states these locations trigger a notification when a user enters within a Google-set radius of the point — note "Google-set": on Android you do not control the radius at all, where Apple at least lets you tighten it.
So the two platforms rhyme without matching. Both cap you at ten places per pass. Apple surfaces the pass on the lock screen and gives you a line of text plus optional beacons and a radius you can narrow. Google fires its own notification inside a radius it decides. If you run both wallets — and you should, because your customers are split between them — you build the same list twice and accept that the behaviour differs. Our Apple Wallet vs Google Wallet comparison covers the other places the two diverge.
Four Limits Worth Knowing Before You Promise Anything
Ten locations, full stop. A café with three branches is comfortable. A retailer with forty is not. The workarounds are real but they cost something: issue branch-specific passes so each customer's card carries only the ten places near them, or use beacons at the sites that matter most, or accept coverage of your top ten.
It fires on the phone's terms, not yours. Wallet relevance rides on the operating system's own low-power location machinery, which is designed to protect battery rather than to be instant. Treat it as "sometime around arrival", never as a trigger you can time to the second.
The customer's settings decide. If location services or lock-screen suggestions are switched off for the wallet, the pass simply stays where it is. There is nothing to appeal to and nothing to configure from your side.
You get no analytics. Nothing is reported back — no impressions, no "surfaced 412 times this week". This is the honest trade for the thing that makes wallet geofencing palatable in the first place: the customer's location never leaves their device, so there is no data for you to see, and no privacy conversation to have. Compared with geofencing advertising, which buys location data about strangers, this is a very different product with a very similar name.
How to Actually Use It
Because the mechanism is a nudge rather than a broadcast, the craft is entirely in the coordinates you pick and the sentence you attach.
Fence what is useful, not just what you own. Your own doorway is the obvious pin. The car park, the metro exit, the mall entrance two floors below and the office tower across the road are often better ones, because they catch the customer while the decision is still open.
Write relevantText as a reminder, not an ad. "Your card — 8 of 10 stamps" beats "50% OFF TODAY ONLY". The customer is looking at their own lock screen; the tone that survives there is the tone of their own belongings.
Give each branch its own line. Because relevantText sits on the location, the Marina branch can say something the Downtown branch does not — opening hours, parking, the fact that this one has the drive-through.
Pair it with a push, do not replace one with the other. Relevance decides where the card appears; a pass update decides what it says. A quiet-Tuesday offer pushed at 2pm, resting on a card that resurfaces every time the customer walks past, is the combination that actually moves footfall.
Wally issues loyalty, stamp, membership, and ticket passes to Apple Wallet and Google Wallet with the location keys, beacons, and push updates handled for you — including the branch-by-branch text. If you want to see it running on your own storefront coordinates, see how wallet geofencing works with Wally or book a short demo.