A digital gift card in a mobile wallet is not a card at all. It is a signed data file (a pass) that Apple Wallet or Google Wallet displays on the lock screen and at the checkout, while the actual money sits on a stored-value ledger run by the retailer or its gift card processor. That split, which sits at the center of how retail gift card and stored-value programs really work, explains most of what goes right and wrong with the format: the phone shows a barcode and a balance, the processor decides whether a redemption is approved, and the two only agree when the pass is refreshed after each transaction. Retailers that understand the split ship wallet passes that redeem cleanly; retailers that treat the pass as the card end up with stale balances, double scans and support tickets.
In short
- A wallet pass is a display layer. The balance of record lives with the stored-value processor; the pass is a signed file that carries the card number, a barcode and a cached balance that must be pushed to the phone after every redemption.
- Apple Wallet and Google Wallet issue passes differently. Apple uses signed .pkpass bundles and its Pass Type ID certificate; Google uses a Gift card pass class created through the Google Wallet API and a JWT-based “Add to Google Wallet” link. A retailer needs both to cover the US phone base.
- Redemption is a scan or a tap. Most US stores read a QR or PDF417 barcode from the screen; NFC redemption through Apple’s Value Added Services protocol or Google’s Smart Tap requires a certified terminal and an entitlement from the platform, so it remains less common than a barcode.
- Balance sync is the main failure point. Push updates can lag by seconds or minutes, pass web services go down, and shoppers screenshot barcodes that stop matching the ledger. Design for the stale-balance case rather than hoping it never happens.
- Refunds, reissues and lost phones are ledger operations, not wallet operations. Because the value never lived on the device, a replacement is a new pass on a new device pointing at the same or a reissued card number, and consumer protections attached to the underlying card still apply.
Why do shoppers prefer a gift card in the phone wallet?
Shoppers prefer wallet gift cards for the same reason they prefer wallet boarding passes: the card is where the phone is, it surfaces itself at the right moment, and the balance is visible without a phone call or a website lookup. Plastic gift cards get forgotten in a drawer; an emailed code gets buried in an inbox. A pass that appears on the lock screen when the phone is near the store is the one that gets spent. That behavior is the reason the format matters to retailers well beyond convenience, since a card that gets spent generates a visit and usually a basket larger than the card value.
The behavioral effect shows up in breakage, the share of gift card value that is never redeemed. Retailers tend to see lower breakage on cards that live in a wallet than on cards that live in a drawer, which reduces the income line that accounting recognizes from unredeemed balances but increases store traffic and the incremental spend attached to each redemption. The tradeoff is real and worth reading against the accounting behind balances nobody redeems before a finance team signs off on a wallet program on the assumption that it is pure upside.
The second reason is speed at the register. A barcode on a bright phone screen scans in under a second on a modern 2D imager, faster than swiping a magstripe plastic card and far faster than a cashier typing a 16-digit number from an email.
The third reason is that the pass can carry more than a balance. Issuers can push messages to the pass, show the nearest store, attach a promotion and change the barcode after each transaction, none of which a printed card can do.
What does a wallet pass contain and how is it issued?
A wallet pass contains the card identifier, a barcode encoding that identifier (and sometimes a PIN or a token), a cached balance, display fields such as the retailer name and colors, and a pointer back to the issuer’s web service so the wallet can request updates. Nothing in the pass can move money. The processor that runs the stored-value ledger (large US retailers commonly use providers such as Blackhawk Network, InComm, Givex or the stored-value modules of their payments processor) holds the balance and answers authorization requests from the POS.
Issuance works the same way on both platforms at a high level. The retailer’s gift card system creates a card record on the processor, then generates a pass for that card, signs it with credentials the platform issued to the retailer, and delivers a link or file to the shopper. When the shopper taps “Add”, the wallet validates the signature, stores the pass and registers the device with the issuer’s web service so it can receive updates. From that moment the phone has a copy of the card data, and the issuer has a way to reach that copy.
Apple Wallet: PassKit and the .pkpass bundle
On iPhone, a gift card is a store card style pass built with Apple’s PassKit framework. The pass is a .pkpass bundle: a JSON description of fields, a set of images for the logo and strip, a manifest of file hashes and a signature created with a Pass Type ID certificate that the retailer obtains through its Apple Developer account. Apple describes the format, the pass styles and the update protocol in its Wallet developer documentation. The barcode formats Apple’s Wallet renders are QR, PDF417, Aztec and Code 128, which means an issuer that still relies on a 1D UPC-style barcode for gift cards has to move to Code 128 or a 2D symbology before the card can live in Apple Wallet.
Updates depend on two fields in the pass: a web service URL and an authentication token. When the pass is added, the device registers with that URL. When the balance changes, the issuer sends a push notification through Apple’s push service, the device fetches the new pass version, and the displayed balance changes.
Apple also allows relevance data on the pass (store locations or beacon identifiers) so the pass appears on the lock screen when the shopper is at the store. NFC redemption is a separate capability that requires Apple to grant an NFC entitlement for the Pass Type ID and a terminal that speaks Apple’s Value Added Services protocol.
Google Wallet: the Gift card pass class and the Wallet API
On Android, a gift card is a Gift card object under a Gift card class in the Google Wallet API. The retailer defines the class once (branding, redemption details, merchant name), then creates one object per card with the card number, a barcode, a balance and a balance update time. The shopper adds the card through an “Add to Google Wallet” link or button that carries a JWT signed with the retailer’s service account key, which Google validates before saving the object to the user’s account. Updates are made by patching the object through the API, and Google pushes the change to every device signed into that Google account.
The two platforms differ in where the pass lives. An Apple pass is a file on the device that can also sync to the shopper’s other Apple devices through iCloud; a Google Wallet object is a record in the shopper’s Google account rendered on whichever device is signed in. The practical consequence is that a Google pass survives a device change without any reinstallation, while an Apple pass usually reappears on a new iPhone once the shopper signs in and Wallet syncs, but the issuer’s web service sees a new device registration and must be ready for it.
| Attribute | Apple Wallet (iPhone) | Google Wallet (Android) |
|---|---|---|
| Pass type used for gift cards | Store card style pass (PassKit) | Gift card class and object (Wallet API) |
| Issuer credential | Pass Type ID certificate from Apple Developer program | Service account key linked to a Google Wallet issuer account |
| Delivery to shopper | Signed .pkpass file via link, email attachment or in-app button | Signed JWT link or “Add to Google Wallet” button |
| Where the pass is stored | On device, optionally synced via iCloud | In the Google account, rendered on signed-in devices |
| Balance update mechanism | Push notification, then device fetches updated pass from issuer web service | Issuer patches the object; Google pushes to devices |
| Barcode formats | QR, PDF417, Aztec, Code 128 | QR, PDF417, Aztec, Code 128 and others per API reference |
| NFC redemption | Apple VAS protocol; requires NFC entitlement from Apple | Smart Tap; requires Smart Tap enablement and a supporting terminal |
| Lock screen surfacing | Location and beacon relevance fields | Location-based notifications where enabled |
| Manual add without issuer support | Not native; third-party pass apps only | Limited; issuer-generated passes are the reliable path |
How does scanning work at the point of sale: barcodes, NFC and fallbacks?
At the register, a wallet gift card is redeemed by one of three methods: the cashier or a self-checkout scanner reads a barcode from the phone screen, the shopper taps the phone on an NFC reader, or someone types the card number and PIN by hand. Every one of those paths ends at the same place: the POS sends the card number (and PIN where the program uses one) to the stored-value processor, the processor checks the balance and returns an approval for the redemption amount, and the POS applies it to the tender line.
The barcode path is the common one in US stores because it works on scanners already installed for product codes. The condition is that the scanner is a 2D imager rather than a laser. Laser scanners read printed 1D barcodes by reflecting light off paper and cannot read a backlit screen reliably; camera-based imagers read screens, QR codes and PDF417 without trouble. Most large chains replaced laser scanners years ago, but independent stores and older self-checkout lanes still fail on phone screens, and the failure looks like a broken pass to the shopper even though the pass is fine.
NFC redemption with Apple VAS and Google Smart Tap
NFC redemption uses the same tap gesture as Apple Pay or Google Pay, but the data exchanged is the pass identifier rather than a payment token. Apple’s mechanism is the Value Added Services (VAS) protocol, which a certified terminal uses to request a pass from Wallet; Google’s is Smart Tap, which does the same for Google Wallet objects. Both require the retailer to be enabled by the platform, the pass to carry the right NFC configuration, and the terminal to support the protocol and be configured with the retailer’s collector identifiers.
The appeal of NFC is that it can combine a payment and a gift card redemption in a single tap. The cost is the certification and terminal work, which is why NFC gift card redemption is concentrated in chains that already run loyalty through the wallet. For most retailers the barcode is the primary path and NFC is a later phase, and the checkout mechanics of the payment wallets themselves are covered in our look at Apple Pay, Google Pay and PayPal at retail checkout.
What the fallback path has to handle
Manual entry is the fallback when the scanner cannot read the screen, the phone is cracked, the pass failed to load, or the store’s network to the processor is down. A well-designed pass shows the card number and PIN in the pass details view so the cashier can key them in, but many issuers hide the PIN to reduce fraud. The choice is a tradeoff: hidden PINs reduce the damage from a shoulder-surfed screen but leave the shopper stranded when the scanner fails. A middle path is to reveal the PIN behind a tap so it is not visible on the lock screen but is reachable at the register.
| Redemption method | What the POS needs | Typical time at register | Common failure | Fallback |
|---|---|---|---|---|
| 2D barcode scan (QR, PDF417) | Camera-based imager | Under 2 seconds | Laser scanner, cracked screen, low brightness | Manual entry of number and PIN |
| 1D barcode scan (Code 128) | Any imager; some lasers fail | Under 2 seconds | Screen glare, narrow bars on small phones | Manual entry |
| NFC tap (Apple VAS, Smart Tap) | Certified terminal with retailer configuration | Under 1 second | Terminal not enabled, pass missing NFC data | Barcode scan |
| Manual entry | Keypad and processor connection | 20–60 seconds | Typos, hidden PIN, processor outage | Store credit issued offline, reconciled later |
| Online redemption | Card number and PIN fields at checkout | Under 30 seconds | Pass shows number but not PIN | Email lookup of original card delivery |
How is the balance kept in sync after each redemption?
The balance is kept in sync by a chain of events that starts at the processor and ends on the phone: the processor records the redemption, the retailer’s pass service learns about it (through a webhook, a polling job or a direct integration with the processor), the pass service updates the pass and notifies the platform, and the platform pushes the new balance to the device. Each link can lag. A shopper who spent $20 of a $50 card and looks at the phone in the parking lot may still see $50 for a few seconds, a few minutes or, if a link is broken, until the next time the pass is opened and refreshed by hand.
The lag has two consequences. The first is support volume: shoppers who see a wrong balance call or email, and staff who cannot see the pass pipeline assume the processor is wrong. The second is a fraud vector: a stale pass on a second device shows a balance that no longer exists, and a shopper (or someone who copied the barcode) can try to spend it again. The processor will decline the second redemption because it holds the true balance, but the register interaction is awkward and the cashier has to explain why the phone is wrong.
Push, pull and the refresh-on-open pattern
Apple Wallet and Google Wallet both support push-driven updates, but the wallets also refresh a pass when the shopper opens it, and Apple’s Wallet lets the shopper pull down on the pass to force a fetch. A resilient issuer treats push as an optimization and the refresh-on-open as the guarantee. That means the pass web service must always return the latest balance from the processor rather than a cached copy, even when the push pipeline has failed, so the moment a shopper opens the pass it becomes correct.
How do delivery, scheduling and gifting to someone else work?
Delivery of a wallet gift card is a two-step handoff: the buyer’s purchase creates the card and a delivery message, and the recipient turns the message into a pass on their own phone. Because the buyer’s device type is irrelevant and the recipient’s device type is unknown at purchase time, the delivery message has to offer both “Add to Apple Wallet” and “Add to Google Wallet” and degrade to a plain code for recipients who use neither. Retailers that only produce a .pkpass attachment lose every Android recipient at the first step.
Transfer and regifting
Transferring a wallet gift card to another person is not a wallet feature; it is an issuer feature. Apple and Google do not provide a “send this pass to someone else” control for store cards, so a retailer that wants to support regifting has to offer it in its own app or site by reissuing the balance to a new card number and delivering a fresh pass to the new recipient. The original pass should then be voided by pushing an update that marks it as transferred and removes the barcode, otherwise the old holder still has a working credential.
Cross-border gifting introduces a second constraint. A card denominated in US dollars and redeemable in US stores is not useful to a recipient in another country, and stored-value programs are usually licensed and regulated per jurisdiction. Retailers that sell in several countries typically run a separate card program per market and a separate pass class per program. That is a different world from open-loop settlement, and readers curious about how genuinely cross-border retail money moves can compare it with stablecoin settlement for cross-border retail merchants, which solves a merchant-side problem rather than a consumer gifting one.
What happens with refunds, reissues and lost phones?
Refunds, reissues and lost phones are all handled at the ledger, not on the device, because the device never held the value. A refund of a purchase paid with a wallet gift card returns value to the same card number on the processor, and the pass updates through the normal sync path. A reissue creates a new card number with the remaining balance and a new pass, and voids the old one. A lost phone changes nothing about the balance; it changes who can present the barcode.
That last point is where support scripts often go wrong. A shopper who lost a phone with a $100 gift card on it has not lost $100. The card still exists on the processor, the balance is intact, and the shopper can add the pass again on a new phone through the original delivery email or link, or (on Apple) through iCloud sync when the new iPhone is set up, or (on Google) by signing into Google Wallet.
What the shopper has lost is exclusivity: whoever has the old phone can present the same barcode until the card is reissued. The safe response is to reissue the balance to a new card number immediately, which is a routine processor operation, and to push an update that blanks the barcode on the old pass.
Reissue mechanics and what the shopper sees
A reissue is invisible to the shopper if the pass is designed for it. The issuer generates a new card on the processor, moves the balance, updates the existing pass object to carry the new card number and barcode, and pushes the update. On Google Wallet the object identifier stays the same and the fields change. On Apple Wallet the pass serial number stays the same and the pass content changes, as long as the issuer keeps the same Pass Type ID and serial number, which is the recommended approach because it avoids the shopper having to delete and re-add anything.
Consumer protection rules that still apply
The wallet format does not change the legal character of the card. In the United States, the federal rules on gift card expiration and fees come from the Credit CARD Act of 2009 and its implementing regulation, which the Consumer Financial Protection Bureau explains in its consumer guidance: according to the CFPB, funds on a gift card generally cannot expire sooner than five years after the card was purchased or last loaded, and inactivity fees are restricted to specific conditions. State laws add unclaimed-property rules and, in some states, stricter limits. Retailers designing a wallet program should read the current text on the CFPB’s gift card page and confirm with counsel, since rules and thresholds change and this article is a general explanation rather than legal advice.
This is general information, not legal, tax or accounting advice. Gift card programs sit under federal consumer finance rules, state unclaimed-property and escheat laws, money transmission questions in some structures and revenue recognition standards, and the right answers depend on the specific program, the states in which it operates and the way balances are held. A retailer setting up or changing a stored-value program should consult a licensed attorney and its accounting advisor for its own situation rather than rely on a summary like this one.
What breaks most often and how do retailers prevent it?
The failures that generate the most support contacts are, in rough order, stale balances, scanners that cannot read the screen, recipients on the wrong platform for the pass they received, passes that fail to add because a certificate expired, and screenshots of barcodes that are presented in place of the pass. None of them is exotic, and all of them are preventable with configuration and process rather than new technology.
Screenshots and copied barcodes
A screenshot of a pass is a static barcode that keeps working as long as the card number and PIN it encodes are valid. That is convenient for a shopper who wants to send a card to a friend and dangerous when the screenshot lands in the wrong hands. Issuers can reduce the exposure by regenerating the barcode content after each redemption (so a screenshot is stale once the card is used), by keeping the PIN out of the barcode and requiring it separately, or by adopting rotating barcodes where the platform supports them for the pass type. The wider set of countermeasures, from PIN scratch panels to processor velocity rules, is set out in our piece on gift card draining, cloning and the controls that stop them.
| Failure | What the shopper sees | Root cause | Prevention |
|---|---|---|---|
| Stale balance | Pass shows more than the card has | Missing processor event feed or push failure | Refresh-on-open returns live balance; show last-updated time |
| Scanner cannot read pass | “It won’t scan” at the register | Laser scanner or low screen brightness | 2D imagers at every lane; auto-brightness boost on pass view |
| Pass fails to add | Error on tapping “Add” | Expired certificate, malformed JSON, bad signature | Credential expiry calendar; pass validation in CI |
| Recipient on wrong platform | Unopenable file or foreign app prompt | Single-platform delivery | Device-aware hosted page with both buttons and plain code |
| Double redemption attempt | Decline on a card that “shows a balance” | Second device or screenshot with stale barcode | Barcode regeneration after use; processor is source of truth |
| Old pass after reissue | Two passes for one card, one dead | New pass per reissue instead of update | Update in place; mark old pass voided |
How does a retailer plan the rollout?
A retailer plans a wallet gift card rollout in four stages: confirm the processor can emit redemption events and expose a live balance endpoint, build and validate passes for both platforms, verify every register and self-checkout lane reads a phone screen, and run the pass through the full lifecycle (issue, partial redemption, refund, reissue, void) before launch. The order matters. Passes built before the event feed exists will look finished and then fail in the field on the first redemption.
Measuring whether it worked
Three numbers tell the story after launch: the share of digital cards that get added to a wallet, the redemption rate of wallet cards against emailed-code cards over the same window, and support contacts per thousand wallet cards. A healthy program sees wallet adds in the double digits as a share of digital cards, a redemption rate visibly above the emailed-code baseline and a support rate that falls after the first month as the event feed and scanner issues are fixed. If redemption rises, finance should expect the breakage assumption to move, which is why the accounting team belongs in the launch review.
Wallet gift cards are a small piece of a larger shift in how money reaches the register, alongside network tokens, tap to pay on phones and pay-later tenders at the physical checkout, and that broader picture is mapped in our overview of how retail payments are changing across cards, BNPL and crypto. The gift card pass is the most contained of those changes because it touches only closed-loop value the retailer already controls, which makes it a sensible first wallet project for a chain that has not yet put anything in Apple Wallet or Google Wallet.
A wallet gift card is not a payment card, not a crypto wallet and not a loyalty card, though it can sit next to all three on the same phone. It uses no payment network, tokenizes no bank account and holds no value on the device. Shoppers sometimes conflate the wallet that holds a stored-value pass with the wallet that holds a self-custodied crypto balance, and the two differ completely in who controls the money; the retail reality of the latter is examined in our assessment of crypto payments in retail, adoption versus hype.
FAQ: digital gift cards in mobile wallets
Is the money stored on my phone when I add a gift card to Apple Wallet or Google Wallet?
No, the pass on the phone holds the card number, a barcode and a cached balance. The money is a balance on the retailer’s stored-value ledger, run by the retailer or its gift card processor. When the card is scanned, the register asks that ledger whether the redemption is allowed. Losing the phone does not lose the money, only exclusivity over the barcode until the card is reissued.
Why does my wallet pass show the wrong balance after I used the card?
Because the balance on the pass is a copy that has to be pushed to the phone after each redemption. The processor records the spend instantly, but the update to the pass travels through the retailer’s pass service and the platform’s push system, which can take seconds or minutes and can fail. Opening the pass usually forces a refresh. If it stays wrong, the retailer’s event feed between the processor and the pass service is probably not working.
Can I add any gift card to Apple Wallet myself?
Not natively. Apple Wallet only accepts passes signed by an issuer with a Pass Type ID certificate, so a card can be added only if the retailer (or a pass vendor acting for it) generates the pass. Third-party pass apps let you create a barcode pass from a card number, which works for scanning but carries no live balance. Google Wallet similarly relies on issuer-generated Gift card objects for balance-aware passes.
Will the card scan at any store register?
It scans at any register with a camera-based 2D imager, which covers most large US chains. Older laser scanners cannot read a phone screen and will fail on any wallet pass. When a scan fails, the cashier can key in the card number and PIN if the pass exposes them, so check whether the retailer’s pass shows the PIN in the details view before relying on it in a store with old hardware.
Can I tap my phone to redeem a gift card instead of scanning?
Only where the retailer has enabled NFC redemption. Apple uses its Value Added Services protocol and requires an NFC entitlement for the pass; Google uses Smart Tap. Both need a terminal configured for the retailer, so chains that already run loyalty through the wallet are the most likely to support it. Everywhere else, the barcode is the redemption path and the NFC tap will only trigger the payment card.
What happens to a wallet gift card if I get a new phone?
On Android, the card is a record in your Google account and appears in Google Wallet on the new device once you sign in. On iPhone, passes typically sync through iCloud when Wallet sync is enabled, and if not, the original delivery email or link adds the pass again. The balance is unaffected either way. If the old phone was lost rather than replaced, ask the retailer to reissue the card so the old barcode stops working.
Do gift card expiration rules apply to a card in a mobile wallet?
Yes. The wallet is a display format and does not change the legal character of the card. According to the CFPB, federal rules generally prevent gift card funds from expiring sooner than five years after purchase or last load and restrict inactivity fees, and state laws can add further limits. Confirm the current rules at the official source, since they change and this is general information rather than legal advice.
What to read next
The wallet pass is the last mile of a stored-value program, and the choices that make it work (who runs the ledger, how breakage is recognized, which fraud controls apply) are made further upstream. Start with the full guide to how retail gift card and stored-value programs really work, then read the fraud and accounting pieces linked above before committing a holiday launch date.