Table of contents

Introduction

Mobile payments are now part of everyday life. We use it to buy a beer, pay for public transport, or do our shopping. What was once an emerging technology is now something millions of people rely on daily.

Today’s major players in Europe are Apple Pay and Google Pay, launched in 2014 and 2015, respectively. In less than 10 years, the global mobile payment market has grown to $3.84 trillion in 2024, and it is projected to reach $26.53 trillion by 2032. This growth is largely driven by the convenience of the technology: it’s fast, secure, and works even when you forget your physical wallet.

But behind the simplicity and speed of mobile payments lies a complex system of technologies. From NFC enabling contactless communication to the integration of Secure Element in smartphones, multiple layers of hardware and software work together to make each transaction seamless and safe. A key part of this system is tokenization, which replaces real card numbers with virtual tokens to reduce fraud and protect user data.

This article aims to uncover what happens behind a simple tap-to-pay. Through a system engineering point of view, we will explore the role of NFC, the architecture of mobile payment systems, and the security mechanisms that protect users. Let’s reveal the sophisticated ecosystem behind an everyday gesture.

NFC Technology

What is NFC?

NFC stands for Near Field Communication. It is a short-range wireless communication technology that allows two devices to exchange data when they are very close: usually less than 4 centimeters apart.

NFC operates at a radio frequency of 13.56 MHz, using electromagnetic induction between two coils. It is based on the same principles as RFID (Radio-Frequency Identification), but with more advanced communication protocols and built-in security features.

NFC provides low-speed data transfer (106 to 848 kbit/s) with a simple setup, making it ideal for quick interactions like contactless payments.

A device using NFC can operate in one or more of the following three modes:

  • Reader/Writer Mode: The device reads or writes data to NFC tags.
  • Peer-to-Peer Mode: Two NFC-enabled devices exchange data directly, like sharing files or contacts.
  • Card Emulation Mode: The device acts like a contactless smart card, this is the mode used for payments.

Each NFC communication involves two parts: the initiator, which starts the exchange, and the target, which responds.

Communication can be:

  • Active: both the initiator and the target generate their own radio fields.
  • Passive: only the initiator generates the field, the target is powered by this field (e.g., building access badge with no battery).

Use cases

You probably use NFC regularly without thinking about it.

Common examples include:

  • Access control: tap a badge to enter a building or office.
  • Public transport: tap your card to access metro, tram, or bus.
  • Device pairing: connect headphones or speakers quickly via Bluetooth using NFC.
  • Payments: tap-to-pay with your phone or contactless card.
  • And more…

Limitations

Despite its convenience, NFC has several limitations:

  • Very short range: both devices must be very close, often within 4 cm.
  • Low bandwidth: not suitable for large data transfers like videos or files.
  • Security risks: without proper authentication, an attacker near you (like in a crowded metro) could potentially communicate with your device.

NFC Communication stack

Like many communication technologies, NFC is structured in layers. Below is the stack specific to card emulation mode, used in mobile payments.

If you’re curious, the full NFC protocol stack across all modes (reader/writer, peer-to-peer) can be found here.

1. Physical Layer

How is energy and data transmitted through the air ?

  • Uses a 13.56 MHz radio frequency.
  • Operates over very short distances (< 4cm).
  • Transfers energy via electromagnetic induction.

How are bits sent and identified ?

  • Manages modulation, anti-collision, and error detection.
  • Ensures only one NFC session is active at a time.
  • Defined by the ISO/IEC 14443 standard (commonly used by contactless smartcards).

3. Transport Layer

How is a card emulated by the phone ?

  • This is where the smartphone emulates a card, using either:
    • A Secure Element (SE) – hardware-based
    • Or Host Card Emulation (HCE) – software-based
  • Follows the EMV Contactless specifications (by EMVCo, used by Visa, Mastercard, etc.).
  • Manages Application Protocol Data Units (APDUs) exchanged during transactions.

4. Application Layer

What service is being used and how is it secured?

  • Handles security, authentication, and tokenization.
  • Interfaces with apps like Google Pay, Apple Pay, or Samsung Pay.
  • This is where payment logic, card selection, and user verification happen.

Types of Mobile Payments

To understand how mobile payments work, we need to explore the two main ways a smartphone can emulate a payment card when communicating with a terminal via NFC.

These two architectures are:

  • Host-based Card Emulation (HCE)
  • Secure Element (SE)–based emulation

