Passkeys and Payment Authentication: Where SPC, 3DS, and FIDO Converge

Authentication and payment authorization have historically been treated as separate problems. You authenticate the user to establish identity. You authorize the transaction as a distinct step, often through a different system, on a different UX path, with a different fraud model underneath. The seam between the two flows has been a persistent source of friction - and a persistent attack surface.

That architectural separation is closing. Three developments are converging in a way that changes the fundamental structure of payment authentication: the maturation of Secure Payment Confirmation (SPC) as a W3C specification, the expansion of passkey programs at Visa and Mastercard, and FIDO2's deepening integration with 3D Secure challenge flows. Taken individually, each is notable. Taken together, they describe a world in which the same passkey credential that authenticates a user at login can also cryptographically authorize a specific transaction at checkout - without a redirect, without an OTP, and without an app switch.

For CTOs and heads of digital at financial institutions, understanding how these pieces fit together is no longer optional. It is a core architectural question with direct implications for authentication roadmaps, 3DS vendor relationships, and checkout experience strategy.

The Persistent Problem: Strong Authentication at the Point of Payment

Before examining the architecture, it is worth grounding the conversation in the problem these standards are all trying to solve. Payment authentication is one of the most friction-sensitive interactions in digital financial services. At checkout, every additional step - an OTP delivery wait, an app redirect, a challenge response that breaks the native flow - introduces the possibility that a customer abandons the transaction. Abandonment at the authentication step is a direct revenue cost, and it is not a small one at scale.

At the same time, removing that friction without compromising security has historically required uncomfortable tradeoffs. Risk-based authentication systems can exempt low-risk transactions from step-up challenges, but those determinations are probabilistic. Fraud slips through. Legitimate transactions get declined. Neither outcome is acceptable when the system is operating at the scale of a major issuer's card portfolio.

The convergence of SPC, 3DS, and FIDO represents a different approach to the problem. Rather than trying to make existing authentication methods less friction-heavy, these standards collectively enable a credential type - the passkey - that is cryptographically strong, user-experience light, and natively bound to the specific context of a transaction. The goal is not to hide authentication from the user. It is to make authentication fast, native, and trustworthy enough that it stops being a conversion problem.

Secure Payment Confirmation: Passkeys Extended to the Transaction Layer

Secure Payment Confirmation (SPC) is a W3C specification built directly on top of WebAuthn - the same underlying standard that powers passkeys. It extends the WebAuthn authentication ceremony in one specific and important direction: it includes transaction details in the signed payload.

In a standard WebAuthn flow, the authentication ceremony produces a signed assertion that confirms user identity. The assertion says, in effect, that this user is who they claim to be on this relying party's service. SPC adds a layer to that: the signed payload includes the merchant name, transaction amount, and currency. The user's device does not just confirm identity - it signs a specific transaction with specific parameters, cryptographically binding the authorization to the authentication event.

What this enables in practice is a native, OS-level transaction confirmation prompt - a Face ID or Windows Hello dialog that displays the transaction details and requires biometric confirmation to proceed. The result is an authentication event that simultaneously constitutes transaction authorization, is phishing-resistant by construction, and requires no redirect, no SMS, and no context switch to a separate application.

SPC is not a competing standard to passkeys. It is passkeys applied to the payment context. Financial institutions that have already deployed or are planning to deploy passkeys for account authentication are building the credential infrastructure that SPC requires. The connection is architectural, not incidental.

3DS and the FIDO Integration Roadmap

3D Secure is the authentication protocol that governs card-not-present transaction authorization. EMV 3DS 2.x brought meaningful improvements over the original protocol - richer device and behavioral data, better risk-based exemption logic, reduced friction for recognized sessions - but the challenge methods it uses have historically relied on SMS OTP delivery and banking app redirects. Both carry friction and, in the case of SMS, meaningful interception risk.

The FIDO Alliance and EMVCo have been working to address this directly. The collaboration is aimed at defining how FIDO2 credentials can be used within 3DS challenge flows - enabling a scenario where, instead of receiving a one-time passcode or switching to a banking app, the cardholder is presented with a WebAuthn-based challenge that completes natively and cryptographically on their device.

The practical version of this, at its most complete, is a 3DS challenge flow that leverages SPC: a single, native biometric prompt that serves simultaneously as the 3DS authentication event and as the transaction confirmation. For the cardholder, it is a faster and more intuitive experience than any OTP-based flow. For the issuer, it is a cryptographically strong authentication event with a full audit trail, compliant with strong authentication requirements under frameworks like PSD2's SCA mandate and comparable regulations building in other markets.

Several access control server vendors and issuers are already piloting FIDO-compatible challenge flows in specific markets. The regulatory pressure from Strong Customer Authentication requirements in the UK and EEA has created both the commercial incentive and the compliance rationale for this kind of upgrade.

Network Programs: Visa, Mastercard, and the Infrastructure Layer

Both Visa and Mastercard have made explicit public commitments to passkeys as part of their authentication strategy. These are not pilot announcements - they reflect investment in production infrastructure.

Visa's Click to Pay program has been expanding passkey support, with the network building credential management infrastructure that allows a passkey issued in one merchant context to be recognized across others. This addresses the credential portability challenge that has historically complicated cross-merchant authentication: the goal is a passkey that travels with the cardholder rather than being scoped to a single relying party.

Mastercard's Identity Check product - its 3DS-based authentication offering - has been incorporating passkey support as part of its evolution away from OTP-based challenge methods. The network is building the infrastructure layer that connects passkey credentials at the issuer level to the transaction authorization flows at the network level.

These programs matter for issuers because they create standardization pressure. When the card networks are building passkey support into their transaction authorization infrastructure, issuers who have deployed passkeys for account authentication are better positioned to connect to those programs without building bespoke integrations. The issuer who has the credential layer in place arrives at network passkey program participation as an integration problem. The issuer starting from zero arrives as a greenfield build.

The Credential Architecture Question for Issuers

The most practically important implication of this convergence is the credential architecture question it raises. Today, most passkey deployments are scoped to account login. A user authenticates to their banking app via passkey, but that credential is bound to the institution as a relying party. When the same user makes a card payment on a merchant site, a completely separate authentication flow begins - typically a redirect to the issuer's 3DS challenge interface, which in most cases has no awareness of the passkey the user just used moments earlier.

The long-term direction of this convergence is to close that gap. A passkey provisioned at the issuer level would be usable - with appropriate privacy protections and user consent - across both the account authentication flow and the payment authorization flow. The device becomes the persistent trust anchor. The distinction between login and transaction authorization becomes a layer above a common credential foundation.

Getting there requires coordination across issuers, acquirers, access control servers, and networks - which is precisely why the EMVCo and FIDO Alliance collaboration and the network passkey programs matter. The standards work is designed to create the interoperability layer that makes this possible at scale without requiring bespoke bilateral agreements between every issuer and every acquiring network.

What to Build Toward Now

For a financial institution evaluating its authentication roadmap today, this convergence has several near-term architectural implications.

Passkey deployments scoped to account login should be designed with payment authentication extensibility in mind from the beginning. The relying party configuration, attestation handling model, and device binding architecture will all matter when the institution is ready to extend passkey credentials into SPC-based payment flows. Building the login credential in isolation from the payment authentication roadmap creates rework later.

3DS integrations coming up for refresh should be evaluated against the evolving FIDO-compatible challenge options. The 3DS ecosystem is not moving uniformly or overnight, but the trajectory is clear, and choosing an access control server that is actively investing in WebAuthn-based challenge support positions the institution better for the near-term evolution of the space.

The Visa and Mastercard network programs deserve active engagement, not passive monitoring. Institutions that have deployed passkeys are closer to participation readiness than they may realize, and the programs are moving from pilot to broader rollout.

Sources

W3C Secure Payment Confirmation Specification - w3.org

W3C Web Authentication (WebAuthn) Specification - w3.org

EMVCo 3D Secure Technology - emvco.com

FIDO Alliance and EMVCo Collaboration Announcement - fidoalliance.org

FIDO Alliance: Passkeys - fidoalliance.org

Visa Click to Pay - visa.com

Mastercard Identity Check - mastercard.com