Digital wallets and network tokenization
How a card becomes a stand-in number on your phone: pass-through versus staged wallets, device tokenisation, and the DPAN journey behind a tap.
L0 Explain simply
An everyday analogy: a digital wallet is a cardholder for cards. When Maya Chen adds her Bank Alfa card to her phone, she is not copying the card into the phone — she is asking the card world for a stand-in number that only this phone may use. From then on the phone pays with that stand-in, called a DPAN (a device account number), plus a fresh one-time code for each tap. Two shapes of wallet exist. A pass-through wallet simply presents that stand-in card to the shop, so the payment still runs on the card rails exactly as a plastic tap would. A staged wallet first pulls money into an account of its own, then pays the shop separately — two steps, staged. At Demo Coffee Ltd, Maya's tap is a pass-through wallet at work. (SYNTHETIC / TRAINING ONLY — every person and firm named here is fictional.)
L1 Core concepts
A digital wallet stores payment credentials on a device and presents them to pay. The distinction that matters for how money moves is pass-through versus staged. A pass-through wallet holds a network token — a DPAN issued through the card network under EMVCo's tokenisation specification and bound to one device — and presents it in a normal card authorisation; the wallet never holds the money, and the issuer authorises against the real PAN behind the token. A staged wallet does two separate legs: it funds a stored balance, often by an account-funding-transaction, then makes its own payment to the merchant, so the merchant sees the wallet, not the card. The wallet-provider is the party that runs the wallet and, for device wallets, acts as a token-requestor — the entity that asks the network's token service for a DPAN and vouches for the enrolling cardholder.
L2 Practitioner view
The practitioner's lens is where risk and data sit. Device-tokenization binds the DPAN to a specific phone and to per-transaction cryptograms, so a token lifted from one device should not authorise from another — the domain controls are the defence, not secrecy of the number. That moves the fraud problem to enrolment: the weak point of wallet provisioning is the identity check done when a card is first added, which is where issuers apply step-up strong-customer-authentication. For a pass-through wallet, disputes, chargebacks and interchange behave as for any card payment, because it is a card payment; the wallet is a presentation layer. For a staged wallet the picture differs: the card sees only the funding leg to the wallet, and the shop's real counterparty is the wallet operator, which changes who bears risk and who holds the customer's transaction data. A blunt caution: 'tap to pay' hides all of this, so always ask which shape of wallet you are actually looking at.
L3 Technical details
Strictly speaking, the DPAN is a real number in its own right, not an encryption of the PAN: the network's token vault holds the PAN-to-DPAN mapping, and the issuer still authorises on the underlying account. Provisioning runs a defined handshake — the token-requestor submits the card and cardholder evidence, the issuer or its agent returns an approve, a decline, or a step-up decision often reported as a colour-coded risk band — and only then is the DPAN activated and delivered to the device's secure element or host-based store. Because the credential lives under strong-customer-authentication duties, the device unlock (biometric or passcode) is what the issuer treats as the possession-plus-inherence check for later payments, which is why a wallet payment can meet SCA without a separate challenge. The honest edge: a network token is only as trustworthy as that first enrolment, so provisioning fraud — adding someone else's card to an attacker's phone — is the attack that domain controls cannot fix on their own.
Sources & standards3
- Official requirement
PSD2 and the RTS on strong customer authentication and secure communication ↗ — European Banking Authority
Referenced from the European Banking Authority's public summaries, guidelines, and technical standards on payment services.
- Market practiceMarch 2003 edition
A glossary of terms used in payments and settlement systems ↗ — CPSS (now CPMI), Bank for International Settlements
Terminology has evolved since this edition; newer CPMI publications refine some definitions.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
SEE THE PAYMENT MOVE
Read the steps as text
- 01ProcessingThe card was already tokenised onto the deviceMaya Chen (phone wallet)
Before any purchase, the wallet asked a token requestor to swap Maya's real card number (the PAN) for a device token (a DPAN) tied to this phone. The DPAN lives on the device; the real PAN never does.
- 05ProcessingCardnet checks the token domain and detokenisesCardnet (card network)
The network verifies the cryptogram and confirms the DPAN is being used within its allowed domain — this device, this kind of transaction — then maps the DPAN back to the real PAN so the right issuer can be reached.
- 08SettlementThe purchase settles in the card cycleBank Alfa (issuer) → Meridian Bank (acquirer)
In the daily clearing and settlement cycle the approved purchase settles between Bank Alfa and Meridian Bank in central bank money. Only now does money actually move between the two banks.
- DR Bank Alfa settlement account — EUR 42.50
- CR Meridian Bank settlement account — EUR 42.50
- 09PostingBank Alfa posts the debit to Maya's real accountBank Alfa (issuer)
The issuer books the EUR 42.50 debit against Maya's real card account — the account behind the DPAN. Her statement shows the purchase against the real card, not the device token.
- DR Maya Chen's card account at Bank Alfa — EUR 42.50
- 10PostingMeridian Bank pays out to Demo CoffeeMeridian Bank (acquirer)
The acquirer credits Demo Coffee's merchant account for the sale, net of fees. The payment is complete end to end: token presented, detokenised, authorised, settled, and both sides posted.
- CR Demo Coffee merchant account at Meridian Bank — EUR 42.50
Sources for this topic3
- Official requirement
PSD2 and the RTS on strong customer authentication and secure communication ↗ — European Banking Authority
Referenced from the European Banking Authority's public summaries, guidelines, and technical standards on payment services.
- Market practiceMarch 2003 edition
A glossary of terms used in payments and settlement systems ↗ — CPSS (now CPMI), Bank for International Settlements
Terminology has evolved since this edition; newer CPMI publications refine some definitions.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
Deepest material on this page: L3 — Technical details. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.