Both follow the EMV (Europay, Mastercard, and Visa) standard, which defines how transactions should work between cards, terminals, and banks.

The main difference lies in where the card logic and sensitive operations are executed: in the phone’s main processor (CPU) or inside a dedicated secure chip (SE).

Host-based Card Emulation (HCE)

With HCE, the smartphone simulates a contactless card entirely in software. All transaction logic, including generating cryptograms and managing card data, is executed by the phone’s main CPU (the “host”). The card credentials and tokens may be stored locally (encrypted) or fetched dynamically from cloud storage.

Pros:

  • No hardware dependency: works on most modern Android phones (at least with NFC chip).
  • Easy to deploy and update: ideal for banks or fintechs developing their own wallet apps, though it may come with limitations due to vendor lock-in, especially on Apple devices.

Cons:

  • Security depends on the OS: the phone’s operating system and sandboxing must be robust.
  • More attack surface: malware on the phone could potentially interfere or spy on the payment logic.

Google Pay uses HCE on most Android devices. It stores dynamic tokens securely and uses the Trusted Execution Environment (TEE) or Android Keystore to protect keys and isolate processes when possible.

Secure Element (SE)

With SE-based architecture, the smartphone contains a dedicated hardware chip that handles all sensitive operations. This Secure Element (SE) is isolated from the main operating system and is tamper-resistant. It stores card credentials, generates cryptograms, and handles cryptographic operations, all without exposing sensitive data to the rest of the device.

The SE is connected to the NFC controller, and during a transaction, the controller routes all commands directly to the SE. The host CPU and wallet app only receive non-sensitive results, such as the transaction status.

There are three types of Secure Elements:

  • Embedded SE: soldered directly onto the smartphone’s motherboard.
  • UICC SE: uses the SIM card as a secure element.
  • External SE: less common, added via accessories like SD cards or secure dongles.

Pros:

  • High security: data never leaves the chip, resistant to physical and software attacks.
  • Trusted by banks: SEs are often certified by EMVCo, payment networks, and regulatory authorities.

Cons:

  • Requires hardware support: limited to devices that include a Secure Element.
  • Less flexible: harder to update or modify remotely.

Apple Pay uses SE-based architecture. All recent iPhones include a hardware Secure Element, which stores encrypted card information and manages transactions without exposing data to iOS or apps.

A step-by-step analysis of a transaction

When you pay with your smartphone using a solution like Google Pay, Apple Pay, or Samsung Pay, everything seems instant. But in the background, there is a standardized sequence that ensures the transaction is both fast and secure. This section walks through the full flow of a mobile payment.

Two standards define the communication and behavior during the transaction:

  • ISO/IEC 14443: Defines low-level contactless communication (physical layer, radio frequency characteristics, anticollision, frame structure, etc.).
  • EMV Contactless: Defines payment-specific logic (transaction flow, command structure, cryptographic exchange, etc.).

Card registration

Before you can pay, your card must be registered in the wallet app.

One key technology used here is tokenization, which protects the user by replacing the real card number with a device-specific virtual token. This token is what will be used later for transactions, the real card number is never used.

1. Card entry

The user enters card data (PAN, expiration date, CVV) manually or by scanning the card.

2. Tokenization request

  • The wallet app sends the card details to the wallet provider (Apple/Google).

  • The provider forwards it to the payment network (Visa, Mastercard).

  • The network contacts the issuing bank.

  • If the bank authorizes, it asks a Token Service Provider (TSP) to create:

    • A DPAN (Device Primary Account Number): a virtual card number unique to this device.
    • DCVV (Dynamic CVV) generation rules: a dynamic cryptographic code used in place of static CVV.

  • Those informations are sent back to the wallet provider.

3. User authentication

To complete registration, the user must authenticate (SMS code, bank app approval, etc.) depending on the bank’s policy.

4. Finalization

Once validated:

  • On iPhones, the DPAN and keys are stored in the Secure Element.
  • On Android, they may be stored in the SE, TEE, or Android Keystore depending on the device and HCE implementation.

Transaction flow

1. Payment initialization

  • The user unlocks the phone using PIN, fingerprint or Face ID.
  • The wallet app retrieves the stored DPAN and prepares for the transaction.

2. NFC Field Detection

  • The terminal powers the NFC field.
  • The phone detects the field and enters Card Emulation mode.
  • The phone and terminal communicate using APDU (Application Protocol Data Units).

