A few days ago, a friend saw me paying for coffee with my Apple Watch. He looked at me with a mix of curiosity and mild horror, and asked: “Do you really trust those things? Isn’t a credit card safer?”

cover

I gave him the usual “well, actually it’s quite the opposite” answer, and then I realized I had never written about this topic in depth. So here we are: a technical breakdown of what happens when you tap your card, your phone, or your watch at a payment terminal, and which of the three gives you the strongest security guarantees.

Short answer: your physical card is already solid, but Apple Pay is usually stronger from an architectural perspective.

How a contactless card actually works

Before comparing wallets, it is worth understanding what a modern contactless credit card does under the hood. The technology is called EMV (Europay, Mastercard, Visa), and “contactless” simply means the card communicates over NFC instead of requiring physical insertion. The security model is fundamentally the same.

When you tap your card, the terminal typically receives card data (including PAN, unless tokenization is used) plus a transaction-specific cryptogram. The critical security property is that the card generates a one-time value for each transaction, usually an ARQC (Authorization Request Cryptogram), computed from secret material in the chip and transaction-specific inputs (for example, amount, terminal data, and a transaction counter). The issuer can verify this cryptogram, and replay attempts fail.

This means that intercepting a tap-and-pay transaction with an NFC sniffer gives you little that is reusable. You may capture data, but you do not get a valid future cryptogram. Cloning the card the old magnetic stripe way, by copying static data, fails at chip-aware terminals. This is a major improvement over the magnetic stripe era.

That said, the physical card has one structural weakness: there is no strong authentication of the cardholder for low-value contactless transactions. If your card is lost or stolen, someone may use it below local limits until issuer or terminal rules trigger stronger verification (for example PIN, online authorization, or cumulative counters).

What Apple Pay adds to the picture

Apple Pay does not replace EMV. It extends it with additional controls at hardware and platform level.

When you add a card to Apple Pay, the issuer/network provisions a payment token (commonly called DPAN) to the device. That token, not the original PAN, is used in NFC payments and is stored in the Secure Element: a tamper-resistant component separated from the main application processor.

The payment applet inside the Secure Element generates dynamic values for each transaction. Conceptually, this is similar to EMV cryptogram logic on a physical card, with token-specific controls added by the payment network. The terminal communicates through the NFC controller, and Apple documents an important point: payment credentials used for contactless payment are isolated from the general iOS app environment.

On top of this, there is a user-authentication step before payment: Face ID, Touch ID, or passcode on iPhone; a double-click on a locked Apple Watch with wrist detection and passcode controls. This addresses the stolen-device scenario better than a plastic card used for low-value tap payments.

The combination of hardware isolation (Secure Element), per-transaction dynamic values, network tokenization (DPAN instead of PAN), and user authentication makes Apple Pay architecturally stronger than a contactless card in most practical threat models.

Google Pay: similar goals, different architecture

Google Wallet reaches broadly similar goals, but the implementation model is more heterogeneous across the Android ecosystem.

On Android, Google introduced large-scale NFC payments through Host Card Emulation (HCE): a software model where card emulation can be handled by the OS/application layer instead of a dedicated removable Secure Element. Over time, implementations have evolved and many devices now combine HCE flows with hardware-backed keystore/TEE protections and tokenized credentials.

It is a strong system, with tokenization and dynamic transaction data, and it requires user authentication before payment. The key architectural difference is that Android’s payment path depends more on OS integrity and vendor implementation details than Apple’s tightly standardized Secure Element model. On compromised or rooted devices, protections can degrade significantly. On up-to-date, non-rooted devices, practical risk remains low.

A further point is Android hardware diversity. Different vendors implement TEEs, secure hardware, and OS hardening differently. This does not make Google Wallet insecure, but it does make risk analysis more device-dependent.

The realistic threat landscape

Most attacks that matter today do not break EMV cryptography or tokenization directly. They target adjacent processes.

infographic

Relay attacks are a known concern for NFC payments. An attacker places a reader near a victim card/phone and relays communication to an accomplice at a POS terminal. NIST’s Mobile Threat Catalogue classifies this as PAY-0. In practice, strict terminal timing checks and transaction controls can make these attacks difficult, but not impossible.

Ghost Tap (described in 2024/2025 reporting, including Kaspersky’s write-up) does not break payment cryptography. It abuses provisioning and relay infrastructure: attackers steal card details and OTP through phishing/social engineering, provision the card into a wallet on an attacker-controlled phone, and relay NFC interactions (for example with tools such as NFCGate) to a second device at a POS.

This attack is effective because it bypasses wallet cryptography by abusing provisioning. If provisioning checks are weak, the attacker gets a valid tokenized wallet instance and can spend through relay-assisted flows.

Provisioning fraud is the broader issue. Both Apple Pay and Google Wallet rely on issuer provisioning controls to bind a card to a device. If an attacker passes identity checks (card data plus OTP/step-up), they can provision a stolen card and pay contactless. Mitigation is mainly in issuer-side risk controls: stronger identity proofing, better behavioral checks, and real-time anomaly detection during provisioning.

Putting it all together

The three options, ranked by technical security depth, look like this.

Option Tokenization User authentication at payment time Hardware isolation Main residual risks
Contactless EMV card Usually no wallet token (PAN-centric flow) Often weak/absent for low-value taps Chip-based EMV security, but no device-level gate Lost/stolen card misuse below local limits; social engineering on card-not-present channels
Google Wallet Yes (network tokens) Yes (device unlock/biometric/passcode) Varies by Android device and vendor hardening Provisioning fraud, rooted/compromised devices, relay-assisted abuse
Apple Pay Yes (network tokens) Yes (biometric/passcode/watch controls) Strong Secure Element isolation with tight platform integration Provisioning fraud, phishing, relay-assisted abuse

A contactless EMV card gives you per-transaction cryptograms and strong protection against simple replay and skimming abuse. Its main gap is weak cardholder verification for low-value transactions and the use of PAN-centric card data in the payment flow.

Google Wallet adds tokenization, mandatory device authentication, and good fraud controls. Compared with Apple, security outcomes are more dependent on device integrity and vendor implementation quality.

Apple Pay adds hardware-isolated credential handling in the Secure Element, strict separation from the general app processor, and a tightly controlled hardware/software stack. In architectural terms, it is usually the most robust of the three.

The key caveat is that most real-world losses do not come from breaking EMV crypto. They come from phishing, provisioning fraud, and relay-assisted abuse.

So if someone asks whether paying with a watch is safe, the technical answer is yes: in normal conditions, a modern wallet is at least as safe as a contactless card, and often safer. Practical hygiene still matters: enable instant transaction notifications, keep device OS updated, avoid rooted/jailbroken devices, and treat wallet-provisioning requests with the same caution as banking OTP requests.

What issuers should do

Wallet security depends heavily on provisioning controls. Issuers can reduce fraud materially by hardening this phase.

  • Apply risk-based step-up during wallet provisioning, not only at card enrollment.
  • Use velocity controls across channels (same card, many wallet enrollments in short windows).
  • Correlate geolocation, device reputation, and behavioral signals before approving token provisioning.
  • Require stronger checks when SIM swap, recent account recovery, or anomalous device change is detected.
  • Trigger near-real-time customer confirmation and fast revocation workflows for suspicious token activation.

What users can do in 60 seconds

  • Enable instant transaction notifications in banking app and wallet.
  • Disable contactless on cards you do not use daily, if your issuer supports it.
  • Keep phone/watch OS updated and avoid rooted or jailbroken devices.
  • Never share OTP/3DS codes, even if the request appears to come from support.
  • Review wallet device list in your account settings and remove unknown devices immediately.

Further reading: