Digital & Emerging Payments

Digital Payments, Wallets & Open Banking

The digital payments landscape has expanded dramatically — from NFC contactless and OEM wallet provisioning to network tokenisation, open banking APIs and ISO 20022 real-time rails. FinPay Consultants provides practitioner-level advisory across every layer of the digital payments stack, helping issuers, fintechs and processors implement, certify and optimise digital payment capabilities.

The Digital Payment Landscape

Digital payment methods now account for the majority of consumer transactions in developed markets — and the architecture underpinning each method carries significant technical depth. Understanding the provisioning flows, token lifecycles and authentication frameworks across these channels is critical for any issuer or processor entering or expanding their digital offering.

Mobile Wallets: Apple Pay, Google Pay & Samsung Pay

OEM wallets provision a device-specific token (DPAN — Device Primary Account Number) in the device's Secure Element or Host Card Emulation (HCE) environment. The token is distinct from the cardholder's actual PAN (FPAN — Funding Primary Account Number), protecting the FPAN from exposure at the point of interaction. Provisioning flows involve the cardholder-triggered add-card action, the issuer identity verification step (ID&V) — which may be green, yellow or red path depending on issuer risk scoring — and the secure delivery of the token credential to the device. Each OEM wallet operates its own Token Service Provider (TSP) — Apple uses MDES (in partnership with Mastercard) and VTS (for Visa cards), Google Pay similarly calls MDES or VTS depending on the card scheme, and Samsung Pay uses its own Samsung Token Service which routes to scheme TSPs.

Network Tokenisation: MDES & VTS

Network tokenisation replaces the FPAN with a scheme-managed token — the DPAN for device-bound use cases or the COF token (Credential on File) for merchant-stored credentials. Token types by use case:

  • Device token (DPAN): Bound to a specific device's Secure Element or HCE; used for NFC/contactless and in-app payments via OEM wallets.
  • COF token (eCommerce): Stored by a merchant or payment service provider in place of the FPAN; enables recurring billing, subscription payments and one-click checkout without transmitting the real card number.
  • Provisioned token: Issued to a token requestor (bank, fintech, wallet) for their specific integration — carries token requestor ID (TRID) that routes authorisation to the correct FPAN at the issuer.

QR Code Payments: EMV QR

EMV QR (defined under the EMVCo QR Code Specification) supports two interaction models — Consumer-Presented Mode (CPM) and Merchant-Presented Mode (MPM):

  • CPM: The consumer's wallet app generates and displays a QR code containing payment credentials; the merchant scans the code. Common in transit and closed-loop retail environments.
  • MPM: The merchant's terminal or display generates a static or dynamic QR code; the consumer scans with their wallet app. Widely deployed for micro-merchant and QR-code-at-counter scenarios across Asia-Pacific and emerging markets.

EMV QR data is encoded per ISO 18004 using a tag-length-value (TLV) structure. MPM dynamic QR codes embed transaction-specific data — amount, merchant reference, transaction timestamp — enabling per-transaction verification and preventing replay attacks that affect static QR deployments.

Open Banking & PSD2

The EU Payment Services Directive 2 (PSD2) mandated open access to payment account data and payment initiation capabilities through standardised APIs, enabling two new licence categories:

  • PISP (Payment Initiation Service Provider): Third parties authorised to initiate payments directly from the customer's bank account — bypassing card rails entirely for account-to-account (A2A) payment flows.
  • AISP (Account Information Service Provider): Third parties authorised to access payment account data for aggregation, financial management and credit decisioning.

SCA (Strong Customer Authentication) requirements under PSD2 mandate two-factor authentication for electronic payments above defined thresholds — combining knowledge, possession and inherence factors. SCA exemptions (low-value transactions, trusted beneficiaries, corporate payments) require technical implementation at the issuer ASPSP level. TPP (Third Party Provider) onboarding requires qualification through an eIDAS certificate authority and registration in the relevant national regulatory sandbox or production directory.

NFC & Contactless Payments

