The principle: a tokenized card, not a new payment method
A payment wallet is an app that stores an existing payment instrument and presents it at checkout. Apple Pay and Google Pay are therefore not payment methods but layers on top of the card. When a card is added to the wallet, the real PAN, known as the FPAN or Funding PAN, is replaced by a DPAN or Device PAN, a payment token tied to that device. The token is issued by the scheme's TSP (Token Service Provider): Visa Token Service (VTS) or Mastercard MDES.
For each transaction, the wallet generates a single-use dynamic cryptogram linked to the DPAN. Even if intercepted, the DPAN and cryptogram are useless: the token is locked to one device (and sometimes one channel), and the cryptogram works only once. The merchant, its PSP, and the acquirer never see the FPAN. Only the TSP can “detokenize” it to send the transaction to the issuer.
{
"applicationPrimaryAccountNumber": "4809 12xx xxxx 2345",
// ^ DPAN: the device token, NOT the customer's actual card
"applicationExpirationDate": "291231",
// ^ token expiration date (independent of the card's)
"currencyCode": "978", // EUR (ISO 4217)
"transactionAmount": 4250, // EUR 42.50 in cents
"onlinePaymentCryptogram": "Af5DGAsWQEIzTQMoJENrPg==",
// ^ unique dynamic cryptogram, verified by the TSP/issuer
"eciIndicator": "7"
// ^ secure e-commerce indicator
}Secure Element vs. HCE: two security architectures
There are two ways to store a token's cryptographic keys on a smartphone. A Secure Element is a dedicated secure chip, isolated from the operating system. This is the approach Apple chose. HCE, or Host Card Emulation, emulates the card in software and keeps the keys in the cloud. Google adopted HCE in 2013 to get around the control that mobile carriers had over Secure Elements.
| Criterion | Secure Element (Apple Pay) | HCE (Google Pay) |
|---|---|---|
| Key storage | Certified hardware chip (eSE), isolated from the OS | OS + cloud: limited-use keys (LUKs), renewed periodically |
| Resistance if the OS is compromised | Very high: the OS never sees the keys | Lower in theory, offset by LUK rotation and integrity attestation |
| Offline payments | Unlimited (keys stored on the device) | Limited to the preloaded keys (a few transactions) |
| Platform control | Historically closed: only Apple Pay could use the iPhone's NFC chip | Open: any banking app can use HCE on Android |
| Certification | EMVCo + schemes (hardware) | EMVCo + schemes (software + back end) |
For years, only Apple Pay could use the iPhone's NFC chip. A European Commission antitrust case (AT.40452) ended that exclusivity. In July 2024, Apple committed to opening NFC access to third-party wallets in the EEA through HCE, starting with iOS 17.4. European banks and wallets, including Wero and banking apps, can now offer their own contactless payments on the iPhone without going through Apple Pay.
Enrollment: the weak link
ID&V (Identification & Verification) is the check an issuer runs before a token is provisioned to confirm that the person making the request is the cardholder. It is triggered every time a card is added to a wallet. The issuer decides how strict the check is based on the risk score attached to the request.
Fraud rates on mobile payments peaked because of fraudulent enrollments. They came down as issuers tightened ID&V. In these frauds, the transaction cryptography, sound by design, is never broken: the fraudster obtains a legitimately issued token and a valid cryptogram. A wallet's security therefore depends on the verification performed at enrollment, not on the strength of its transaction cryptography.
Three payment journeys: contactless, in-app, and web
| Flow | Merchant integration | Authentication | SCA / 3DS | Impact on conversion |
|---|---|---|---|---|
| Contactless at the POS terminal | None (standard NFC) | Device biometrics (CDCVM) | SCA met by CDCVM, no PIN | Faster lines; no friction on purchases over €50 |
| In-app | SDK / PSP | Device biometrics | 3DS usually unnecessary: SCA is already met (cryptogram + CDCVM) | 20% to 40% higher conversion than a card form (PSP studies) |
| Web | JS button / PSP | Biometrics on the phone or Touch ID | Same as in-app | Much lower mobile cart abandonment |
The business model: who pays what?
Merchants pay no specific fee to accept Apple Pay or Google Pay. The transaction is billed like any other card payment, at the same MSC. Any fee for the wallet is charged on the issuer side, to the bank that issued the tokenized card.
| Digital wallet | Who pays? | How much (ballpark) | Logic |
|---|---|---|---|
| Apple Pay | The card issuer | About 0.15% per credit card transaction in the US; lower rates negotiated in Europe (not public, in the range of a few basis points) | Apple monetizes access to its user base and (historically) to NFC |
| Google Pay | No one directly | No issuer fee | Indirect model: aggregated usage data, lock-in to the Android ecosystem |
| Samsung Pay | No one directly | No fee in Europe | Hardware differentiation; MST (magnetic stripe emulation) has been dropped |
For merchants, the net effect is positive on three fronts. Express checkout, with no card details to type, delivers higher conversion. Because issuers approve more tokenized transactions, which carry stronger authentication, wallet payments get a higher authorization rate. The dynamic cryptogram and biometrics mean less fraud and fewer chargebacks. Apple's issuer fee, on the other hand, fuels a lasting conflict with banks. It also drove the forced opening of NFC in Europe, which lets banks bypass that fee.
Adoption in 2024–2026 and the competitive landscape
France was long a laggard in mobile payments, because consumers were attached to their PIN and contactless limits were low. It has since caught up with the European average, and mobile payments there have grown by more than 50% a year since 2022. Apple Pay leads the NFC segment by value. Google Pay is growing with the Android installed base, and banking-app wallets (Paylib in the past, HCE apps going forward) have taken advantage of the opening of NFC on iOS.