Category: Payment Ecosystem

Mobile Payments

Also known as: mobile money, mobile money transfer, mobile wallet

Simply put

Mobile payments are financial transactions made using a portable device such as a smartphone, tablet, or wearable instead of cash, a physical card, or a check. They let users pay for goods and services, or send money, digitally through the device. The term covers a range of payment processing services delivered through mobile technology.

Formal definition

Mobile payments refer to payment processing services that enable transactions to be initiated and completed through mobile devices such as smartphones, tablets, and wearables. Implementations vary widely and may include in-person acceptance, online payments, and person-to-person money transfer, often via mobile wallet applications. Because the term describes a delivery channel rather than a single technology or control, the applicable security requirements, cardholder data handling, and PCI DSS scope depend on the specific architecture used (for example, whether the device captures, transmits, or stores account data, and whether tokenization, encryption, or other controls are applied); readers should evaluate each implementation against the current published standards rather than assuming a uniform control set.

Why it matters

Mobile payments have become a mainstream way for consumers to pay for goods and services in person, online, and to send money to one another. Because the term describes a delivery channel rather than a single technology, it spans a wide range of implementations, each with its own security characteristics. This variability matters for security and compliance teams: the risks and controls that apply to a wearable tapping a contactless terminal differ from those of a mobile wallet application transmitting account data over the internet, or a person-to-person transfer app.

For payment security purposes, the critical question is not whether a transaction is labeled a mobile payment, but how the specific architecture handles account data. Whether the mobile device captures, transmits, or stores cardholder data, and whether tokenization, encryption, or other controls are applied, drives the applicable requirements and the PCI DSS scope. Two apps described identically to a consumer may sit in very different positions relative to sensitive authentication data handling and cardholder data protection obligations. Treating mobile payments as a uniform category can lead teams to under- or over-scope their compliance efforts.

Because implementations evolve quickly and vary across regions and platforms, organizations should evaluate each mobile payment deployment on its own terms against the current published standards rather than assuming a fixed control set. The label alone does not establish which data is present, where it flows, or which safeguards are validated.

Who it's relevant to

Merchants and Merchant Risk Teams

Merchants adopting mobile payment acceptance—whether in person, online, or across channels—need to understand how their chosen implementation handles account data before assuming a given compliance posture. The specific architecture, including whether the device captures, transmits, or stores account data and whether tokenization or encryption is applied, determines the applicable controls and scope.

Compliance Officers and QSAs

Because mobile payments describe a delivery channel rather than a single technology, compliance professionals should scope each deployment individually against the current published standards rather than applying a uniform control set. Determining how and where cardholder data flows through the mobile solution is central to establishing accurate PCI DSS scope.

Payment Processors and Acquirers

Processors and acquirers supporting mobile payment products serve a range of use cases, including in-person acceptance, online payments, and person-to-person transfer. Understanding the varied architectures and data-handling behaviors across these implementations helps in assessing the security requirements associated with each.

Security Engineers

Engineers designing or integrating mobile payment functionality should assess how the device and application capture, transmit, or store account data, and which controls such as tokenization or encryption are in place. These design decisions, not the mobile payment label, drive the security requirements and the effect on cardholder data handling.

Inside Mobile Payments

Mobile Wallet (Digital Wallet)

A software application on a mobile device that stores payment credentials, often as tokens rather than the actual PAN. Examples include OEM wallets and issuer or merchant wallets. The wallet typically presents a device-specific token during a transaction rather than the underlying cardholder data.

Tokenization in Mobile Payments

Substitution of the PAN with a surrogate value, frequently a device-bound or domain-restricted token, so the real PAN is not transmitted or stored on the device. Tokenization differs from encryption, truncation, and masking; whether it reduces PCI DSS scope depends on the specific implementation and validation, not the label alone.

Near Field Communication (NFC) / Contactless

A short-range communication technology used to present payment credentials at a physical point of interaction. In mobile contactless transactions, credentials such as a token are exchanged with the terminal, typically leveraging EMV contactless specifications for card-present style acceptance.

In-App and Card-Not-Present Mobile Payments

Payments initiated within a merchant application or mobile browser where the physical card is not presented. These are generally treated as card-not-present transactions and may carry different fraud exposure and network rules than card-present acceptance.

Device Authentication and Cardholder Verification

Mechanisms such as device passcodes, biometrics, or on-device verification used to authorize use of stored credentials. These may contribute to multi-factor or strong customer authentication objectives but address different risks than EMV chip authentication or 3-D Secure, and no single control eliminates fraud.

Sensitive Authentication Data Considerations

Full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks are sensitive authentication data that must not be stored after authorization, even when encrypted. This constraint applies to mobile acceptance and provisioning flows just as to other channels.

Applicable PCI Standards

Depending on the role, mobile payment environments may involve PCI DSS for cardholder data environments, and separate standards such as the PCI Software Security Framework for software, PCI PIN or PCI P2PE where relevant, and PCI 3DS for 3-D Secure components. These are distinct standards governing different controls.

Common questions

