Card Tokenization for Tap & Pay and E-Commerce

Card tokenization is one of the most technically demanding programmes a bank can undertake. It requires coordinating a payment scheme, a card host, an SDK provider, a mobile app development partner, and the bank's own internal teams — all simultaneously, across a single shared implementation timeline that Mastercard controls.

I led this engagement as the primary product and programme coordinator on behalf of the banking client — a MENA retail bank introducing NFC Tap & Pay via its mobile banking app and Card-on-File tokenization for e-commerce. The project is live in production.

What the Programme Covers

The scope spans two distinct tokenization programmes running in parallel under Mastercard's Digital Enablement Service (MDES) infrastructure:

Issuer Wallet (Wallet 856) — NFC Tap & Pay via the bank's mobile banking app. Cardholders tokenize their Debit and Credit cards within the app and pay at POS terminals by tapping their phone. Authentication is handled via the Thales D1 SDK embedded in the app, with tokens provisioned through Mastercard MDES as the token issuer.

Remote Commerce / Merchant Card on File Tokenization (Wallet 327) — tokenization of card credentials stored by e-commerce merchants. Rather than storing raw card numbers, merchants store tokens — reducing the risk surface of Card-not-Present fraud across the bank's entire card portfolio.

The Stakeholder Landscape

This project required coordinating across five distinct organisations, each with their own technical requirements, timelines, and approval processes. Getting all five aligned — and keeping them aligned — was as much of the work as the product design itself.

The BIN Portfolio in Scope

Nine BIN ranges were onboarded across Debit and Credit card products, spanning two ICA numbers — covering the bank's full mainstream card portfolio:

How Tokenization Actually Works

The tokenization flow involves six system actors passing messages in a precise sequence. Understanding this sequence — and owning the gaps between the systems — was central to the product coordination work.

Tokenization sequence diagram — system actors and message flow

The full tokenization sequence: six system actors, twelve message exchanges, ending at Token Created. Every interface between these actors required alignment between organisations that had separate contracts, separate timelines, and separate technical environments.

The Mastercard Implementation Process

Mastercard's MDES onboarding is a structured, milestone-gated process. Nothing moves until Mastercard approves it. I was the named contact on the Mastercard Customer Implementation Services (CIS) Implementation Plan — project reference CIS-2023-03244, EEMEA region — responsible for driving each activity to completion on the bank's side.

The key milestones the bank had to own:

MDES Parameter Collection Guide completion. Offline testing with Mastercard. MDES Manager onboarding. Card design approval. Cryptographic key exchange — API Gateway Client Certificate, Customer Wrapping Key, PEPK-PESK, and ECB/CCMOut Keys. Customer test environment setup. Online testing. Production Validation Testing (PVT). Go-live.

Each of these had dependencies on the other four stakeholders. A delay in the EuroNet passthrough configuration affected the key exchange. A change in the Thales SDK integration affected offline testing. Keeping all five organisations moving in the same direction, at the pace Mastercard's timeline required, was the core coordination challenge.

Testing — What We Put It Through

The Production Testing Report (PTR) covered 64 test cases across device eligibility, tokenization flows, NFC payment transactions, token lifecycle management, and backend operations including settlement, dispute handling, reconciliation, and authorisation.

The test scope included: device eligibility checks — NFC-enabled vs non-NFC devices handled correctly; end-to-end tokenization for all 9 BIN ranges across Debit and Credit products; 1-tap and 2-tap NFC payment flows for both logged-in and session states; token lifecycle management (Active → Suspend → Active → Delete) via both Thales portal and mobile app; card image validation across all BIN ranges on tokenization and transaction success screens; and international transaction validation — a successful NFC payment was performed on a NAPS POS terminal outside Pakistan, confirming cross-border token interoperability.

Items parked for the next release were documented and tracked — not dropped. Each had a defined owner, a root cause, and a target resolution milestone. Parking a finding correctly is as important as resolving it: it keeps the go-live timeline intact without creating undocumented debt.

What Made This Hard

Token lifecycle management across five systems is harder than it appears. A token that is Active in the Thales portal can show as Disabled in the mobile app under certain conditions — which is a user-facing failure even though all systems are technically functioning correctly. Resolving these interface gaps required joint debugging sessions between Avanza (app), Thales (SDK and portal), and EuroNet (card host) — none of whom had a shared incident management process.

The cryptographic key exchange was another pressure point. MDES requires specific key types — PEPK-PESK for payment credentials, ECB and CCMOut keys for the external CMS. Each key exchange has a strict procedural requirement from Mastercard, and any error resets the clock. Getting this right required close coordination between the bank's security team, EuroNet, and Mastercard's CIS team across different time zones.

And throughout all of this, the Mastercard billing clock was running. At Tier L.3, the monthly implementation fee accrues from the first billing cycle after plan submission. Every week of delay has a direct cost. That creates a different kind of urgency than an internal project — one that has to be communicated clearly to every organisation in the chain.

Where It Landed

The programme delivered what it set out to: cardholders can tokenize their Debit and Credit cards within the bank's mobile app and pay at NFC terminals without presenting a physical card. E-commerce merchants can store tokens instead of raw card numbers, reducing fraud exposure across the bank's card portfolio. Both programmes are live in production.

What This Means for You

If your bank is planning a tokenization programme — or has been told by Mastercard that MDES onboarding is straightforward — here is what the experience actually looks like: