Apple Pay and Google Pay without the marketing: network tokens and fraud reduction

When a customer clicks the Apple Pay or Google Pay button on an online store, they are not sending their sixteen-digit card number or expiry date. Nor is it a simple visual shortcut that auto-fills payment form fields. What executes between the browser or mobile app, the hardware provider's servers, and the card networks is a cryptographic architecture designed to isolate the underlying card credentials.

Understanding how these digital wallets operate under the hood allows businesses to objectively assess their technical impact on authorization rates, processing costs, and protection against unauthorized transactions.

From FPAN to DPAN: the provisioning phase

To understand what travels across the wire in each transaction, two core concepts must be distinguished:

• FPAN (Funding Primary Account Number): The actual number printed on the physical plastic card or generated in online banking. The cardholder enters this number only once when provisioning their device.
• DPAN (Device Primary Account Number) or Network Token: An alternate identifier issued directly by the card schemes (Visa, Mastercard, or American Express) at the request of Apple or Google. This token replaces the FPAN and is bound exclusively to that specific hardware or user account.

When a user adds a card, the issuing bank verifies their identity—typically via an SMS one-time password or in-app approval—and authorizes the card scheme to issue the network token. From that moment on, the original FPAN remains stored in the secure vaults of the payment schemes and is never transmitted during day-to-day purchases.

Unlike proprietary tokens generated by payment gateways, which we explored in detail when explaining card tokenization, network tokens are recognized across the entire payments ecosystem and do not depend on a specific payment gateway.

Dynamic cryptograms: why intercepted tokens cannot be reused

A static surrogate number on its own would not solve security challenges in card-not-present environments; if an attacker intercepted a DPAN, they could attempt to submit it elsewhere. The true security barrier lies in the one-time cryptogram.

For every purchase completed through Apple Pay or Google Pay, the device's secure hardware element (the Secure Element on iOS devices or equivalent secure runtime environments on Android) generates a dynamic cryptogram. This cryptographic payload is derived from a private key stored on the device, the transaction amount, the currency code, and a non-repeatable transaction counter.

When the payment gateway receives this payload, it passes it through the acquiring chain to the card scheme. The network validates that the cryptogram matches that specific DPAN, for that exact amount, at that precise moment. If malicious actors were to capture payment traffic and attempt a replay attack on another merchant site, the transaction would be rejected instantly because the cryptogram would already be expired or invalid.

Biometric authentication and the liability shift

Within the European Economic Area, regulatory frameworks mandate strong identity verification to combat digital fraud. Apple Pay and Google Pay handle this natively via on-device biometrics (Touch ID, Face ID, or fingerprint authentication) or device passcode validation.

From a compliance standpoint, this local two-factor verification directly satisfies the requirements for Strong Customer Authentication (SCA). Because the transaction carries both a scheme-verified cryptogram and authenticated biometric proof, a liability shift occurs: should the transaction turn out to be unauthorized, the merchant is generally shielded against a fraud-related chargeback, with the issuing bank absorbing the financial loss.

Operational benefits over manual card entry

Beyond mitigating identity theft and unauthorized transactions, the network token architecture delivers two concrete operational advantages:

• Decoupled card lifecycle: When a physical card is lost, stolen, or expires, the card scheme automatically updates the mapping between the newly reissued FPAN and the existing DPAN on the device. Customers do not need to update their payment details manually, eliminating failed payments caused by expired cards.
• Reduced checkout friction: Because cardholders are not redirected to an external bank interface to complete a standard 3D Secure challenge, payment funnel drop-offs decrease significantly while retaining full legal protection.

Practical conclusion

Supporting Apple Pay and Google Pay on a website or mobile application is not merely a user interface enhancement; it represents a structural improvement in how payment data is secured and processed. Replacing manual card numbers with scheme-level tokens and single-use cryptograms systematically curbs card theft, shifts dispute liability to card issuers, and removes the friction of expired card renewals.