Apple Wallet (and Google Pay) is a mobile system design question that touches secure-element hardware, NFC protocols, payment networks, and the user-experience challenges of a “wallet” that holds everything from credit cards to airline tickets to building access cards.
Functional requirements
- Store credit cards, debit cards, transit passes. The wallet holds open-loop payment cards (credit and debit) alongside closed-loop transit passes, which behave differently at the reader. Be ready to explain why transit needs sub-300ms taps while a retail payment can tolerate a round trip to the issuer.
- Boarding passes, event tickets, loyalty cards. These are static or slowly-updating passes rather than payment instruments, so the design centers on rendering, barcode display, and update delivery. A common follow-up: how does a gate change reach a passenger whose phone is in airplane mode?
- Pay with NFC at point-of-sale. This is the latency-sensitive core of the design; interviewers want the token and cryptogram exchange, not just “the phone talks to the reader.” Know that the device emulates a contactless EMV card.
- Pay online with Apple Pay / Google Pay. In-app and web payments skip NFC and hand a token plus cryptogram to the merchant’s server over the network. The point to make is that the merchant still never sees the real card number.
- Sync across user’s devices. Passes and provisioned cards follow the user to new devices, but each device gets its own device-bound token rather than a copied one. Expect questions on how a new phone or watch re-provisions a card without the user re-entering the number.
- Notifications when passes are relevant (boarding time, location-based). Relevance is driven by time and geofence triggers baked into the pass, so the phone can surface a boarding pass near the airport without a server ping. Interviewers probe the battery and privacy trade-offs of always-on geofencing.
Architecture
Three layers: secure element (hardware), wallet app (UX), cloud sync.
Secure element
Card numbers are never stored on the device in the clear. The chip in the device generates a token (DPAN — Device Primary Account Number) that represents the card. The DPAN is what gets transmitted at the point of sale.
The token is bound to:
- The specific device, so a token lifted from one phone is useless on another.
- Optionally a specific merchant. In-app tokens can be locked to a single merchant, which limits the damage if that merchant is breached.
- A cryptographic key in the secure element. The key never leaves the chip, so copying the token off the device does not let an attacker generate valid cryptograms.
The actual card number stays at the issuing bank.
NFC payment flow
- User taps device on NFC reader
- Reader sends payment request
- Wallet app authenticates user (Face ID / Touch ID / passcode)
- Secure element generates a one-time cryptogram using the DPAN
- Cryptogram + DPAN sent to merchant
- Merchant’s acquirer routes to card network → issuing bank
- Issuer detokenizes, validates, approves or declines
- Result returned in <500ms typical
Pass format
Passes are signed JSON bundles (.pkpass on iOS, similar on Android). They include:
- Front and back images. The layout and artwork the user sees; the front is the glanceable view on the lock screen, the back holds fine print and support details.
- Barcode or QR code. This is the actual credential scanned at a gate or register, so its payload and refresh behavior matter more than the visuals.
- Trigger conditions (time, location). Metadata that tells the OS when to surface the pass, such as an hour before departure or within range of a stadium.
- Web service URL for updates. The issuer endpoint the phone calls to pull fresh pass data, paired with a push token so the issuer can signal that a change is waiting.
Passes can be updated by the issuer (e.g., gate change for a flight). Wallet polls or receives push when a pass updates.
Location-based notifications
Passes can specify locations. When the user is near a relevant location (airport, stadium), the pass surfaces on the lock screen.
Implementation: register geofence with iOS/Android. When triggered, show the pass.
Cross-device sync
iCloud Keychain (iOS) or Google Account sync (Android). Passes and tokenized cards sync to other devices owned by the same user. Each new device requires re-authentication.
Security model
- Biometric required for payment
- Tokens revocable remotely (lost device)
- Suspended automatically if device is reported lost
- Each transaction generates a unique cryptogram — replay attacks are impossible
Frequently Asked Questions
What happens if I lose my phone?
Tokens can be revoked from iCloud (Find My) or Google Find My Device without canceling the underlying card. The card itself remains usable; only the device-specific token is killed.
Can a merchant see my real card number?
No. They see only the DPAN (token). The real card number is never transmitted. This is significantly more secure than traditional EMV.
How does Wallet handle transit cards?
Transit cards typically use a different protocol (closed-loop transit cards). Wallet provisions them via the transit operator’s issuing app and stores them in the secure element similarly to credit cards.
Keep sharpening your system design:
