Passkeys, Network Tokens, and EMV 3DS at Checkout

On 6 October 2026, Mastercard announced that Wio Bank had become the first issuer in the UAE to auto-enable Click to Pay for its cards. Mastercard describes the experience as powered by its network tokenisation and EMVCo authentication standards, with its Payment Passkey service using device biometrics alongside tokenisation to authenticate transactions.

Announcements like this tend to bundle several technologies into one phrase. For a merchant or PSP deciding what to support, they need separating. A network token protects the card number. A passkey proves the person at the device is the cardholder. EMV 3D Secure (EMV 3DS) is the protocol that carries an authentication request to the issuer. Click to Pay is a checkout that stores tokenised cards. They overlap, but they answer different questions, and the practical question for a merchant is who authenticated the cardholder and what evidence reached the issuer.

Why one-time passcodes are exposed to phishing

Many EMV 3DS challenges still use a one-time passcode (OTP) sent by SMS. An OTP proves that someone has the phone, but nothing ties the code to the website where it is typed. A phishing page can ask for card details and the OTP, then relay both to a genuine checkout.

Singapore Police Force advisories describe this pattern repeatedly. A 2026 advisory describes victims being sent to a spoofed portal and prompted to enter card details, banking credentials or an OTP. Standing police advice is to check the merchant name in an OTP message before entering the code, which shows how much of the defence currently rests on the cardholder.

Passkeys work differently. Under the FIDO and WebAuthn model, a passkey is bound to the website or app it was registered with, and the browser or operating system will not release it to a different origin. A phishing page has nothing it can ask the cardholder to type. That is the main security reason schemes and issuers are moving towards passkeys, separate from any convenience gain.

Who authenticates the cardholder in each checkout pattern

The same customer can now pay in several ways, and the party doing the authentication changes with each one. This comparison describes typical arrangements; programme details vary by scheme and market.

Two points follow. First, a passkey is not one thing: it can belong to the issuer, the scheme, the wallet or the merchant, and each arrangement produces different evidence. Second, the liability and regulatory treatment of each pattern is set by scheme rules and local regulation, not by the technology. A merchant should confirm both with its acquirer before assuming that a biometric checkout carries the same protection as an authenticated EMV 3DS transaction.

Where EMV 3DS still fits

Tokens and passkeys do not make EMV 3DS redundant. A tokenised card can still be authenticated through EMV 3DS, and in many checkouts that remains the route by which the issuer itself decides whether to authenticate. Where an issuer has not joined a scheme passkey programme, or a shopper’s device cannot use one, EMV 3DS is the fallback that reaches every enrolled card.

The protocol is also adapting. Recent EMV 3DS versions define how SPC can be used for an issuer challenge, which brings passkey-based authentication inside the issuer’s own 3DS flow. Our articles on SPC and WebAuthn and why SPC support matters for issuers cover the issuer side.

Decisions for merchants and PSPs

List which of the five patterns your acquirers and PSPs support today, by scheme and market.
For each pattern, confirm in writing how authentication evidence is passed and how fraud liability is treated.
Define the fallback when a passkey or wallet route is unavailable, so the customer is not sent to manual card entry with no authentication.
Keep EMV 3DS data complete for the cases that still use it, and check that results reach authorisation intact.
Measure approval, challenge and fraud outcomes by pattern rather than in aggregate, so you can see which route actually performs for your customers.

Frequently asked questions

Does a passkey replace 3D Secure?

Not in general. A passkey is a way to authenticate. EMV 3DS is a way to carry authentication to the issuer. A passkey can be used inside an EMV 3DS challenge through SPC, or outside it through a scheme or wallet programme. Which applies depends on the issuer, scheme and checkout.

Do tokenised card payments still need 3D Secure?

Sometimes. Tokenisation protects the card number but does not by itself prove who is paying. Whether a tokenised transaction needs EMV 3DS depends on the checkout pattern, the scheme programme and any local authentication rules. Check with your acquirer for each market.

Are passkeys and Secure Payment Confirmation the same thing?

No. A passkey is the credential. SPC is a browser feature that uses a passkey to confirm one specific payment, showing the cardholder the merchant and amount before they approve.

What happens when a shopper’s device cannot use a passkey?

The checkout needs a fallback, usually an EMV 3DS authentication in which the issuer uses its other challenge methods. Define that fallback before launch so the shopper is not left with no route to pay.

Planning your authentication routes

GPayments’ ActiveServer is a 3DS Server used by acquirers, payment gateways, PSPs and merchants. To work through which authentication routes your checkout should support and how EMV 3DS fits alongside tokens and passkeys, speak with a GPayments 3DS specialist.