Answers to the questions practitioners most commonly ask about Mobile Payments.

Does using a mobile wallet mean the merchant no longer handles cardholder data and is automatically out of PCI DSS scope?

Not automatically. Mobile wallets often use tokenization and device-based cryptography that can reduce the exposure of the primary account number (PAN), but whether a merchant's environment is in or out of PCI DSS scope depends on the specific implementation and how the transaction data flows, not on the label 'mobile wallet.' Any system that stores, processes, or transmits cardholder data, or that can affect the security of that data, may remain in scope. Merchants should validate scope against the current published PCI DSS rather than assuming the wallet removes their obligations.

Do mobile payment methods eliminate payment fraud because they use tokens and biometrics?

No. Tokenization and device-level authentication are intended to reduce certain risks, such as exposure of the PAN or unauthorized device use, but they do not eliminate fraud. Different fraud types, including account takeover, first-party or friendly fraud, and synthetic identity fraud, can still occur, and detection controls carry false-positive and false-negative trade-offs. No single control prevents fraud; mobile payment security is layered and addresses specific risks at specific points in a transaction.

How should we determine PCI DSS scope for a mobile payment acceptance solution?

Start by mapping how cardholder data and any sensitive authentication data flow through the mobile application, the device, and any connected systems, including where data is captured, transmitted, and whether it is ever stored. The transformation techniques applied, such as tokenization, encryption, or truncation, affect scope based on how they are implemented and validated, not on the label alone. Confirm scope determinations against the current published PCI DSS and consult your acquirer or a qualified assessor where the boundaries are unclear.

What is the difference between tokenization and encryption in a mobile payment context?

Encryption transforms data using a key so it can be reversed by an authorized party holding that key, while tokenization replaces a value such as the PAN with a surrogate token that typically has no mathematical relationship to the original and requires a separate mapping to recover it. Truncation and masking reduce or hide portions of data, and hashing produces a one-way representation. Each has a different effect on data exposure and on PCI DSS scope depending on how it is implemented and validated, so the technique should be assessed rather than assumed from its name.

Which authentication controls apply to a mobile payment transaction, and what does each address?

Different controls address different risks at different points. Device-level authentication such as biometrics or a passcode helps confirm the user of the device. For card-not-present flows initiated from a mobile app, 3-D Secure may be applied to help authenticate the cardholder to the issuer, and strong customer authentication requirements may apply depending on region and applicable rules. Multi-factor authentication may protect access to accounts or administrative systems. These controls are complementary and none, on its own, addresses every fraud scenario.

How do we handle sensitive authentication data in a mobile payment application?

Sensitive authentication data, which includes full track data, card verification values such as CAV2/CVC2/CVV2/CID, and PINs or PIN blocks, must not be stored after authorization, even in encrypted form. This constraint applies to mobile applications and their supporting systems as it does to other channels. Some cardholder data, such as the PAN, may be retained only under defined controls, so design the application to avoid persisting prohibited data and confirm handling requirements against the current published PCI DSS and any related standards that govern PINs or software security.

Common misconceptions

Because a mobile wallet uses a token instead of the card number, the transaction is automatically out of PCI DSS scope.

Tokenization can reduce scope, but the effect depends on how tokens are generated, stored, mapped, and validated in a given implementation, not on the presence of the word token. Scope determination should be based on the actual data flows and validated against the current standard.

Biometric device authentication on a phone prevents payment fraud.

On-device verification may help reduce certain fraud, such as unauthorized device use, but it addresses different risks than EMV chip authentication, 3-D Secure, or network-level controls. No single authentication mechanism eliminates fraud, and card-not-present and account takeover risks may remain.

A contactless mobile transaction and an in-app mobile purchase carry the same fraud and liability treatment.

Contactless acceptance is generally handled as card-present, while in-app or browser purchases are typically card-not-present. Fraud exposure, liability shift, and chargeback treatment are governed by card brand and network rules that vary by region and change over time.

Best practices

Map the actual data flows for each mobile acceptance channel and confirm which cardholder data or sensitive authentication data is transmitted, processed, or stored before assuming any scope reduction from tokenization.

Ensure sensitive authentication data, including full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks, is never retained after authorization in any part of the mobile flow, even in encrypted form.

Identify which PCI standards apply to your role and components, distinguishing PCI DSS from the PCI Software Security Framework, PCI PIN, PCI P2PE, and PCI 3DS, and apply each to the controls it governs.

Validate tokenization, encryption, truncation, and masking implementations independently rather than relying on the label, since their effect on scope and data protection depends on how they are deployed and validated.

Treat contactless and in-app mobile transactions according to their card-present or card-not-present classification, and confirm current card brand and network rules for the relevant region regarding liability and chargebacks.

Layer authentication controls, recognizing that device verification, EMV chip authentication, 3-D Secure, and multi-factor or strong customer authentication address different risks, and evaluate detection controls for their false-positive and false-negative trade-offs.

Confirm all requirement references against the current published version of the applicable standard, since numbering and wording differ between versions.