Lock-screen notifications from a wallet pass: what is actually possible

A wallet notification is the OS telling your customer their card changed

A wallet pass can put one line of your text on a customer's lock screen. You control that line. You don't control the header above it, and the customer can switch the whole thing off in two taps without telling you. Everything else in this article follows from those three facts.

There's no app of yours involved anywhere in the chain. On iPhone, the server sends a silent background push to the device, the device fetches the updated pass, and the Wallet app decides whether the change deserves a banner. On Android, the server appends a message to the pass object through the Google Wallet API and the Google Wallet app surfaces it. Different plumbing, same shape: the operating system is the sender and you're only the source.

None of this touches SMS. No carrier, no phone number handed to a messaging vendor, no per-message fee to an aggregator. That's genuinely useful, and it's also exactly why the reach ceiling is lower than SMS. We'll get to that trade-off at the end, because it's the part most vendors skip.

The text you control, and the text iOS writes for you

On Waya a message has two parts: a title of 1 to 80 characters and a body of 1 to 240 characters. Those are hard limits enforced by the send endpoint, not soft guidance. Copy that runs long gets rejected outright rather than silently trimmed, which is the behavior you want when you're writing something 200 people will read.

On iPhone, the body is what lands on the lock screen. The header above it is the pass's organization name, baked into the pass file itself, because iOS writes that line and you can't override it per message. Your title becomes the label on the back of the card, visible when the customer taps the pass open. Merchants who assume the title is the bold line on the lock screen get surprised exactly once.

On Google Wallet, the title and the body both travel as a message attached to the pass, and the Google Wallet app renders them together. So the same send reads slightly differently on the two platforms. Write the body so it stands on its own and you never have to think about which phone the customer is carrying.

What you get is plain text. No images, no buttons, no reply field, no custom sound. Tapping the banner opens the pass, and that's the only action available. Waya substitutes four variables before sending, {customer_name}, {stamps_left}, {reward}, and {shop_name}, so "2 stamps to go, Sara" is one template instead of 80 hand-typed messages. Emoji render fine and count against the character budget.

What happens when a customer mutes the pass

Any iPhone user can open a pass in Wallet, go to the details view, and turn off notifications for that single card. From that moment they get no banners from it. There's no override, no appeal, and no signal back to you. Google Wallet has the equivalent: per-pass notification settings inside the app, plus the OS-level notification permission for the Wallet app as a whole.

Here's the part worth understanding. The pass keeps updating. The silent push still arrives, the device still fetches the new file, and the stamp count is still correct the next time the customer opens the card. Muting stops the banner, not the data. Someone who mutes you hasn't left, they've just stopped being reachable on the lock screen.

This changes how you should read delivery numbers, including ours. When Waya's dashboard marks a message delivered, it means Apple's push service accepted the push or Google accepted the message. It does not mean a human saw a banner. Treat "delivered" as "handed off correctly" and nothing more.

The one genuinely hard signal is removal. When a customer deletes the pass, the device token goes dead, Apple returns a 410, we stop targeting that device, and a nightly cleanup drops the registration. So your reachable-cardholder count is honest about deletions and blind to mutes. Plan around the blind spot rather than pretending it isn't there.

Realistic frequency, and the limits that already bind

Start with the limits that aren't up to you. Waya blocks an immediate broadcast while your shop is closed and defers a scheduled one to the next open window, using the business hours and timezone on your store record. A 1 a.m. loyalty banner is the fastest route to a muted pass. Geofenced proximity reminders fire at most once every 4 hours while a customer is inside the radius, and that radius runs from 50 to 500 meters, 150 meters by default, around up to 10 branch coordinates carried in the pass.

Then the volume limit. On Waya the paywalled unit is messages, not customers. Free gives you 100 wallet messages a month at 0 SAR, forever. Growth is 85 SAR a month for 5,000. Premium is 149 SAR a month with messages uncapped. A broadcast costs one message per targeted cardholder, counted the moment you press send, so a send to 80 cardholders spends 80 messages whether or not all 80 phones light up.

Worked example, assumptions written out. Say you have 240 cardholders on the Growth plan. Two deliberate broadcasts a month is 480 messages. Add automatic event triggers and assume your 240 customers average 1.5 visits a month, which is another 360 or so confirmations. That's roughly 900 of your 5,000. Volume is almost never the binding constraint.

Tolerance is. The pattern that holds up is to let event triggers carry the everyday contact and keep deliberate broadcasts to two to four a month. Event messages are welcome because the customer just did something. Broadcasts are interruptions, and interruptions have a budget you can't see on any dashboard.

The moments that earn a notification

Waya ships four automatic triggers, and they map to moments where the customer's attention is already on you: a stamp was added, a reward was redeemed, a card was just created, and 14 days have passed with no visit. The first three are confirmations. Only the fourth is marketing. That ratio is deliberate.

Confirmations are what build the habit. "3 stamps to go" arriving right after the cashier scans the card tells the customer the system is real and the count is right. That does more for repeat visits than a discount blast, because it removes doubt instead of adding pressure. It also costs you nothing in goodwill, which broadcasts always do.

The 14-day nudge is the one to write carefully. It arrives unprompted, to someone who has already drifted, competing with everything else on that lock screen. One specific reason to come back beats a generic "we miss you". Write it the way you'd greet a regular you hadn't seen in two weeks, and keep it inside 240 characters.

The geofenced branch reminder works differently from all of these. Nothing is sent. The pass carries your branch coordinates, the phone notices proximity on its own, and the OS shows your line. That means it costs nothing from your monthly message quota, and it also means it only works when the customer's location permissions allow it, which you can't verify. The geofence and the automatic triggers sit on the paid plans; Free covers the manual sends.

Why this isn't an SMS replacement

Wallet notifications reach exactly one group: customers who added the pass and left notifications on. Not the person who scanned your QR code, filled in the one-screen form, and never tapped Add. Not the one whose browser loaded the web card fallback instead of a real pass. Not anyone whose number is sitting in a spreadsheet you imported.

There's no two-way channel either. The customer can't reply. There's no read receipt at the human level, no way to confirm a banner was actually seen, and no way to reach someone who muted you. SMS gives up privacy and costs money per message, and in exchange it reaches nearly anyone with a working number. Wallet passes make the opposite trade.

So the honest positioning is narrow: wallet notifications are the cheapest way to talk to your best customers, and they can't talk to anyone else. Waya sends no SMS at all and never hands a customer's mobile number to a third-party messaging app. If your plan depends on reaching every customer you've ever served, you need a channel we don't provide, and you should know that before you sign up rather than after.