EMV Contactless: VSDC vs. M/Chip Advance Contactless

Both Visa and Mastercard define their own contactless application specifications built on the ISO/IEC 14443 contactless communication standard and the EMVCo contactless framework:

  • VSDC Contactless (Visa): Visa's contactless application, processed via Kernel 3 of the EMVCo Contactless Kernel Specifications. VSDC contactless transactions use a Cryptogram Version Number (CVN) and a dedicated ARQC generation algorithm. Online-capable VSDC contactless transactions carry a full TC/ARQC cryptogram; offline-only transactions at transit gates use a reduced data set with an offline-approved flag.
  • M/Chip Advance Contactless (Mastercard): Mastercard's contactless application, processed via Kernel 2. M/Chip Advance supports both online and offline contactless modes, with the issuer's chip profile configuring the CVM List and contactless transaction limits. M/Chip Advance uses Application Cryptograms (ACs) for transaction authentication — the AC type (ARQC, TC, AAC) communicates the card's decision outcome to the issuer host.

Kernel differences matter for terminal certification and card personalisation: Kernel 3 and Kernel 2 have distinct Application Identifier (AID) structures, PPSE selection logic and Offline Data Authentication (ODA) requirements. Cards supporting both schemes carry both AIDs — terminal kernel selection at PPSE determines which contactless application is invoked.

PPSE — Proximity Payment System Environment

PPSE (2PAY.SYS.DDF01) is the EMV contactless application directory — the first SELECT command issued by a contactless terminal to enumerate available payment applications on a card or device. The PPSE response contains a list of ADF (Application Definition File) entries, each with an AID, application label and optional priority indicator. Application selection logic — governed by both the terminal's supported kernel list and the card's priority order — determines which payment application is selected when multiple AIDs are present. Incorrectly configured PPSE entries are a common cause of contactless interoperability failures during scheme certification.

CDCVM — Consumer Device CVM

CDCVM (Consumer Device Cardholder Verification Method) allows the consumer's device biometric or PIN — unlocking the OEM wallet — to serve as the CVM for a contactless payment, replacing the need for a separate PIN entry at the terminal. When CDCVM is performed successfully prior to the tap:

  • The wallet sets the CDCVM bit in the transaction data sent to the terminal.
  • The terminal's CVM list processing recognises CDCVM as a valid CVM outcome and does not prompt for terminal-side PIN.
  • CDCVM enables higher contactless transaction limits — many issuers apply lower limits to no-CVM contactless transactions (e.g., £100) but allow higher limits (e.g., £500+) when CDCVM is confirmed.

CDCVM is critical to the premium contactless UX in OEM wallets — without it, high-value tap-and-go transactions would require a separate PIN entry that defeats the speed advantage of contactless.

Express Transit & Zero-Amount Tap

Transit use cases — metro, bus, barrier tap — impose stringent latency requirements (typically <500 ms transaction completion) that preclude online authorisation at the point of tap. Both Visa (XpressWay / Transit Express) and Mastercard (Transit Express) define programmes for offline or deferred-auth transit acceptance:

  • Zero-amount pre-authorisation: The transit terminal sends a zero-amount tap to the issuer to validate card validity without an amount. The issuer responds with an ATQC (Authorisation Transit Quick Code) or equivalent approval flag. Subsequent boarding taps within a defined session window proceed without individual online authorisations, accumulating a deferred balance settled at end of journey or end of day.
  • ATQC handling: The issuer must configure ATQC response generation and the card profile must be personalised with transit-specific CVM configuration (typically CVM=No CVM for transit) to enable no-PIN, no-signature transit taps below scheme-defined floor limits.
  • Aggregated clearing: Transit acquirers submit aggregated clearing records covering multiple taps per journey — the clearing record carries the total journey fare, not individual boarding amounts. Issuers must handle the clearing amount differing from any individual zero-amount tap authorisation.

Scheme Token Services: VTS & MDES

Network tokenisation is now a core capability for any issuer or payment service provider operating in digital channels. FinPay Consultants provides end-to-end advisory on VTS and MDES integration — covering token requestor onboarding, provisioning flow implementation, token lifecycle management and issuer host integration.

VTS — Visa Token Service

VTS is Visa's network tokenisation platform. Key VTS concepts for issuers and token requestors:

  • TAVV (Token Authentication Verification Value): A cryptographic value generated per-transaction by the VTS token — analogous to the CVV2 for the token domain. The TAVV is included in the authorisation request and validated by VTS during de-tokenisation, binding the payment credential to the specific transaction and device session.
  • Token Requestor IDs (TRID): Each entity that registers with VTS to request tokens (merchants, wallets, payment facilitators) is assigned a unique TRID. The TRID is included in authorisation messages, enabling issuers to identify which wallet or merchant originated the token-based transaction and apply appropriate fraud or authorisation logic.
  • Token lifecycle management: Tokens are created, suspended, resumed and deleted via VTS lifecycle APIs. Issuers receive lifecycle event notifications — enabling issuer-side account profile updates (e.g., when a token is provisioned to a new device by the cardholder).

MDES — Mastercard Digital Enablement Service

MDES is Mastercard's token service, supporting both OEM wallet provisioning and merchant/COF tokenisation. The MDES provisioning flow uses a traffic-light model to determine the identity verification path:

  • Green Path: The issuer's ID&V scoring — based on device risk, account history and cardholder verification data — is sufficient to approve provisioning automatically with no additional step-up. The token is provisioned directly to the requesting wallet.
  • Yellow Path: The issuer requires additional ID&V before provisioning. Common yellow-path methods include OTP (one-time password) sent via SMS or email, in-app push notification to an already-authenticated banking app, or call centre verification. Yellow path is the most common provisioning outcome for first-time device provisioning on new cards.
  • Red Path: The issuer declines provisioning — the risk score or rule evaluation indicates fraud risk or the cardholder's account status precludes digital wallet use. A red path response must include a reason code; if the decline is a false positive (common for legitimate new customers), it creates a significant cardholder friction event and is tracked by Mastercard as part of provisioning decline rate monitoring.

In-App vs. OEM Wallet Provisioning

In-app provisioning embeds the wallet experience within the issuer's own mobile banking application — the cardholder adds their card to Apple Pay or Google Pay directly from within the bank's app, leveraging the app's existing authenticated session for ID&V. This typically results in higher green-path rates and lower provisioning abandonment. OEM wallet provisioning (initiated from the Wallet app directly, without the issuer app context) relies on MDES/VTS risk scoring without the benefit of the issuer's authenticated session, leading to higher yellow-path rates.

BNPL & Alternative Payment Methods

BNPL Integration Patterns

Buy Now Pay Later products have become a mainstream payment method, particularly in e-commerce. Two primary integration architectures exist, each with distinct technical and commercial implications:

  • Redirect-based BNPL: At checkout, the consumer is redirected to the BNPL provider's hosted page (or presented with an embedded iframe) for eligibility assessment and instalment selection. The merchant receives a payment confirmation reference; the BNPL provider settles the full transaction amount to the merchant (less fees) and manages the instalment collection from the consumer. Redirect integration is simpler to implement but introduces checkout friction and conversion loss at the redirect step. Providers: Klarna, Afterpay, Laybuy.
  • API-based (inline) BNPL: The BNPL eligibility check and plan selection occur inline within the merchant's checkout — typically via a JavaScript widget or server-side API call — without redirecting the consumer away from the merchant site. API-based integration requires deeper technical engagement (tokenised payment credentials, webhook event handling for payment status updates) but significantly reduces checkout friction and typically improves conversion rates by 15–30% versus redirect integration.
  • Card-based BNPL: Increasingly, BNPL functionality is being delivered through scheme-network rails using virtual card numbers or instalment-enabled physical cards — Visa Instalments, Mastercard Instalment Lending Service (MILS). This model enables BNPL at any card-accepting merchant without merchant-side integration, with instalment logic managed at the issuer or processor level.

