Wallets & Alternative Rails / Learning brief
Digital wallets, explained: pass-through versus staged
Your notes
In simple terms / 01
What this means in plain language
A digital wallet is a container for a way to pay, but not all wallets work alike. Pass-through wallets present a tokenised version of an existing card so the payment runs on the card rails; staged wallets take an in-wallet payment first, then pay the merchant separately. Knowing which kind you are looking at explains who the merchant is really paid by, where the funds pause, and what the device actually stores.
A digital wallet is software on a phone, watch, or browser that stores a way to pay and presents it at checkout. Not all wallets work the same way. A pass-through wallet hands an underlying card credential — normally a device token, or DPAN (device primary account number) — straight to the merchant, so the payment runs on the card rails exactly like an ordinary card tap; the wallet holds no money. A staged wallet is different: it first pulls money into a balance of its own, then pays the merchant from that balance as a separate step. The two shapes settle differently, expose different data, and put the merchant's real counterparty in a different place, which is why the first question about any wallet is which of the two you are looking at.
Key takeaways / 03
Three things to remember
- 01
A pass-through wallet presents a device token to the merchant, so the money moves on the card rails as an ordinary card payment.
- 02
A staged wallet funds its own balance first and then pays the merchant separately, so the merchant's counterparty is the wallet operator, not the card.
- 03
Device tokenisation means the phone stores a DPAN, not the real card number, plus a one-time code for each tap.
Practical use cases / 04
Where you would use this
An operations analyst tracing a disputed wallet payment checks whether it was pass-through (handled as a card chargeback) or staged (a claim against the wallet operator).
A merchant weighing wallet acceptance compares the settlement timing and data it will see from a pass-through wallet against a staged one.
A screening team maps which party it can actually see — the cardholder for a pass-through wallet, the wallet operator for a staged one.
Worked example / 05
Put the idea into a real situation
(SYNTHETIC / TRAINING ONLY) Maya Chen adds her Bank Alfa card to her phone. The phone does not store the card number; it stores a DPAN provisioned through the card network. At Demo Coffee Ltd she taps, and the phone presents the DPAN plus a one-time cryptogram. Because this is a pass-through wallet, the payment runs to Meridian Bank as acquirer, out to the network, and on to Bank Alfa as issuer, which authorises against Maya's real account — a normal card payment wearing a wallet's clothes. Had she instead topped up a EUR 20.00 balance in a staged wallet and paid Demo Coffee from that balance, the shop's counterparty would have been the wallet operator, and the card would have seen only the funding step.
Operational sequence / 06
Follow the message and decision path
This compact sequence is a learning model. Exact routing and rulebook behavior can vary by scheme, participant, and implementation.
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.
- 02MessageMaya taps her phone to payMaya Chen (phone wallet) → Demo Coffee Ltd (terminal)
Maya authorises on the device with a fingerprint or face check — the on-device strong customer authentication — and the wallet presents the DPAN plus a one-time cryptogram for this EUR 42.50 order, never the real card number.
- 03MessageThe terminal sends an authorisation request on the tokenDemo Coffee Ltd (terminal) → Meridian Bank (acquirer) · 0100 authorisation request (ISO 8583)
Demo Coffee's terminal packs the DPAN, cryptogram, amount and merchant details into an authorisation request and sends it to Meridian Bank, its acquirer. The merchant only ever handles the token, not Maya's PAN.
- 04MessageMeridian Bank routes the request to CardnetMeridian Bank (acquirer) → Cardnet (card network) · 0100 authorisation request (ISO 8583)
The acquirer forwards the tokenised authorisation request into the card network so it can be detokenised and routed on to the right issuer.
- 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.
- 06MessageCardnet forwards the detokenised request to Bank AlfaCardnet (card network) → Bank Alfa (issuer) · 0100 authorisation request (ISO 8583)
With the real PAN restored, Cardnet routes the authorisation request to Bank Alfa, the account's actual issuer.
- 07MessageBank Alfa approves and respondsBank Alfa (issuer) → Cardnet (card network) · 0110 authorisation response
The issuer checks the real card account — is it open, do funds cover EUR 42.50, does the risk score pass — and answers with an approval and an authorisation code, sent back through Cardnet.
- 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
Evidence & review / 07
Evidence & review
Consumer mobile and device wallets that carry cards or account credentials; not specific to any one wallet brand or card scheme.
What this brief simplifies: Wallet brands are described as two structural types; real wallets can blend behaviours. The device tokenisation walkthrough compresses provisioning and does not show every cryptographic step. All amounts and parties are synthetic.
Sources for this brief3
- Market practiceMarch 2003 edition
A glossary of terms used in payments and settlement systems ↗ — CPSS (now CPMI), Bank for International Settlements · Definitions: electronic wallet, payment token
Terminology has evolved since this edition; newer CPMI publications refine some definitions.
- Official requirement
PSD2 and the RTS on strong customer authentication and secure communication ↗ — European Banking Authority · RTS on SCA and secure communication: possession + inherence on the device
Referenced from the European Banking Authority's public summaries, guidelines, and technical standards on payment services.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal · Pass-through vs staged framing; synthetic cast and amounts
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.