Digital wallet payments are becoming a routine part of commerce, but the label hides very different payment models. McKinsey’s 2024 Digital Payments Survey found that 92% of US consumers had made some form of digital payment in the previous year, while in-store digital wallet adoption rose from 19% in 2019 to 28% in 2024. For businesses, the key question is not simply whether to add a wallet button. A wallet may use a tokenized card credential, linked account, or stored balance—differences that can affect authorization, settlement, refunds, disputes, and reconciliation.
This guide explains how digital wallet payments work, the main models behind them, how wallet preferences differ across markets, and what merchants should evaluate before adding them to a payment strategy.
A digital wallet payment is a transaction initiated through a software-based wallet that stores or references payment credentials, funds, accounts, or other payment sources.
Instead of manually entering payment information for every purchase, a customer may select a wallet, authenticate, and confirm the transaction.
Common examples include:
Apple Pay
Google Pay
PayPal
Alipay
WeChat Pay
GCash
PayPay
However, these services should not be assumed to work in the same way.
A wallet may:
reference a credit or debit card;
use a tokenized card credential;
connect to a bank account;
draw from a wallet balance;
support several funding sources;
operate within a wider local payment or super-app ecosystem.
This is why digital wallet is better treated as a broad payment category than as one standardized payment rail.
The terminology is not fully standardized across markets and providers.
|
Term |
Practical meaning |
|
Digital wallet |
Broad term for software that stores or references payment credentials, funds, accounts, or other digital assets |
|
Mobile wallet |
A digital wallet primarily accessed through a smartphone or wearable device |
|
E-wallet |
Common alternative term, often used for account-based or stored-value wallet services in some markets |
For merchants, the more useful question is usually not what the product is called, but what funds the payment and how the transaction is processed.
The exact flow depends on the wallet, funding source, payment provider, channel, and market. A simplified transaction can be understood in six stages.
The customer chooses an available wallet at:
online checkout;
in-app checkout;
a contactless point of sale;
a QR-based payment experience.
Depending on the wallet, authentication may involve:
Face ID or another biometric;
fingerprint recognition;
device passcode;
wallet PIN;
app-based confirmation.
Authentication helps verify access to the wallet or device, but the exact controls vary by provider.
This is where payment models begin to diverge.
The transaction may use:
a tokenized card credential;
a stored card;
a linked bank account;
a wallet balance;
another supported payment source.
For applicable card-based transactions, EMV Payment Tokenisation can replace a Primary Account Number, or PAN, with a payment token whose use can be restricted to a defined environment. That model is important, but it should not be used as a universal explanation for every digital wallet transaction.
Depending on the setup, the request may involve some combination of:
merchant;
payment service provider, or PSP;
acquirer;
wallet provider;
card network;
bank payment rail;
issuer or other funding institution.
Not every transaction includes every participant.
The relevant provider or institution evaluates the request.
For example:
an issuer may authorize a card-funded payment;
a wallet provider may validate an account or available balance;
another payment system may confirm funds and transaction status.
The merchant then receives the applicable transaction result.
Depending on the payment model, merchants may still need to manage:
capture;
settlement;
fees;
currency conversion;
refunds;
disputes;
reporting;
reconciliation.
That is why a simple wallet checkout experience can create very different operational requirements behind the scenes.
The customer may see one wallet button. The merchant may be dealing with very different infrastructure behind it.
A useful starting point is to compare three broad models.
|
Wallet model |
Simple explanation |
Typical funding source |
Merchant takeaway |
Example |
|
Card-linked wallet |
The wallet gives customers a faster way to use an existing card |
Credit or debit card |
The payment may still move through card networks and acquiring infrastructure |
Apple Pay |
|
Wallet account |
The customer pays through an account managed by the wallet provider |
Card, bank account, wallet balance, or a mix |
Refunds, reporting, and payment flows may depend on the provider |
PayPal |
|
Stored-balance wallet |
The customer pays with funds already held in the wallet |
Preloaded or stored balance |
Settlement and post-payment processes may follow wallet-specific rules |
Starbucks app |
Note: These are simplified models. Some digital wallets support multiple funding sources and may fit more than one category.
Wallet strategy is highly market-dependent.
McKinsey’s consumer research found that wallet preferences vary by both channel and geography. In the United States and Europe, device-maker wallets are important for in-store payments, but local solutions and retailer apps create different market patterns. McKinsey also found that retailer apps such as those offered by Starbucks, Walmart, and McDonald’s are more established in the United States, while some European markets have developed local account-based payment experiences.
The table below is deliberately representative rather than exhaustive. Wallet availability, product capabilities, and market position can change.
|
Region / market |
Representative payment apps or wallets |
Common pattern merchants should watch |
|
United States |
Apple Pay, Google Pay, PayPal, Venmo, retailer apps |
Strong card infrastructure; device wallets and merchant-owned apps can coexist |
|
UK, France, Germany |
Apple Pay, Google Pay, PayPal; retailer apps in selected markets |
Global wallets coexist with local and retailer-led payment experiences |
|
Nordics / parts of Benelux |
Swish, Payconiq and other local mobile payment services |
Some local solutions rely more on account-to-account infrastructure than classic card-wallet models |
|
Saudi Arabia |
urpay and other domestic wallet or app-based payment services, alongside device wallets |
Domestic wallet ecosystems and payment modernization are important considerations |
|
United Arab Emirates |
e& money, Careem Pay, device wallets |
Wallets may combine merchant payment, transfers, bills, remittance, and wider app services |
|
Mainland China |
Alipay, WeChat Pay |
Wallets are closely connected to broader digital ecosystems and QR-based experiences |
|
Japan |
PayPay and other local wallet or QR-payment services |
Local acceptance and QR-based flows can matter alongside cards and global wallets |
|
South Korea |
Kakao Pay, Naver Pay, Toss-related payment services |
Wallets can sit within wider platform and fintech ecosystems |
|
India |
PhonePe, Google Pay, Paytm |
Many popular app-based journeys use UPI bank-account rails; not every payment app is a stored-value wallet |
|
Southeast Asia |
GCash, GoPay, DANA, OVO, Touch ’n Go eWallet, TrueMoney, GrabPay |
Country-level wallet preferences are highly fragmented |
|
Latin America |
Mercado Pago and other regional or local wallet ecosystems |
Wallet growth is linked to broader fintech and retail-payment ecosystems |
McKinsey’s 2024 survey found that device-maker wallets were the most common in-store digital-payment category in both the United States and surveyed European markets. However, the same research found major local differences: retailer apps are particularly visible in the US, while solutions such as Swish in Sweden and Payconiq in Belgium illustrate stronger local account-based traditions in parts of Europe.
Strategy&’s 2025 Payments and Open Banking Survey, covering 11 countries, similarly argues that payment strategies should be tailored to individual market characteristics rather than treated as uniform across Europe.
The Middle East should not be treated as a single wallet market either. McKinsey found a strong shift toward digital payment preferences among surveyed Middle Eastern consumers, while Strategy& reported that domestic digital wallets in Saudi Arabia had attracted more than 15 million users by 2024 by its calculation.
Asia matters because app-based payments do not always follow Western card-wallet models.
EY notes that APAC has seen stronger adoption of digital wallets and super apps, while Southeast Asia is shaped by distinct country-level ecosystems. Merchants expanding into the region can explore a deeper breakdown of e-wallets in Asia Pacific and Southeast Asia and how preferences differ across markets.
Singapore shows how different models can coexist: tokenized-card wallets sit alongside PayNow, FAST, and SGQR.
India also requires careful terminology—apps such as PhonePe and Google Pay may look like wallets, but many transactions run over UPI account-to-account infrastructure rather than stored-value wallet rails.
Latin America also has strong regional fintech ecosystems. BCG’s 2025 fintech research identifies Mercado Pago among scaled regional players and highlights how Latin American fintechs have grown around retail and underbanked customer needs.
A US-based business entering a new market should not simply ask: “Which global wallets do we already support?”
A better set of questions is:
Which payment apps do customers actually use?
What funds those payments?
Does the app use card, bank, stored-value, or another rail?
Can the merchant entity accept it?
What currencies are supported?
How are refunds handled?
Who settles the merchant?
How will finance reconcile the transactions?
Digital wallet payments become easier to understand when we look at how real businesses use different payment models.
The point of these examples is not that every merchant should copy them. It is that “digital wallet” can serve very different business purposes.
Starbucks is a useful example of a merchant-controlled payment ecosystem.
Its US terms describe the Starbucks Card as a way for customers to load dollar value for future purchases at participating stores. The Starbucks app also supports payment and rewards functionality.
The model connects:
stored value;
repeat purchase;
mobile payment;
loyalty;
customer account.
For a business, the wallet is not merely a faster checkout button. It can become part of a retention strategy.
Walmart Pay takes a different approach.
Walmart’s own instructions show customers opening Walmart Pay in the Walmart app, authenticating, selecting a preferred payment method, and interacting with a QR code at the register. Walmart also documents the interaction with gift-card balances and different stored payment methods.
This model brings together:
merchant-owned app experience;
stored payment methods;
QR-based checkout;
gift cards;
digital receipts.
The merchant controls more of the customer journey without necessarily creating one single underlying payment rail.
McDonald’s provides another model.
Its US app supports Mobile Order & Pay and lists payment options including cards, Apple Pay, Google Pay, PayPal, and Venmo, subject to applicable availability and conditions.
A business does not have to build its own stored-value wallet to create a strong mobile payment experience.
It can instead:
own the ordering journey;
integrate external wallets;
retain checkout context;
give customers several ways to pay.
This is especially relevant for ecommerce and digital businesses.
|
Business |
Simplified model |
Strategic lesson |
|
Starbucks |
Stored value + loyalty |
Payments can support retention |
|
Walmart |
Merchant app + multiple funding methods + QR |
A merchant can control the checkout interface |
|
McDonald’s |
Merchant app + third-party wallets |
External wallets can sit inside a merchant-owned journey |
|
Kaufland |
Retailer app + account-linked payment + loyalty |
Wallet-like experiences can use non-card funding models |
This is the broader point: The wallet experience customers see is only the front end. The payment and business model behind it can be very different.
Digital wallets can reduce customer friction, but they do not remove payment risk or operational complexity.
Customers may avoid repeatedly entering:
card numbers;
expiration dates;
billing details.
McKinsey’s survey found that 74% of US consumers and 71% of European consumers surveyed cited easier and faster checkout as a primary reason for using digital wallets.
Customers may be more comfortable using an existing wallet, device, or local payment app than entering unfamiliar payment details.
For card-based wallet transactions using payment tokenization, merchants may interact with a payment token rather than the underlying PAN. This benefit should be described specifically rather than generalized to every wallet. EMVCo defines payment tokenization as replacing a PAN with an alternative value whose use can be constrained.
Depending on the provider, wallet experiences may support:
ecommerce;
in-app checkout;
contactless POS;
QR payments.
Attackers may target:
wallet accounts;
email accounts;
devices;
authentication credentials.
Compromised payment credentials may be added to a wallet before fraudulent transactions are attempted.
Wallet security cannot prevent every customer from being deceived into approving or initiating a fraudulent transaction.
International merchants may need to manage multiple:
providers;
technical integrations;
currencies;
customer flows;
operating rules.
Supporting more methods can create additional work around:
payment status;
refunds;
disputes;
settlement reporting;
reconciliation.
A useful merchant view is therefore: Digital wallets may simplify the customer experience while creating different operational requirements behind the scenes.
Digital wallet payments can use strong security controls, but no payment method should be described as completely secure.
For applicable card-based payments, payment tokenization can reduce exposure of the underlying PAN.
But the technical boundary matters: Not every digital wallet payment is a tokenized card payment.
An account-based or stored-value wallet may use a different security and processing model.
Encryption can help protect sensitive data during relevant stages of storage or transmission.
Wallets may use:
biometrics;
PINs;
passcodes;
device authentication;
risk-based controls.
Where payment account data is stored, processed, or transmitted, PCI DSS requirements may be relevant to the applicable environment. PCI SSC defines PCI DSS as a baseline of technical and operational requirements designed to protect payment account data.
Security should therefore be viewed as a layered system rather than a single wallet feature.
Adding digital wallet payments should start with customer and market needs rather than a list of wallet logos.
Ask:
Where are customers located?
Which channels do they use?
Which devices do they use?
Which wallets or payment apps are common in that market?
Determine whether the wallet is primarily:
card-backed;
account-based;
stored-value;
bank-linked;
hybrid.
This affects what happens after the customer confirms payment.
Businesses may need to evaluate:
PSP support;
gateway support;
acquirer coverage;
buyer country;
merchant entity location;
processing currencies;
settlement setup.
Antom is one example of this operational approach: payment methods are documented individually across availability, currencies, refund capabilities, disputes, and integration options.
Possible approaches include:
hosted checkout;
embedded checkout;
APIs;
web components;
mobile SDKs;
ecommerce plugins.
Checkout design also matters. Some solutions aim to reduce redirects by keeping more of the wallet payment journey within the merchant experience. Antom EasySafePay is one example.
The appropriate option depends on the business’s technical resources, channels, markets, and required payment methods.
A robust test plan often includes:
approval;
decline;
cancellation;
timeout;
pending status;
asynchronous notification;
duplicate-payment handling;
full refund;
partial refund where supported.
Before launch, clarify:
Who settles the merchant?
In which currency?
How are fees reported?
How are refunds matched?
How are disputes communicated?
Which identifiers link order, payment, refund, and settlement records?
There is no single universal fee schedule for digital wallet payments.
Depending on the setup, costs may include:
PSP or processing fees;
fees associated with the underlying rail;
cross-border charges;
foreign exchange costs;
integration and maintenance costs;
fraud and operational costs.
A card-funded wallet and a local stored-value wallet should not be assumed to have the same economics.
Settlement can depend on:
wallet model;
PSP;
acquirer;
wallet provider;
market;
currency;
merchant agreement.
Avoid universal claims such as: “Digital wallets settle in one to three days.”
That may be true for a particular setup, but not for the entire category.
Merchants should verify:
whether refunds are supported;
whether partial refunds are supported;
any applicable time limits;
how refund status is reported;
how refunds appear in reconciliation.
For example, records refund and partial-refund capabilities at the individual method level rather than applying one rule to every wallet.
A card-funded wallet transaction may remain subject to relevant card-scheme dispute processes.
Other wallet models may involve:
provider-specific dispute procedures;
different evidence requirements;
different consumer-protection mechanisms.
The correct workflow depends on the payment model and contractual setup.
A merchant may need to connect:
order ID;
payment ID;
provider reference;
payment status;
fee;
currency;
refund;
settlement amount;
payout record.
The customer sees a wallet button.
The merchant’s finance team may see several records.
That difference is one reason multi-wallet expansion should be treated as an operational decision, not only a checkout decision.
Antom supports 300+ payment methods across 200+ payment markets, with published acquiring coverage in 40+ markets. The goal is not to make every transaction local at any cost, but to choose the setup that best matches each market and stage of growth.
A digital wallet payment is a transaction initiated through a software-based wallet that stores or references a payment credential, account, balance, or other funding source.
The customer selects a wallet, authenticates, and confirms use of an available credential or funding source. The request then moves through the relevant payment infrastructure for authorization and, if successful, subsequent settlement and reconciliation.
Risks can include account takeover, phishing, fraudulent provisioning, compromised devices or accounts, and provider-specific vulnerabilities. Merchants may also face integration, refund, dispute, and reconciliation complexity.
Examples include payments initiated through Apple Pay, Google Pay, PayPal, Alipay, WeChat Pay, GCash, and PayPay. The underlying payment model differs by provider and market.
There is no universal industry rule defining exactly four digital payment methods. One practical grouping is:
1. cards;
2. digital wallets;
3. bank-based or account-to-account payments;
4. other alternative methods such as buy now, pay later.
Other classifications may also be valid.
It depends on the payment model and the comparison. Some card-based wallet transactions use tokenization and device authentication, which can reduce exposure of the underlying card number. Digital wallets can still face account takeover, phishing, and other fraud risks.