What a wallet pass actually is, in plain English

A wallet pass is a signed file, not an app

A wallet pass is a small bundle of text and images, signed by whoever issued it, stored locally on your phone inside Apple Wallet or Google Wallet. It is not an app and it does not run code. Treat it as a signed document your phone knows how to display, refresh, and put on the lock screen at the right moment.

The two platforms build the same idea differently. Apple's version is a real file: a ZIP archive with the extension .pkpass and the MIME type application/vnd.apple.pkpass. Google's version is a record held on Google's servers that syncs down into the Google Wallet app.

Boarding passes, cinema tickets, gym memberships, and coffee-shop loyalty cards are all this one format underneath. Once you understand the file, every behavior follows from it, including the limits. The limits are the part most people get wrong.

What is actually inside a .pkpass

Rename a .pkpass to .zip and unzip it. You get pass.json, a handful of PNG images (an icon, a logo, and usually a strip or background image supplied at 1x, 2x, and 3x scale), a manifest.json, and a file called signature. That is the entire pass, and it is usually tens to a few hundred kilobytes.

pass.json is the data. It holds formatVersion, a passTypeIdentifier that Apple issues to the business, a serialNumber unique to that one card, the barcode definition, and the visible values grouped into header, primary, secondary, auxiliary, and back fields. Colors and label text sit in the same file. Space on the front is tight, so a store card shows a handful of short values and anything long belongs on the back.

manifest.json is a list of SHA-1 hashes, one per file in the bundle. signature is a detached PKCS#7 signature over that manifest, produced with a Pass Type ID certificate issued by Apple and chained to Apple's WWDR intermediate certificate. Change one pixel of one image and the hash stops matching, so the pass stops verifying. That is why a customer cannot edit their own stamp count.

Google Wallet approaches it from the other end. The issuer defines a class (the template for the whole program) and an object (one customer's card), then hands the phone a save link carrying a JWT signed with the issuer's service-account key and redeemed at pay.google.com. The card data lives in Google's API rather than in a file the customer downloads.

What a wallet pass can do

It renders with no network. The data and images are already on the device, so the card opens in airplane mode, in a basement parking garage, and on the 200th scan of a busy Friday night. The barcode reads the same in all three cases.

It can appear on the lock screen without sending a notification. A pass can carry a relevant date and a list of coordinates with a maximum distance. When the phone is near one of those coordinates, or the time is close, the pass surfaces by itself. Waya uses exactly this for branch-proximity reminders, configured per branch.

It updates itself. An Apple pass includes a web service URL and an authentication token; the device registers with that service and receives a silent push over APNs when something changes. The push carries no content, so the phone then fetches the new pass.json from the issuer. If a field is flagged with a change message, the customer sees a lock-screen line such as "3 stamps to go".

It stays under the customer's control. Adding a pass is always a deliberate tap, and removing one takes about two taps. Nothing installs quietly, and nothing lingers after the customer decides they are done.

What a wallet pass cannot do

It cannot run code. There is no runtime inside a pass, so no JavaScript, no forms, no navigation, and no custom screens. You get a fixed layout with slots you fill in. If you need buttons and flows, you need a web page or an app instead.

It cannot reach into the phone. A pass has no access to contacts, the camera, the photo library, or location history. Lock-screen relevance is computed by the operating system against coordinates baked into the pass, so the issuer never learns where the customer is.

It gives you almost no analytics. You can tell that a pass was created and, on Apple, that a device registered for updates. There is no reliable "the customer opened the card" event and no per-view tracking, which is why serious loyalty reporting has to come from scans at the counter rather than from the pass itself.

It is not a broadcast channel. Apple shows a notification only when a value you flagged actually changes, so the change is the message. You cannot fire arbitrary marketing blasts through the pass layer, and any messaging quota your vendor sells you is a limit on those update events.

How a pass differs from an app, a web page, and a payment card

An app is a signed binary that runs code, ships through App Store review, needs updating, and must ask permission before it can notify anyone. A pass is a data file the operating system already knows how to draw. Nothing gets reviewed, nothing installs from a store, and there is no password. That single difference is why loyalty programs moved to passes: the install step becomes one tap inside a sheet the customer already trusts.

A web page needs a network round-trip every time it opens, lives in a browser tab that gets closed and forgotten, and cannot place itself on the lock screen. A pass is the mirror image: offline by default, permanent until removed, and able to surface without being opened. The trade-off is interactivity, because a web page can take input and a pass cannot.

A wallet pass is not a payment instrument. It carries no card number, no EMV chip data, and no payment credential, and it cannot move money. Apple Pay is a separate subsystem that happens to live in the same app, so a pass sits beside it, not inside it. Some pass types can carry NFC for door access or transit under a specific entitlement, never for payments.

The short version: an app runs, a web page loads, and a pass simply sits there and stays correct.

What the format means if you issue loyalty cards

The format shapes your customer experience more than your card design does. Because a pass installs in one tap and needs no account, enrollment can be a QR code on the counter plus a one-screen form. On Waya that form asks for a first name and a mobile number, and then the customer taps once to add the card to Apple Wallet or Google Wallet. Any other device or browser gets a web card instead.

The honest limits are worth stating early, because they are mostly the format's limits. Waya does not integrate with your point-of-sale system and needs no hardware: staff scan the customer's card on an ordinary phone, so Waya sits beside whatever till you already run. There is no SMS anywhere in the product, since messages arrive as wallet updates on the lock screen.

Pricing follows the same shape. The free plan is 0 SAR forever and covers up to 100 customers, 100 wallet messages a month, 1 stamp card, and 1 branch, with a hard stop at those numbers; customers already enrolled keep their cards and keep collecting. Growth is 85 SAR a month and Premium is 149 SAR a month, and the metered resource on paid plans is wallet messages rather than customers.

For scale, the figures published on our Arabic homepage are 100+ shops across Saudi Arabia, 5,000+ customer cards living in wallets, and an average of 4.9 out of 5 rated by 90 merchants. None of that is a property of the pass format itself. It is just evidence that a file which installs in one tap clears a bar that a downloadable app rarely does.