QR codes and Apple Wallet / Google Wallet: how loyalty cards, tickets, and coupons actually work

QR codes and Apple Wallet / Google Wallet: how loyalty cards, tickets, and coupons actually work

Type "QR code Apple Wallet" into Google and most of what comes back is either a thin marketer how-to that skips the mechanism entirely, or an engineer's developer-docs page that assumes you already know what a signing certificate is. Neither answers the question an agency actually has: a client wants a loyalty card, a ticket, or a coupon that customers can save to their phone with a single scan, and they want to know what that scan is really doing.

The short answer is that the QR code and the wallet pass are two different objects that only look connected. A QR code is a static image. A wallet pass is a small signed software bundle (on iOS) or a cloud-hosted record (on Android) that the phone's operating system treats as a first-class object, complete with a home-screen icon, a lock-screen entry, and its own update channel. The QR code's only job is to point the phone at that bundle or record for one moment, at save time. After that, the pass and the code live separate lives.

Why you can't just "add" a QR code image to Apple Wallet

This is the part almost every marketing guide glosses over. You cannot drag a QR code PNG into Apple Wallet the way you'd add a photo to your camera roll. Apple Wallet does not accept arbitrary images at all.

What it accepts is a .pkpass file: a signed zip archive containing a pass.json manifest, an icon, and any images the pass uses. Inside pass.json, under a barcodes key, you declare which barcode format the pass should display and what data it encodes. Apple's own schema documentation spells this out: the barcode is a data dictionary inside the signed pass, not an image file dropped into a folder. The whole bundle is cryptographically signed with a certificate tied to your Apple Developer account, and Wallet will refuse to install anything whose signature doesn't check out.

So the actual flow for "add a QR code to Apple Wallet" is: generate a .pkpass file server-side, embed the barcode declaration inside its pass.json, sign the bundle, and serve it to the phone (usually behind an "Add to Apple Wallet" button, or a link that the phone recognises by MIME type and hands to Wallet automatically). A bare QR code scanned in a QR scanner app has nowhere to go in that pipeline. There is no "import barcode" button in Wallet because Wallet was never designed to take one.

This is also why so many agencies end up building the wrong thing: a QR code that, when scanned, opens a page showing another QR code is not a wallet pass. It still requires the customer to rescan something at the till, which defeats the point of saving a pass in the first place.

What barcode formats Apple Wallet actually supports

Once a barcode is correctly declared inside a signed pass, Apple Wallet supports exactly four formats on iOS 9 and later, per Apple's PKBarcodeFormat documentation:

• PKBarcodeFormatQR - a standard QR code, the most flexible of the four and the one most retail scanners can read without extra hardware.
• PKBarcodeFormatPDF417 - the stacked linear format used on boarding passes and some ID documents, chosen because it holds more data in a wide, short shape that fits a ticket stub.
• PKBarcodeFormatAztec - compact and historically favoured by transit systems and some airlines for high-speed gate scanning.
• PKBarcodeFormatCode128 - a traditional 1D barcode, useful when the checkout hardware is older POS equipment that only reads linear barcodes.

A pass can only carry one declared format at a time (with an optional legacy fallback for older iOS versions), so the choice matters. For a retail loyalty card or a coupon, QR is almost always the right call: it is what your staff's scanner already expects, and it is the one people will recognise as "a QR code" if they ever need to show it manually.

How Google Wallet's model is different

Google Wallet does not use signed file bundles at all. Instead, it works on a Class and Object model. The Class is a template you define once, for example "Acme Coffee Loyalty Card", with its layout, logo, and field structure. An Object is one issued instance of that Class, for example the loyalty card issued to a specific customer with their specific points balance.

To let someone add a pass, you generate a JWT (JSON Web Token) that references the Class and Object, sign it with a service-account key from your Google Wallet API Issuer account, and hand the customer a link in the form https://pay.google.com/gp/v/save/<signed_jwt>. Tapping that link, or scanning a QR code that encodes that link, tells Google Wallet's servers "here is a signed instruction to add this specific object to this user's wallet." Google's own JWT documentation covers the exact structure. Functionally this plays the same role as Apple's signed .pkpass, but the signing happens against a hosted API rather than a bundle you generate and serve yourself.

This distinction matters when scoping a project: an Apple integration means standing up a service that generates and signs files, while a Google integration means calling an API to create Class and Object records and generate signed save links on demand. Both need a signing key kept server-side, which is another reason a plain QR code generator can never produce a wallet pass on its own.

The one-code, two-platforms trick

