Wallet pass privacy: what the shop can and cannot see

A wallet pass is a file, not an app

A loyalty pass in Apple Wallet is a .pkpass bundle: a ZIP of JSON and PNG images, cryptographically signed by the issuer's certificate. There is no code inside it, no runtime, and no permission it can request. Everything a shop learns about a customer comes from two places only: the form the customer filled in at enrollment, and the scans the shop's own staff performed.

Open one up and you find a short list of things. Display fields (the name, the stamp count, the reward wording), foreground and background colors, the logo, the barcode payload, a web service URL for updates, an authentication token, and optionally a set of branch coordinates with a radius. Apple Wallet renders that data. Nothing in it executes.

The contrast with an app is the whole story. An app can ask for your contacts, your photo library, background location, and the advertising identifier. A pass can ask for nothing, because there is no process to run and no API for it to call. This is why customers who add a Waya card are never shown a permission prompt: they tap Add in Apple Wallet or Save in Google Wallet, and that is the end of the interaction.

Why your loyalty card cannot read the customer's bank card

The wallet is not a shared folder that every pass can browse. Each Apple Wallet pass belongs to exactly one pass type identifier, which is tied to one certificate held by one issuer. That identifier is the boundary, and it is enforced by the operating system rather than by policy.

Reading a pass programmatically requires an iOS app carrying an entitlement for that specific pass type. Waya ships no consumer app at all — customers install nothing — so there is no code of ours on the customer's phone, no wallet entitlement, and no way to enumerate what else is in there. Google Wallet draws the line in the same place at the API level: loyalty objects live under an issuer ID, and the API only returns objects under yours.

So a barber's stamp card, a boarding pass, and a bank card can sit three rows apart in the same wallet with no channel between them. If a loyalty vendor ever suggests their pass gives you visibility into a customer's other cards or their spending elsewhere, that is not how PassKit or the Google Wallet API work. Ask them to show you the API call.

Serial numbers and auth tokens: only one of them is a secret

Two identifiers do the real work, and people routinely mix them up. The serial number names one pass to its issuer, and it is the string encoded in the QR code your cashier scans. The authentication token is that pass's password for pulling its own updates. Confusing the two is how loyalty systems get abused.

How an update actually reaches the lock screen

When a customer adds a pass, iOS registers that device with the pass's web service URL and hands over an APNs push token. Nothing about the customer travels in that handshake: the device sends an opaque identifier scoped to this pass type, and the server stores it against the serial.

When a stamp is added, the server sends an empty background push. There is genuinely no text in it. The device wakes, comes back for the refreshed pass with an Authorization: ApplePass header carrying its token, and the sentence the customer reads on the lock screen comes from a change message field on the new pass. The push channel never carries the message. On Google Wallet the plumbing differs — the object is patched through Google's API and Google handles delivery — but the shape is the same: the issuer touches its own objects and nothing else.

Here is the part most vendors leave out. On Waya, the auth token is 64 random hex characters, kept in the database only as a peppered hash, with the plaintext existing solely inside the pass on the device; re-issuing a pass rotates it. Serial numbers are a weaker design: ours are built from the program ID, the enrolling mobile number, and a timestamp, so a serial should be treated as an identifier and not as a secret. Practically, that means don't post a photo of a customer's card QR publicly, the same way you wouldn't post a receipt with a phone number on it.

Knowing a serial still buys an attacker nothing useful. Every write — add a stamp, spend points, redeem a reward — goes through a signed-in staff account belonging to the shop that owns that program. A scan by itself is a lookup, not a transaction.

Proximity reminders don't send anyone's location to a server

The feature people assume is surveillance is the passive branch reminder, and it is the opposite. Branch coordinates are written into the pass file itself, along with a radius that defaults to 150 meters on Waya. That data flows outward to the phone, once, at issue time.

iOS then compares the phone's position to those coordinates on the device and surfaces a lock-screen suggestion when they match. The phone reports nothing back. There is no coordinate stream arriving at our servers, which means neither the shop nor Waya can reconstruct where a customer was on Tuesday afternoon. That property comes from the platform design, not from a promise in a policy document.

Two honest limits. The geofence only exists if the merchant switched the branch-proximity toggle on and saved real coordinates on the Branches screen — a card's own Address and Maps fields are display text and do nothing here. And it is a suggestion from the operating system, not a guaranteed delivery: Apple decides whether to show it, based on signals you don't control.

What the server stores, and what it never sees

The record behind a Waya card is short. First name, mobile number, which program and which branch, the current stamp, point, or balance value, and a timestamped list of scans and redemptions. Then, per device that added the pass, the device identifier and push token described above. None of those is the phone number, the Apple ID, or an advertising identifier.

What is absent matters more. No card numbers or payment data, because Waya has no POS integration and never sits in the payment path — it runs beside your till, not inside it. No SMS logs, because Waya doesn't send SMS; updates ride the wallet itself, so no customer's number is handed to a third-party messaging app. No customer email or password, because enrollment creates no account. No contact list, no location history, no browsing data.

Deletion works in both directions. When a customer deletes the pass, iOS calls the web service and unregisters that device, so updates stop arriving. The shop's own visit history stays in its dashboard until the shop removes it, and a merchant deleting a customer's pass also clears that pass's device registrations. The written terms for all of this live on our /privacy and /dpa pages; we describe what the system does and don't claim any regulatory certification.

What a merchant should refuse to collect

The enrollment form is configurable, which is exactly the risk. Waya's default is two fields: first name and mobile number. Optional toggles exist for gender (including a prefer-not-to-say option), birthday, and custom questions. Most shops that switch all of them on never use the answers.

Use one rule. Add a field only when it changes something you will actually do this quarter. A birthday earns its place if you send a birthday reward. Gender earns its place if your stock genuinely splits and you message the two groups differently. A field that only feeds a report nobody opens costs you enrollments at the counter and leaves you holding data you now have to protect.

Refuse these outright: national ID or Iqama number, full home address, employer or income, car plate, a photo of the customer, and a second contact channel you have no plan to use. Also refuse the informal copy — the customer list exported to a spreadsheet and dropped into a staff WhatsApp group, or living on a former employee's personal phone. In small businesses that is almost always where a leak actually starts, not in the platform.

Three questions before you print the QR code. Would I be comfortable if this field showed up in a screenshot? Do I know the specific message that uses it? Can my cashier explain in one sentence why we ask? If any answer is no, delete the field. You can test the whole thing on yourself for nothing: the free tier covers up to 100 customers and 100 wallet messages a month with no credit card, so add your own shop's card to your own phone and try to discover anything about yourself you didn't type in.