3. Application Selection

  • The terminal asks the phone to select a supported payment application (APDU command: SELECT AID, AID stands for Application Identifier).
  • The NFC controller routes the request to the SE (or CPU in HCE).

4. Negotiation of capabilities

  • The terminal sends a GPO (Get Processing Options) APDU.
  • The phone replies with supported features: online/offline, cryptographic options, etc.

5. Data and Cryptogram exchange

  • The terminal sends READ RECORD commands to retrieve static card data (card issuer, expiration date, etc.).
  • Then it sends a GENERATE AC command with:
    • Terminal info
    • Amount
    • Currency
    • And more…
  • The SE (or CPU) signs this data using stored keys and returns an Application Cryptogram.
  • After this step, the phone can be removed from the reader. All necessary data has been exchanged. Steps above has been done in less than a few seconds.

6. Online Authorization

  • The terminal sends the cryptogram and transaction data to the merchant’s bank.
  • It’s routed through: Payment Network → TSP (Token Service Provider) → Issuing Bank.
  • The TSP maps the token (DPAN) to the real card and forwards it to the bank.
  • The bank authorizes or declines the transaction and sends back the result.

7. Completion

  • The terminal displays the result and prints the receipt.
  • The wallet app may query the SE to display transaction details to the user.

Key components

Component Type Description
NFC Chip Hardware Manages NFC communication. Acts as a router: it forwards APDU commands between the payment terminal and either the Secure Element or the Host CPU. Follows ISO/IEC 14443 standard.
Secure Element (SE) Hardware Tamper-resistant chip that stores payment credentials and handles cryptographic operations. Can be embedded (eSE), on SIM (UICC), or external.
Host CPU Hardware Executes the wallet app and card emulation logic in HCE mode. Manages communication if no SE is present.
Trusted Execution Environment (TEE) / Secure Enclave Hardware + Software Isolated execution zone within the CPU. Protects cryptographic keys and sensitive operations from the main OS. Android uses TEE, iOS uses Secure Enclave.
OS NFC Service Software (OS-level) System component responsible for handling NFC events, permissions, routing logic, and coordinating between the NFC controller and applications.
Wallet Application Software (User-level) UI/UX layer allowing users to enroll, manage, and select cards. Also interacts with the SE or HCE service during transactions. Examples: Apple Wallet, Google Wallet.
EMV Contactless Protocol Stack Protocol Standard from EMVCo that defines how the phone behaves like a contactless EMV card (APDUs, cryptograms, transaction steps). Implemented in both SE and HCE.
Tokenization Service Cloud Replaces the real card number with a unique, limited-use token. Managed by Visa, Mastercard, Apple, Google, or banks. Critical for securing transactions.
Payment Network Cloud Visa, Mastercard, etc. Handle card validation, cryptogram checks, and send transaction results back to the terminal or bank.
Issuer Bank Cloud The cardholder’s bank. Validates the token, processes the payment request, and returns the final authorization decision.

Security considerations

Mobile payment solutions rely on multiple layers of protection, from hardware isolation to real-time cryptographic validation, to ensure that each transaction is legitimate, safe, and authorized.

On top of the EMV process, additional protections often depend on geographic regulations. Globally, standards like PCI-DSS apply, while in Europe, PSD2 enforces strong customer authentication and open banking rules.

Multi-layered security

1. Hardware and software isolation

  • With SE-based payments (like Apple Pay), all sensitive operations (including token storage, key management, and cryptographic calculations) take place within a tamper-resistant Secure Element, physically isolated from the main OS.
  • With HCE-based payments (like Google Pay on many Android devices), operations are handled in software but protected by OS-level mechanisms such as the Trusted Execution Environment (TEE) and Android Keystore, providing strong isolation and secure memory.

2. Tokenization

  • Instead of transmitting your real card number (PAN), mobile wallets use a token (DPAN).
  • This DPAN is mapped to your real card number via a Token Service Provider (TSP) but is useless if intercepted: it cannot be reused without the correct device-specific context and cryptographic keys.

3. Dynamic cryptograms

  • For each transaction, a unique cryptographic value (such as the Application Request Cryptogram - ARQC) is generated.
  • This ensures that even if someone intercepts the transaction data, it cannot be reused for fraudulent purposes, preventing replay attacks and card cloning.

4. User authentication

  • Before initiating a payment, the wallet may require user authentication (biometric scan, PIN, or password) to verify the cardholder’s identity.
  • This adds an additional layer of protection if the phone is lost or stolen.

5. Limited communication range

  • NFC requires devices to be within a few centimeters of each other, which makes it difficult for attackers to eavesdrop or intercept data.
  • This proximity requirement is a natural security barrier, reducing the risk of man-in-the-middle attacks.

Potential attacks and mitigations

Attack Type Description Mitigations
Skimming An attacker gets close enough to your device or card to trigger an unintended NFC transaction. Disable NFC when not in use. Use RFID-blocking wallets for physical cards. Mobile payments should require user authentication.
Secure Element Tampering Attempts to physically extract cryptographic keys or data from the Secure Element. Tamper-resistant hardware, encrypted internal communication, keys are non-exportable.
Eavesdropping / Relay Attack Capturing or forwarding NFC data in real time between a legitimate device and a storekeeper’s terminal. Strict timing constraints, dynamic cryptograms and proximity limits.
Malware Malicious software attempts to steal sensitive payment data, credentials, or tokens. Avoid untrusted apps and suspicious links. Keep software updated.
Cloning Attempting to copy the card signal or emulate it for reuse. Not feasible due to dynamic cryptography and tokenization. See this other article from the blog: Why your contactless credit card can’t be cloned?
Token Reuse / Replay Reusing previously captured tokenized transaction data to perform a fraudulent payment. Every transaction includes a one-time cryptogram (ARQC).
Phone Theft A stolen phone is used to make unauthorized payments. Device authentication (PIN, biometrics) and wallet lock.

Privacy

When you pay with your smartphone, your actual card number is never shared with the storekeeper. Instead, a virtual token (DPAN) and a transaction specific cryptogram are used, both of them are useless outside their original context.

  • With SE-based payments (e.g., Apple Pay), this data is stored and generated locally on a Secure Element. It never leaves the device.
  • With HCE-based payments, some information can be stored on the cloud (e.g., Google servers), with protections like TEE and key management to ensure security.

Why NFC mobile payments are safer than contactless credit cards ?

Contrary to popular belief, mobile payments using NFC are generally more secure than using a traditional contactless credit card.

A physical card contains static informations (card number, name, expiration date, CVV) that can be easily stolen if the card is lost. A mobile wallet never reveals these details. It uses dynamic tokens, requires biometric authentication, and can be remotely disabled. Additionally, mobile devices benefit from advanced security mechanisms like Secure Enclaves (iOS) and TEE (Android).

In short, stealing a phone is not enough to perform a mobile payment whereas stealing a card often is.

Conclusion

Mobile payment is part of everyday life. From tapping your phone at a store to paying for public transport, it feels easy and instant. But behind this simple gesture lies a complex system that brings together hardware, secure software, and global standards to ensure each transaction is safe and fast.

In this article, we explored how it all works. The starting point is NFC: the short-range wireless technology that allows devices to exchange information when close together. But the real complexity lies in how the phone processes payment information securely using two main architectures: Host-based Card Emulation (HCE) and Secure Element (SE).

HCE relies on the phone’s operating system and is flexible and easy to use on many Android phones. SE, on the other hand, uses a dedicated chip to store and process sensitive data, offering stronger protection, this is the model used by Apple Pay. Both follow the EMV protocol, which is the global standard for credit card transactions.

We also went through the full transaction flow, from registering a card to tapping at checkout. Each step, from biometric authentication to cryptographic checks, happens in just seconds.

A key part of mobile payment security is tokenization. Instead of sending your real card number, the system creates a token, which is only valid on your device. Even if someone intercepts this token, they can’t use it without the cryptographic context and protections tied to your phone.

Security is built into every layer of the transaction flow. The Secure Element (or TEE in HCE), dynamic cryptograms, user authentication, and short communication range all work together to prevent fraud. In many cases, mobile payments are more secure than traditional credit cards, which can be stolen or used more easily.

What’s next?

As technology continues to evolve, ways we pay will also continue to evolve.

Emerging payments methods are:

  • Biometric payments: using facial recognition or biometrics for checkout without device.
  • Wearables and IoT: watches, rings, or other objects becoming secure payment devices.
  • Invisible payments: for example, exiting a supermarket triggers seamless and invisible payment.

Bibliography