Here is the part that actually matters for an agency briefing a client: you don't need two separate printed QR codes for iOS and Android users. The standard pattern is a single QR code that points at a short redirect URL your own server controls, the same setup you'd use for dynamic vs static QR codes on any other campaign. When the phone scans the code and hits that URL, your server reads the User-Agent header, detects iOS or Android, and issues the matching response: a .pkpass download for iPhone, or a redirect to the signed pay.google.com/gp/v/save/... link for Android.

Worth stating plainly: this is a widely used engineering pattern, not a formal Apple or Google spec. Neither company documents a joint "cross-platform wallet QR" standard, because from each platform's point of view the QR code is simply a QR code; the branching happens entirely on your server before either Wallet app gets involved. It's the same trick agencies already use to send one QR code to two app stores.

Because the branching logic lives on your server, this only works cleanly with a dynamic code, one whose target URL you can update without reprinting anything. A static code printed straight to a .pkpass file or a single save link is locked to one platform from the day it goes to print, and a customer on the wrong device just gets an error.

What actually updates: the pass, not the code

The part most explainer content skips is the one that makes wallet passes genuinely useful for an agency: after a customer saves a pass, its printed QR code never changes again. What changes is the content Apple's or Google's servers push into that already-saved pass.

On Google Wallet, updating a live pass, changing a loyalty points balance, marking a coupon as redeemed, expiring a ticket after the event, is done by writing to the Object's fields through the API, and the customer's saved pass refreshes automatically with no rescanning required. Expiry works the same way: Google's documentation on expired loyalty passes shows it set programmatically via object.validTimeInterval.end.date, or by moving the object to an Expired, Inactive, or Completed state. Apple Wallet updates work similarly, through a push-notification mechanism that tells the phone a pass has changed and to re-fetch its pass.json.

This is the real difference between a wallet pass and a QR code that just links to a web page, and it's the point worth making to a client comparing the two. Changing a destination without reprinting keeps the printed code the same while the page behind it changes. A wallet pass goes one step further and keeps the installed object on the customer's phone current too, including lock-screen and location-based surfacing, without the customer doing anything at all.

Where this earns its keep: loyalty, tickets, coupons, membership

The four practical use cases an agency will actually build are loyalty cards, event tickets, coupons, and membership cards, and each leans on a different part of the pass model. Loyalty cards get the most value from dynamic field updates, a points balance or tier that changes without the customer rescanning anything. Event tickets lean hardest on the barcode-format choice (PDF417 or Aztec for high-throughput gate scanning) and on location-based lock-screen surfacing near the venue. Coupons are the simplest pass type, a single barcode and an expiry date, but benefit most from a "mark as redeemed" server push once used, so a screenshotted code can't be reused. Membership cards typically combine a QR or barcode with a photo or name field for staff verification, closer to an ID card than a loyalty stamp.

Google publishes named partner results for its Wallet product, worth citing precisely because they're attributable rather than generic industry averages. According to Google's published Wallet case studies: PizzaExpress Hong Kong reported 5.5x membership growth and 25 per cent higher spend per transaction after moving loyalty onto Google Wallet; Xenos in the Netherlands saw an 80 per cent increase in loyalty registrations; Salomon reported a 3x revenue increase and 54 per cent more items per order; and Kiehl's reported a 65 per cent coupon redemption rate. Treat these as best-case examples from Google's own showcased partners, not an average any campaign should expect, but they're a far more honest reference point than the vague "X% prefer digital wallets" claims that circulate with no named source.

For context on scale: Juniper Research estimated that roughly 4.4 billion people used a digital wallet worldwide in 2025, around 55 per cent of the global population. Be precise about what that figure measures: it covers digital and payment wallets broadly (Apple Pay, Google Pay, PayPal and similar), not specifically Apple Wallet or Google Wallet passes like loyalty cards and tickets. It tells you the addressable audience already has a wallet app installed and habitually uses it, not how many of them save loyalty cards or tickets specifically.

What it costs and takes to set up

Apple restricts pass creation and signing to enrolled developers. It requires membership in the Apple Developer Program, currently $99 a year, with fee waivers available for qualifying nonprofit, education, and government organisations. That fee covers your organisation's whole developer account, not a per-pass or per-campaign charge, so for an agency running passes across multiple clients it's a one-off annual cost rather than something to bill per project.

The "Add to Apple Wallet" badge itself is free to use, but Apple is strict about how: it must be the unmodified official asset in one of Apple's defined localisations, placed with the specified clear space, and shown with the required trademark credit line. Apple's guidelines page is explicit that you cannot recolour it, resize it outside spec, or substitute your own button design and still call it an "Add to Apple Wallet" action. This trips up more agencies than it should: a bespoke branded button might look better on the page, but if it doesn't match Apple's asset it isn't compliant.

Google Wallet requires enrolling as an issuer through the Google Wallet API, setting up a service account and a signing key for your JWTs. There's no published flat annual fee equivalent to Apple's, but building and hosting the Class/Object management and the signing service is still real engineering work, not a plug-in.

Frequently asked questions

Can you add any QR code directly to Apple Wallet?

No. Apple Wallet only installs signed .pkpass bundles. A QR code that isn't declared inside a pass's barcodes data and wrapped in a signed bundle has no route into Wallet. Any workflow claiming to "add a QR code to Apple Wallet" is, under the hood, generating and signing a .pkpass file that happens to contain a QR barcode.

How do you put a QR code into Google Wallet?

You define a Class and Object for the pass, then generate a signed JWT referencing them and hand the customer a https://pay.google.com/gp/v/save/<jwt> link, usually behind a QR code or an "Add to Google Wallet" button. The link, not a raw image, is what carries the QR code's actual payload.

What's the difference between a QR code and a wallet pass?

A QR code is a static image encoding a short piece of data, usually a URL. A wallet pass is a signed file (Apple) or a cloud-hosted record (Google) that becomes a persistent object on the customer's phone, with its own icon, lock-screen surfacing, and update channel. The QR code is only the delivery mechanism at save time; the pass is the thing that persists afterwards.

Do wallet passes expire?

Yes, and both platforms handle it as pass state rather than code state. Google Wallet sets an object's validTimeInterval.end.date or moves it to an Expired, Inactive, or Completed state. Apple Wallet passes carry an expirationDate field and can also be marked void by the issuer's server. Either way, expiry is something you set on the pass record, not something baked into the printed QR code.

Can a wallet pass update without the customer rescanning a code?

Yes, this is the main advantage over a plain QR link. Once a pass is saved, the issuer's server can push updated field values (a new points balance, a redeemed status, a changed seat number) and the phone refreshes the saved pass automatically, using Apple's push mechanism or Google's Object API. The customer never rescans anything.

What barcode formats does Apple Wallet support?

Four, as of iOS 9 and later: QR (PKBarcodeFormatQR), PDF417, Aztec, and Code128. QR is the most broadly compatible with retail scanners; PDF417 and Aztec are common for tickets and boarding passes; Code128 suits older 1D-only POS hardware.

Do you need an Apple Developer account to create Wallet passes?

Yes. Signing a .pkpass bundle requires a certificate issued to an enrolled Apple Developer Program member, currently $99 per year, with waivers for qualifying nonprofits, schools, and government bodies. There is no way to sign a valid pass outside that programme.

Can one QR code work for both Apple Wallet and Google Wallet?

Yes, but only indirectly. The printed code points to a redirect URL on your own server. That server detects whether the scanning device is iOS or Android from the User-Agent header and serves the matching flow, a .pkpass download or a signed Google save link. This device-detection redirect is a common engineering pattern, not a feature either platform builds in natively, and it depends on the code being dynamic rather than a static link to one platform's file.

How do you add a QR-code loyalty card without an app?

This is precisely what a wallet pass solves: neither platform requires the business to build its own app. The loyalty card lives inside the customer's existing Wallet app, added via the .pkpass/JWT flow described above, so "no app required" for the customer is true, even though someone still has to build the pass-issuing service behind the scenes.

Is the "Add to Apple Wallet" badge free to use?

Yes, the badge asset itself carries no licence fee, but it must be used unmodified, in an approved localisation, with the specified minimum clear space and the required trademark credit line, per Apple's official guidelines. Modifying the artwork or substituting a custom button and still calling it "Add to Apple Wallet" is not compliant.

Can wallet passes send push or location notifications?

Yes, within limits set by each platform. A pass can surface on the lock screen when the customer is near a relevant location (a coupon near a store, a ticket near a venue), and issuers can push content updates that appear as pass changes. That's a genuine capability difference from a QR code linking to a static web page, which has no equivalent presence on the device between scans.

The short version

A bare QR code cannot go into Apple Wallet: it has to be declared inside a signed .pkpass bundle's barcodes data, one of exactly four supported formats (QR, PDF417, Aztec, Code128). Google Wallet works differently again, built on a Class/Object model added via a signed JWT save link rather than a file bundle. One printed QR code can still serve both platforms by pointing at your own redirect server, which detects iOS versus Android and serves the right flow, the same dynamic-code pattern used for routing to two app stores. Once a pass is saved, it's the pass content, not the printed code, that updates: points balances, redemption status, and expiry all live on the server side. If you're briefing a client on loyalty cards, tickets, or coupons, start by deciding whether you actually need the persistence and lock-screen surfacing a wallet pass gives you, or whether a well-built QR code retargeting flow into a normal landing page solves the problem more simply. And if the campaign doesn't need Wallet's install step at all, it's worth comparing against NFC tags before committing to either.