Category: Payment Ecosystem
Digital Wallet
Also known as: e-wallet, mobile wallet
Simply put
A digital wallet is a software application or online service, typically running on a smartphone, tablet, or similar device, that stores a user's payment information so they can pay without a physical card. Users can add credit cards, debit cards, or bank account details and then make purchases in stores, in apps, or online, often by tapping their device at a payment terminal. Familiar examples include Google Wallet and similar mobile payment applications.
Formal definition
A digital wallet is a software application, online service, or electronic device that stores payment credentials and enables a party to initiate payments in card-present (for example, contactless tap-to-pay at a terminal), in-app, or card-not-present contexts. Wallet implementations vary in how they store and transmit credentials, and the handling of underlying cardholder data and any sensitive authentication data determines applicable security controls; readers should assess PCI DSS scope based on the specific implementation, credential storage model, and validation rather than the 'digital wallet' label alone. The evidence provided describes wallets at a functional level and does not specify the tokenization, encryption, or authentication mechanisms used by any particular wallet, so those details should be confirmed against the relevant provider documentation and current PCI standards.
Why it matters
Digital wallets have become a common way for consumers to pay in stores, in apps, and online, storing card and bank account details in a single application on a smartphone, tablet, or similar device. For merchants, acquirers, and processors, this shift changes where payment credentials live and how they move through a transaction, which in turn affects how security controls are applied. Because wallet implementations vary in how they store and transmit credentials, the presence of a digital wallet in a payment flow does not by itself determine what cardholder data or sensitive authentication data an organization touches; that depends on the specific implementation.
Who it's relevant to
Merchants and merchant risk teams
Merchants that accept digital wallet payments in stores, in apps, or online need to understand how each wallet integration affects the payment data they handle. Because the security properties and credential storage models vary by implementation, risk teams should evaluate each acceptance channel individually rather than treating all wallets the same.
Compliance officers and QSAs
Those responsible for PCI DSS scoping should base their assessment on how a specific wallet implementation stores and transmits cardholder data and any sensitive authentication data, not on the wallet label. Applicable requirements should be confirmed against the current published PCI standards, since requirement numbering and wording differ between versions.
Acquirers and payment processors
Acquirers and processors handling wallet-initiated transactions across card-present, in-app, and card-not-present contexts need clarity on how credentials flow through their environments. The differing implementation models mean control expectations should be determined per integration and validated against provider documentation and current standards.
Security engineers
Engineers designing or integrating wallet acceptance should identify what payment credentials pass through or are stored in their systems for each implementation. Because the evidence here does not specify tokenization, encryption, or authentication mechanisms for any particular wallet, those details must be confirmed with the provider before designing supporting controls.
Inside Digital Wallet
Wallet credential store
The component that holds payment credentials on behalf of the user. Depending on implementation, this may store a device-specific token rather than the underlying PAN, or may reference credentials held server-side. The distinction affects whether cardholder data is present and how PCI DSS scope applies.
Tokenized payment credential
Many digital wallets present a network or payment token in place of the PAN at transaction time. Tokenization substitutes the PAN with a surrogate value and is distinct from encryption; its effect on scope depends on the tokenization approach and how it is validated, not on the label alone.
Device or user authentication mechanism
The wallet typically gates access with a device unlock, biometric, or passcode. This is a form of authentication local to the wallet and is separate from network-level authentication such as 3-D Secure or EMV chip authentication that may occur during the transaction.
Transaction cryptogram or dynamic data
Wallet transactions may generate dynamic, per-transaction data intended to help reduce replay and reuse of static credentials. This mechanism is intended to mitigate certain risks but does not by itself eliminate fraud.
Provisioning and identity binding process
The steps by which a card is added to the wallet, including issuer verification of the cardholder. This process is intended to reduce the risk of unauthorized card provisioning, though its rigor varies by implementation and issuer.
Common questions
Answers to the questions practitioners most commonly ask about Digital Wallet.
Does a digital wallet mean the merchant no longer handles cardholder data or falls out of PCI DSS scope?
Not automatically. The effect of a digital wallet on PCI DSS scope depends on the implementation and how the payment credential is processed, transmitted, and stored, not on the wallet label itself. Some wallet integrations tokenize the underlying PAN so that the merchant handles only a token or a network token rather than the primary account number, which may reduce scope. Other integrations may still expose the merchant's systems to cardholder data. Scope reduction should be confirmed against your specific integration and validated, and you should confirm requirements against the current published PCI DSS.
Is a digital wallet the same thing as tokenization, and does using one guarantee that no card data is ever stored?
No. A digital wallet is a consumer-facing method of storing and presenting payment credentials, while tokenization is a data-transformation technique that substitutes a sensitive value such as a PAN with a token. Many wallets use tokenization, but the two are distinct concepts, and tokenization is not the only way data may be represented. A wallet also does not by itself guarantee that no card data is stored; that depends on the architecture, the parties involved, and how each component is implemented and validated. Sensitive authentication data must not be stored after authorization regardless of the wallet used.
How do I determine whether my digital wallet integration reduces my PCI DSS scope?
Trace the flow of the payment credential end to end and identify where cardholder data or a token enters, is transmitted through, and rests within your environment. If your systems only ever receive and handle a token rather than the PAN, scope may be reduced, but this depends on the specific integration and must be validated rather than assumed. Document the data flows, identify all system components that store, process, or transmit account data, and confirm the applicable requirements against the current published PCI DSS. Where a service provider handles part of the flow, clarify the division of responsibility.
What should I confirm about the token a digital wallet passes to my systems?
Clarify what type of token you receive and how it behaves, because tokens differ. Determine whether it is a network token, a payment token tied to a specific merchant or transaction context, or another form, and understand its scope of use, its lifecycle, and whether it can be reversed to the PAN and by whom. Also confirm whether the value is subject to the same storage and protection expectations as cardholder data in your environment. These characteristics affect both your risk and how the integration maps to the applicable PCI DSS requirements, which should be verified against the current standard.
How does a digital wallet interact with authentication controls during a transaction?
A digital wallet may participate in device-level and cardholder authentication, but it does not replace the distinct authentication mechanisms that operate at different points in a transaction. Depending on the implementation, wallet transactions may involve device authentication, cryptographic credentials, and network flows that can carry authentication data, and card-not-present flows may still involve 3-D Secure or strong customer authentication where applicable. These controls address different risks and no single one eliminates fraud, so evaluate which mechanisms your specific wallet integration actually invokes rather than assuming coverage.
What responsibilities remain with the merchant when using a digital wallet through a service provider?
Even where a service provider or wallet operator handles significant portions of the payment flow, the merchant retains responsibility for the parts of the environment and processes under its control and for validating the applicable PCI DSS requirements. Establish a clear division of responsibility with each party, document which requirements each side addresses, and obtain evidence of the other parties' validation where relevant. Do not treat outsourcing as removing all obligations, and confirm the current requirement wording against the published PCI DSS, since numbering and wording differ between versions.
Common misconceptions
A digital wallet always stores the full card number on the device.
Many wallets store a device-specific token or reference rather than the PAN. Whether actual cardholder data is present depends on the implementation. When tokenization is used and validated appropriately, the data handled at the device may differ from a stored PAN, which can affect PCI DSS scope.
Because a wallet uses tokenization, it is automatically out of PCI DSS scope and equivalent to encryption.
Tokenization, encryption, truncation, masking, and hashing transform data in different ways. Tokenization substitutes a surrogate value while encryption reverses with a key; the effect on scope depends on implementation and validation, not the label. A wallet's use of tokens does not by itself remove an entity's PCI DSS obligations.
Biometric unlock on a wallet prevents fraud.
Device or biometric authentication is one control that gates local access and may help reduce unauthorized use, but it addresses a different point in the transaction than 3-D Secure, EMV chip authentication, or network-level strong customer authentication. No single control eliminates fraud, and account takeover or first-party fraud can still occur.
Best practices
Determine and document whether the wallet handles PANs or only tokens/device references, and confirm the resulting PCI DSS scope against the current published standard rather than assuming a fixed requirement number.
Never store sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, or PIN blocks after authorization, even when encrypted, regardless of the wallet's tokenization approach.
Validate the tokenization implementation on its technical and process merits rather than relying on the label, and confirm how it affects scope with the appropriate standard and, where relevant, your assessor.
Layer authentication controls appropriately, recognizing that device or biometric unlock, 3-D Secure, EMV chip authentication, and strong customer authentication address different risks at different points and should not be treated as interchangeable.
Assess the provisioning and identity-binding process with issuers to help reduce unauthorized card enrollment, while accounting for residual account takeover and first-party fraud risk.
Confirm liability, chargeback, and dispute handling for wallet-based transactions against current card brand and network rules, noting these vary by region and change over time.