GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX
FOLLOW THE PAYMENT

Tokenized wallet payment

Maya Chen pays Demo Coffee Ltd from a phone wallet. The device presents a network token (a DPAN), not her real card number; Cardnet detokenises it before Bank Alfa authorises. (SYNTHETIC / TRAINING ONLY)

Your notes
Tokenized wallet payment — interactive diagramMaya Chen pays Demo Coffee Ltd from a phone wallet. The device presents a network token (a DPAN), not her real card number; Cardnet detokenises it before Bank Alfa authorises. (SYNTHETIC / TRAINING ONLY) The full step-by-step description follows this diagram as text.1. Provisioned2. DPAN + crypto3. 0100 token4. 0100 routed5. Detokenise6. 0100 detokenised7. 0110 approve8. Card cycle9. DR card acct10. CR merchant
STEP 1 / 10INTERNAL

The card was already tokenised onto the device

Maya 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.

Step 1 of 10: The card was already tokenised onto the device

  1. 01Processing
    The card was already tokenised onto the deviceMaya Chen (phone wallet)
  2. 02Message
    Maya taps her phone to payMaya Chen (phone wallet) → Demo Coffee Ltd (terminal)
  3. 03Message
    The terminal sends an authorisation request on the tokenDemo Coffee Ltd (terminal) → Meridian Bank (acquirer) · 0100 authorisation request (ISO 8583)
  4. 04Message
    Meridian Bank routes the request to CardnetMeridian Bank (acquirer) → Cardnet (card network) · 0100 authorisation request (ISO 8583)
  5. 05Processing
    Cardnet checks the token domain and detokenisesCardnet (card network)
  6. 06Message
    Cardnet forwards the detokenised request to Bank AlfaCardnet (card network) → Bank Alfa (issuer) · 0100 authorisation request (ISO 8583)
  7. 07Message
    Bank Alfa approves and respondsBank Alfa (issuer) → Cardnet (card network) · 0110 authorisation response
  8. 08Settlement
    The purchase settles in the card cycleBank Alfa (issuer) → Meridian Bank (acquirer)
  9. 09Posting
    Bank Alfa posts the debit to Maya's real accountBank Alfa (issuer)
  10. 10Posting
    Meridian Bank pays out to Demo CoffeeMeridian Bank (acquirer)
MESSAGECLEARING OBLIGATIONSETTLEMENTPOSTING
Full step-by-step text (works without JavaScript)
  1. 01Processing
    The 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.

  2. 02Message
    Maya 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.

  3. 03Message
    The 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.

  4. 04Message
    Meridian 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.

  5. 05Processing
    Cardnet 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.

  6. 06Message
    Cardnet 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.

  7. 07Message
    Bank 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.

  8. 08Settlement
    The 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 accountEUR 42.50
    • CR Meridian Bank settlement accountEUR 42.50
  9. 09Posting
    Bank 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 AlfaEUR 42.50
  10. 10Posting
    Meridian 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 BankEUR 42.50

What this simplifies: A pass-through wallet where the device token stands in for the card. Real tokenisation adds a token service provider, provisioning identity checks, and per-scheme domain rules. Cardnet is fictional; the amount is illustrative.

Sources for this flow3
  1. Official requirement

    PSD2 and the RTS on strong customer authentication and secure communicationEuropean Banking Authority · RTS on SCA — on-device authentication

    Governs open banking access in the European Union, including payment initiation and account information services offered by third-party providers, and the requirement for strong customer authentication. · Checked 2026-07-13

    Referenced from the European Banking Authority's public summaries, guidelines, and technical standards on payment services.

  2. Market practiceMarch 2003 edition

    A glossary of terms used in payments and settlement systemsCPSS (now CPMI), Bank for International Settlements

    Standard definitions for payment, clearing, and settlement terminology used across BIS committee reports and referenced by glossary entries on this site. · Checked 2026-07-12

    Terminology has evolved since this edition; newer CPMI publications refine some definitions.

  3. Simplified educational illustration

    Payments Signal editorial teaching modelsPayments Signal

    This site's own simplified teaching models. · Checked 2026-07-12

    What this simplifies: One wallet, one acquirer, one issuer; dual-message processing. Wallet-provider agreements, staged-wallet funding, provisioning identity checks and per-scheme token rules are omitted; Cardnet is fictional and the amount is illustrative.

    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.

COMMUNITY SIGNAL

Discuss this learning page

Share an operational observation or ask a concrete payments question. Your name and message are public; your email remains private.

NEXT QUESTION REVIEWMonday, 27 Jul, 8:00 amMonday answer runs use source-supported educational material. Some questions may need owner review.
WHAT ARE YOU SHARING?

Public discussion

LOADING

Loading the discussion…