Digital Wallets Explained: How Apple Pay, Google Pay, and Samsung Pay Work

You tap your phone at the coffee shop terminal, hear a cheerful ding, and walk away with your latte — no card, no PIN, no signature. In under 500 milliseconds, your phone just orchestrated a cryptographic handshake involving your bank, the card network, a hardware security chip, and a one-time-use payment credential that will never work again. That’s a digital wallet in action, and the engineering behind that half-second tap is astonishingly elegant.

What is a Digital Wallet?

A digital wallet (also called a mobile wallet) is a software application — typically on a smartphone, smartwatch, or tablet — that stores virtualized versions of your payment cards and uses them to make contactless transactions at physical terminals or online checkouts. Instead of carrying a plastic card, your device becomes the card.

But here’s the critical engineering detail: your digital wallet does not store your actual card number. When you add a card to Apple Pay or Google Pay, the real Primary Account Number (PAN) is replaced with a Device PAN (DPAN) — a network token issued by the card network’s Token Service Provider. Your real card number never touches the merchant’s terminal.

Deep dive: Our Payment Tokenization Guide explains the full lifecycle of network tokens and DPANs — the same technology that powers every digital wallet transaction.

Also Known As

Digital wallets go by many names across different contexts:

How Digital Wallets Work

Every digital wallet transaction follows two major phases: enrollment (adding the card) and payment (tapping to pay). Understanding both is essential for payment engineers.

Phase 1: Card Enrollment (Provisioning)

When you add a credit card to a digital wallet, a multi-party provisioning flow occurs:

┌──────────┐   PAN    ┌──────────┐  Verify  ┌──────────┐
│  User    │ ───────→ │  Wallet  │ ───────→ │  Card    │
│  (Phone) │          │  App     │          │  Network │
└──────────┘          └────┬─────┘          └────┬─────┘
                           │                     │
                           │                     ↓
                           │              ┌──────────┐
                           │              │  Token    │
                           │              │  Service  │
                           │              │  Provider │
                           │              └────┬─────┘
                           │                   │ DPAN
                           ↓                   ↓
                     ┌──────────────────────────┐
                     │  Secure Element / HCE    │
                     │  (stores DPAN + keys)    │
                     └──────────────────────────┘

1. User enters card details — PAN, expiry, CVV2 (or scans the card with camera)
2. Wallet contacts the card network — The PAN is sent to the network’s Token Service Provider (Visa Token Service, Mastercard Digital Enablement Service, etc.)
3. Issuer verifies identity — The issuing bank may require additional verification (SMS OTP, in-app approval, call to bank)
4. Network issues a DPAN — A format-preserving token bound to this specific device
5. DPAN stored securely — In the phone’s Secure Element (Apple Pay) or Host Card Emulation environment (Google Pay)
6. Card is “provisioned” — Ready for contactless payments

Phase 2: Making a Payment (Tap-to-Pay)

When you hold your phone near a contactless terminal:

1. NFC field activates — The terminal’s NFC reader powers the communication
2. Wallet presents the DPAN — Along with a one-time dynamic cryptogram (similar to an ARQC in chip transactions)
3. Terminal sends authorization — An ISO 8583 0100 message is sent through the acquirer to the card network
4. Network de-tokenizes — The Token Service Provider maps the DPAN back to the real PAN
5. Issuer authorizes — The issuer approves the transaction against the real card account
6. Response flows back — Approval reaches the terminal in under 500ms

The merchant never sees your real PAN. The terminal receives a token and a cryptogram — nothing reusable.

Try it yourself: Use our ISO 8583 Studio to parse an authorization message from a contactless transaction — Field 22 will show entry mode 07 (contactless chip) or 91 (contactless DPAN).

Apple Pay, Google Pay, and Samsung Pay Compared

While all three wallets achieve the same goal — tap-to-pay without a physical card — they differ significantly in architecture, security model, and capabilities:

Samsung Pay’s MST: The Magnetic Trick

Samsung Pay originally included a unique technology called Magnetic Secure Transmission (MST) that could mimic a magnetic stripe swipe. The phone’s MST coil generated a magnetic field that legacy terminals interpreted as a card swipe — allowing Samsung Pay to work at terminals without NFC.

NFC Payment:     Phone ←─── NFC field ───→ Contactless Reader
MST Payment:     Phone ───→ Magnetic field ───→ Mag Stripe Reader