Real-Time Payments & ISO 20022

Account-to-account real-time payment schemes are disrupting traditional card-rail dominance in bill payment, P2P transfers and increasingly at point-of-sale. Technical foundations:

  • ISO 20022 pacs.008: The FI-to-FI Customer Credit Transfer message format — the standard clearing instruction for real-time payment schemes including SEPA Instant Credit Transfer, FedNow and many central bank-operated real-time rails. pacs.008 carries rich structured remittance data (creditor, debtor, purpose codes, ultimate originator/beneficiary) that enables straight-through reconciliation at the receiving institution — a key differentiator over legacy ISO 8583-based card clearing.
  • SWIFT gpi (Global Payments Innovation): SWIFT's tracked and confirmed cross-border payment service, overlaid on the correspondent banking network. gpi provides end-to-end payment status tracking via the Unique End-to-End Transaction Reference (UETR), same-day value commitment and remittance data integrity — addressing the opacity and delays of legacy correspondent wire transfers.
  • Regional real-time schemes: SEPA Instant (EU, max €100k, 10-second clearing), FedNow (US, launched 2023, maximum $500k initial limit, ISO 20022-native), and UPI (India's Unified Payments Interface — now processing over 10 billion transactions per month, with cross-border integration via bilateral agreements with Singapore's PayNow and other ASEAN schemes). Each scheme carries distinct API specifications, confirmation message formats and dispute frameworks — FinPay Consultants supports issuers and PSPs through connectivity assessment, API integration and scheme membership requirements.
The convergence of card and A2A rails: Visa and Mastercard are actively acquiring and building real-time account-to-account payment capabilities — Visa's acquisition of Earthport and investments in open banking, Mastercard's acquisition of Vocalink (operator of Faster Payments in the UK). The strategic direction points toward a hybrid payments future where card and A2A rails co-exist within a single issuer or acquirer stack, managed through unified orchestration layers.

Frequently Asked Questions

EMVCo payment tokenization replaces the PAN with a device-specific Token (DPAN) provisioned by the Token Service Provider — Visa Token Service (VTS) for Visa, Mastercard Digital Enablement Service (MDES) for Mastercard. At transaction time the device generates a cryptogram bound to the DPAN, merchant, and amount. The acquirer routes the transaction with the DPAN; the scheme detokenizes to the FPAN for issuer authorization. Issuers receive the FPAN so no issuer-side processing changes are required, though Token Assurance Level (TAL 0–2) can influence fraud scoring and should be factored into rule logic.

Click to Pay is the EMVCo Secure Remote Commerce (SRC) specification, branded by Visa and Mastercard. It creates a cross-merchant digital identity enabling one-click checkout without re-entering card details. Unlike traditional 3DS card-on-file checkout where each merchant stores PAN data independently, Click to Pay centralises cardholder recognition via the SRC system and uses a network token, with 3DS2 invoked transparently. For issuers, Click to Pay transactions arrive with a network token and 3DS authentication data, providing stronger fraud signal than plain CNP.

Secure Element (SE) NFC — used in Apple Pay and Samsung Pay — stores the DPAN and cryptographic keys in a tamper-resistant hardware chip certified to Common Criteria EAL4+. Host Card Emulation (HCE) — used in Google Pay and Android wallet implementations — emulates the card in software. Keys are managed via cloud-based limited-use keys (LUKs) retrieved from the TSP. HCE transactions must use cloud-based tokenization profiles (MDES or VTS HCE). From a certification standpoint, SE-based wallets require Secure Element certification and scheme tokenization programme enrollment; HCE wallets require EMVCo SRC or scheme-specific HCE certification.

Ready to Accelerate Your Digital Payments Programme?

Whether you are launching Apple Pay and Google Pay support, integrating MDES or VTS tokenisation, navigating PSD2 SCA requirements or building open banking connectivity — our digital payments specialists have the hands-on experience to deliver.

Talk to a Digital Payments Specialist