Design Apple Wallet: Passes, Cards, and Apple Pay

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
  • Boarding passes, event tickets, loyalty cards
  • Pay with NFC at point-of-sale
  • Pay online with Apple Pay / Google Pay
  • Sync across user’s devices
  • Notifications when passes are relevant (boarding time, location-based)

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
  • Optionally a specific merchant
  • A cryptographic key in the secure element

The actual card number stays at the issuing bank.

NFC payment flow

  1. User taps device on NFC reader
  2. Reader sends payment request
  3. Wallet app authenticates user (Face ID / Touch ID / passcode)
  4. Secure element generates a one-time cryptogram using the DPAN
  5. Cryptogram + DPAN sent to merchant
  6. Merchant’s acquirer routes to card network → issuing bank
  7. Issuer detokenizes, validates, approves or declines
  8. Result returned in <500ms typical

Pass format

Passes are signed JSON bundles (.pkpass on iOS, similar on Android). They include:

  • Front and back images
  • Barcode or QR code
  • Trigger conditions (time, location)
  • Web service URL for updates

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.

Scroll to Top