Related: Learn how magnetic stripe data is structured in our Magnetic Stripe Track Data Guide — MST transmits tokenized equivalents of this format.

The Security Architecture

Digital wallets are often more secure than physical cards. Here’s why:

Secure Element vs Host Card Emulation

The core architectural decision for any digital wallet is where to store the sensitive DPAN and cryptographic keys:

Secure Element is a tiny, tamper-proof chip (similar to what’s inside your EMV card) embedded in the phone. It runs its own operating system and stores the DPAN and private keys in hardware that resists physical extraction — even if the phone is jailbroken.

Host Card Emulation avoids the need for a hardware SE by storing tokenized credentials in a cloud environment. Google Pay downloads a set of limited-use keys to the device. Each key can only be used for a small number of transactions before new keys must be fetched from the cloud.

The Dynamic Cryptogram

Every digital wallet transaction generates a unique, one-time cryptogram — a cryptographic value computed from the DPAN, transaction data, and a key stored in the SE or HCE environment. This is conceptually identical to the ARQC (Application Request Cryptogram) generated by EMV chip cards.

The cryptogram ensures that even if someone intercepts the NFC transaction data, they cannot replay it — the cryptogram is bound to that specific transaction amount, date, and counter value.

Verify cryptograms: Use our ARQC Calculator to understand how transaction cryptograms are generated — the same HSM-based principles apply to digital wallet cryptograms.

Why Wallets Beat Physical Cards on Security

Digital Wallets in ISO 8583

For payment engineers, digital wallet transactions appear as standard contactless chip transactions in ISO 8583 messages, with a few important distinctions:

Key Fields

POS Entry Mode Codes for Digital Wallets

The Field 22 POS Entry Mode tells the issuer exactly how the cardholder credential was presented:

Look up codes: Our POS Entry Mode Guide has the complete Field 22 breakdown — modes 07 and 91 are the ones you’ll see in wallet transactions.

DSRP: Digital Secure Remote Payment

When digital wallets are used for online (card-not-present) transactions, the card networks use a protocol called DSRP (Digital Secure Remote Payment). DSRP generates a chip-like cryptogram for e-commerce transactions, giving them the same security benefits as in-store contactless taps.

Decode DSRP data: Use the EMV Tag Inspector to parse the Field 55 data from wallet transactions — you’ll see the same EMV tags as chip card transactions.

Other Digital Wallets in the Ecosystem

Beyond the big three OEM wallets, the digital wallet landscape includes several other important players:

These wallets use varying architectures — some use network tokenization (like OEM wallets), while others act as intermediaries that process payments through their own acquiring relationships.

What Digital Wallets Do NOT Do

Understanding the boundaries prevents over-reliance:

Not a Bank Account

Digital wallets are pass-through mechanisms. They don’t hold money (unlike prepaid wallets like PayPal balance). The actual funds come from the linked card’s issuing bank.

Not Universal (Yet)

Not Immune to All Fraud

• Social engineering — Fraudsters can still trick users into adding stolen cards to their wallet
• Account takeover — If someone compromises your Apple/Google account, they may access your wallet
• Provisioning fraud — Stolen card details can be provisioned into a wallet if issuer verification is weak
• Friendly fraud — Wallet payments can still be disputed just like card payments

Understand authentication: Our 3D Secure / SCA Guide covers how Strong Customer Authentication protects digital wallet provisioning and online wallet payments.

Quick Reference: Digital Wallet Terminology

Next Steps

Now that you understand how digital wallets process payments:

1. Decode wallet transactions with the EMV Tag Inspector — parse DSRP cryptograms in Field 55
2. Parse authorization messages with the ISO 8583 Studio — see DPANs in Field 2 and contactless entry modes in Field 22
3. Understand tokenization in our Payment Tokenization Guide — the network token infrastructure behind every wallet transaction
4. Learn POS entry modes in our POS Entry Mode Guide — entry modes 07 and 91 identify wallet taps
5. Review 3D Secure in our 3D Secure / SCA Guide — how SCA applies to digital wallet enrollment and online payments
6. Look up response codes in the Reference Database — debug wallet transaction declines
7. Explore biometric payments in our Biometric Payments Guide — how FIDO2 and palm/face recognition power the next generation of contactless payments

This post is part of the ISO 8583 Mastery series. Follow along as we explore payment messaging in depth.