Passkeys Payment Authentication: FIDO2, 3-D Secure and PSD2 SCA

Disclaimer: this article is systems and architecture analysis only. It is not financial, legal or compliance advice; confirm regulatory interpretation with your own counsel and acquirer.

Most European card-not-present payments still end the same way: a six-digit code arrives by SMS, the customer copies it into a bank-branded iframe, and a meaningful share of them abandon the basket. That code is also the weakest link in the chain, because it can be phished, intercepted through SIM-swap, or relayed by a real-time proxy. Passkeys payment authentication replaces the shared secret with a public-key signature produced by a device the customer already unlocks dozens of times a day, and it does so inside the same 3-D Secure rails that issuers, schemes and acquirers already operate.

It matters now because three things have matured at once: EMV 3-D Secure carries FIDO data natively, the W3C Secure Payment Confirmation specification is moving through Candidate Recommendation, and the EU is rewriting its payment rules around fraud liability. This guide walks the reference architecture end to end. You will leave with a clear model of who holds which key, how the signature is bound to an amount and a payee, where synced credentials strain regulatory language, and how to design recovery without reopening the SMS hole.

What this covers: the context of PSD2 strong customer authentication and 3-D Secure, a reference architecture for passkeys inside a 3DS flow, a walk-through of dynamic linking and secure payment confirmation, enrolment and recovery design, failure modes, and a practical checklist.

Context and Background: Why SMS OTP Became the Default and Why It Is Ending

The revised Payment Services Directive (PSD2) and its Regulatory Technical Standards on strong customer authentication and secure communication (Commission Delegated Regulation (EU) 2018/389, the “RTS”) require payment service providers to apply strong customer authentication (SCA) to most electronic payments. SCA means authentication using at least two independent elements drawn from knowledge, possession and inherence, where a breach of one element must not compromise the others. For remote card payments the RTS adds a further requirement: the authentication code must be dynamically linked to the amount and the payee.

When SCA enforcement began, the card industry reached for what it already had. EMV 3-D Secure (3DS), the protocol that lets an issuer authenticate a cardholder during an online purchase, offered a challenge step and almost every issuer filled it with an SMS one-time passcode (OTP) or a knowledge element such as a static password. These choices were cheap to roll out. They were not designed to resist modern attacks: OTPs are not bound to an origin, so a phishing page can request and relay them, and SMS depends on telecom infrastructure that fraudsters routinely subvert.

The European Banking Authority clarified in its June 2019 opinion on the elements of SCA what counts as possession and inherence. It accepts device binding, described as a security chip or a private key linking an app or a registered browser to a device, as evidence of possession, and it accepts fingerprint, face and similar biometrics as inherence. That is almost exactly the profile of a FIDO credential: a private key held by the device and released by a biometric or PIN gesture. The regulator never needed to name passkeys for them to fit.

What changed in the last few years is that the protocol plumbing caught up. EMVCo published EMV 3DS 2.3 in October 2021 with support for WebAuthn and Secure Payment Confirmation (SPC) developed with the W3C and the FIDO Alliance, and 3DS 2.3.1 in September 2022 added data elements for SPC and out-of-band authentication. In December 2025 EMVCo stated plainly that passkeys work in online payments through two EMV standards: EMV Secure Remote Commerce (SRC), where version 1.5 lets consumers create passkeys for their SRC profile, and EMV 3DS, where passkeys run in the challenge flow using SPC.

The commercial pressure comes from the other direction too. The EU’s payment services package, PSD3 and the Payment Services Regulation (PSR), reached provisional agreement in November 2025 according to PwC’s summary, with adoption expected in the second half of 2026 and most obligations applying around 2028; treat those dates as indicative and verify against the Official Journal. The package widens SCA to high-risk account actions and shifts the burden of proof towards the payment service provider, so a successful authentication is no longer treated as proof of authorisation. Phishing-resistant authentication stops being a conversion tactic and becomes a liability control. For related thinking on how compute and infrastructure cost shape which fraud defences are affordable at scale, see our analysis of hyperscaler capex and AI compute economics, which sets the backdrop for machine-learning risk engines that sit beside the passkey step.

Vocabulary that the rest of the article depends on

A passkey is the consumer-facing name for a FIDO discoverable credential: an asymmetric key pair created for one relying party, with the private key held by an authenticator and the public key stored by the relying party. WebAuthn is the W3C browser API, and CTAP2 is the protocol between the client and an external authenticator such as a phone or a security key; together they form FIDO2. A relying party (RP) is the server that verifies assertions, identified by an RP ID that is a registrable domain suffix. In a payments context the RP is usually the issuer or the issuer’s authentication provider, not the merchant.

Two passkey flavours matter for regulators. Device-bound credentials never leave the authenticator that created them. Synced credentials are backed up and replicated across a user’s devices by a platform provider’s cloud account, which is excellent for usability and awkward for the SCA language about possession. We return to that tension in the trade-offs section.

Reference Architecture: Passkeys Inside an EMV 3-D Secure Flow

The shortest correct statement of the architecture is this: the issuer’s Access Control Server (ACS) becomes a WebAuthn relying party, the browser or app becomes the WebAuthn client, and EMV 3DS messages carry the challenge and the assertion between them. The merchant never sees a private key, never verifies the signature, and never needs to be a FIDO relying party for the card payment to succeed.

Figure 1: Reference architecture for passkeys payment authentication inside an EMV 3-D Secure flow, from the cardholder device to the issuer ACS and back to authorisation.

Figure 1 reads from the cardholder downwards. The passkey lives in the device’s secure element, trusted execution environment or platform credential manager. The browser or app calls the WebAuthn API. The merchant’s 3DS Requestor environment hands the transaction to a 3DS Server, which sends an authentication request through the card scheme’s Directory Server to the issuer’s ACS. The ACS evaluates risk, optionally triggers a challenge, validates the FIDO assertion against the public key it stored at enrolment, and returns an authentication result. The merchant then submits the authorisation request with the electronic commerce indicator and the authentication value so that liability shifts as agreed.

Who is the relying party, and why it matters

There are two integration models, and mixing them up is the most common source of confusion in design reviews.

In the first model, the merchant is the FIDO relying party. The shopper signs in to the merchant account with a passkey, and the merchant tells the issuer about it. EMVCo and the FIDO Alliance described this in a 2020 technical note: FIDO authentication data is serialised as JSON and carried in the 3DS Requestor Authentication Data field, with a reserved 3DS Requestor Authentication Method value of 06 meaning login to the cardholder account at the 3DS Requestor using a FIDO authenticator. The data object includes the authentication time, the RP ID or app ID, and an array of authenticator references with the public key, the authenticator model identifier (AAGUID or AAID), a flag for whether it was used for this transaction, and the user-presence and user-verification flags. The issuer’s ACS treats it as a risk signal, not as SCA by itself. It raises the chance of a frictionless approval but the issuer remains responsible for the SCA decision.

In the second model, the issuer is the relying party. The cardholder registers a passkey with the bank, scoped to the bank’s RP ID, and the ACS challenges it directly during 3DS. This is the model that satisfies SCA on its own because the issuer controls enrolment, the credential lifecycle and verification. It also produces the strongest dynamic-linking evidence, since the issuer signs off on the exact challenge it generated. Cross-origin use, where an assertion is requested from a merchant page for a credential scoped to the bank, is what the W3C Secure Payment Confirmation specification was created to handle.

A third pattern is emerging under the label of delegated authentication, where the issuer or scheme delegates the authentication ceremony to a trusted third party such as a wallet or the merchant’s own PSP, then accepts the result. The delegation is a contractual and regulatory arrangement before it is a protocol feature, and I could not verify from public EMVCo material the exact EMV 3DS version in which data elements for delegated authentication were finalised, so treat any vendor claim about it as something to check against the current specification set.

What the issuer stores and what it can prove later

At enrolment the ACS or its FIDO server stores, per credential: the credential ID, the public key, the signature counter if the authenticator reports one, the AAGUID, the attestation statement if requested, backup eligibility and backup state flags, and metadata linking the credential to the card or customer. Those last two flags, BE and BS in the authenticator data, tell the RP whether a credential can be and currently is synced. They give the issuer a machine-readable way to distinguish device-bound from synced credentials, which feeds directly into the risk policy discussed later.

At authentication time the issuer must retain evidence for audits and disputes: the challenge it issued, the derivation record connecting that challenge to the amount and payee, the returned authenticator data and signature, and the user-verification outcome. That evidence package is what turns a cryptographic event into something a dispute analyst, an auditor or a regulator can read.

The role of the Directory Server and the scheme

The scheme’s Directory Server routes authentication messages and enforces message-level rules, but it does not verify the FIDO assertion. Schemes have launched their own passkey payment programmes and the FIDO Alliance’s payments page names Mastercard and Visa as having implemented passkey payment services; I do not rely on scheme marketing figures here, and the specifics of each programme, such as how credentials are tokenised or how they interoperate with network tokens, should be taken from the scheme’s own documentation. For the architecture it is enough to know that the scheme is a router and a rules enforcer, and the cryptographic trust anchor sits at the issuer.

Dynamic Linking: Binding the Signature to the Amount and the Payee

Dynamic linking means the authentication code is specific to the amount and the payee the payer agreed to, and any change to either invalidates it. With passkeys the code is a digital signature, and the binding is achieved by making the signed bytes depend on the transaction.

A plain WebAuthn assertion signs the authenticator data concatenated with the SHA-256 hash of the client data JSON, and the client data JSON contains the challenge. If the challenge is a fresh random nonce, the signature proves possession and user verification but says nothing about what was being paid. Dynamic linking therefore requires the relying party to derive the challenge from the transaction: hash a canonical encoding of the amount, currency and payee identifier, mix in server-side randomness to prevent replay, and use the result as the challenge. When the assertion returns, the server recomputes the challenge from its own record of the transaction and checks it matches the one in the signed client data.

Binding the challenge is necessary but it is not sufficient, and this is the part that most blog posts skip. The RTS also expects that the payer is made aware of the amount and the payee, and that the authentication elements are protected against tampering with what is displayed. If the page that shows the amount is the same page an attacker controls, a compromised merchant page can display GBP 20 while the challenge encodes GBP 2,000. The cryptography is intact and the customer has still been deceived. A secure display path is what closes that gap.

Secure Payment Confirmation: the browser renders the transaction

Secure Payment Confirmation moves the display of the transaction into browser-controlled user interface. The W3C specification, a Candidate Recommendation Draft as of 2 July 2026 according to the version I fetched, combines the Payment Request API with WebAuthn. The merchant creates a PaymentRequest using the secure-payment-confirmation payment method, passing credential IDs, a challenge, the RP ID, instrument details such as a name and icon, and optionally the payee name or origin. The browser then shows a standardised dialog with the payee, the amount and the instrument, collects the user-verification gesture, and returns signed data in a structure the specification calls collected client payment data. The merchant forwards it to the relying party for verification.

Figure 2: Secure Payment Confirmation sequence. The challenge is a hash of amount, payee and a server nonce, and the browser, not the merchant page, displays the transaction to the cardholder.

Registration uses the payment extension to WebAuthn through navigator.credentials.create(), typically inside an iframe controlled by the issuing bank. The extension explicitly opts the credential into cross-origin use, which is the relying-party opt-in that prevents any arbitrary merchant from requesting assertions against a bank credential. The specification also defines an optional browser-bound key, a device-specific key pair created by the browser whose private key is never exported, which adds a second signature over the transaction details and supports a device-binding story even when the main credential is synced.

Availability can be probed with PaymentRequest.securePaymentConfirmationAvailability(), and capabilities such as hardware-backed browser-bound keys through getSecurePaymentConfirmationCapabilities(). The practical caveat is browser coverage. A July 2026 practitioner write-up reports that SPC ships only in Chromium-based browsers, leaving Safari and Firefox without it. I could not confirm that claim against browser vendor release notes during research, so verify it for your target audience before you commit to SPC as the only path.

The fallback: challenge binding with an RP-rendered display

Where SPC is unavailable the relying party renders the amount and payee in its own interface, typically the ACS challenge iframe, and binds the same values into the challenge. This is weaker against a malicious host page that overlays or manipulates the iframe, so compensating controls are worth the engineering: frame-ancestor and clickjacking protections on the ACS page, a visible-origin cue, and a risk-engine check for anomalous embedding contexts. Regulators generally care about evidence, so you must be able to reconstruct from logs exactly which canonical amount and payee strings produced the challenge.

Why the signature counter and flags matter for linking

The assertion’s authenticator data includes flags for user presence (UP) and user verification (UV). For SCA you want UV set, because UP only proves that something touched the authenticator and says nothing about inherence or knowledge. A passkey assertion with UV unset must be treated as one factor at best. Policy should therefore request user verification as required in the WebAuthn options and reject assertions where the returned flag disagrees, since a client can ignore a preference but cannot fake the signed flag byte.

Deeper Analysis: Enrolment, Step-Up Policy and the Authentication Decision

A passkey is only as strong as the moment it was created. Nearly every real-world weakness in passkey payments sits in enrolment and recovery, not in the signature scheme, which is mathematically solid. The design question is how to get a credential bound to the right person with the least friction and without reintroducing a phishable fallback.

Enrolment: three realistic paths

The cleanest path is enrolment during a strongly authenticated session. The cardholder is already inside the bank’s mobile app, authenticated with an existing SCA method, and the app creates a passkey scoped to the bank’s RP ID. Because the issuer observed a full SCA event moments earlier, the new credential inherits that assurance.

The second path is enrolment at checkout after a legacy challenge. The cardholder completes an SMS OTP or app approval during a 3DS challenge, and the ACS then offers to create a passkey on this device. This is how most programmes bootstrap the installed base, because it requires no separate onboarding. The risk is that a fraudster who defeats the OTP can enrol their own passkey and thereby convert a one-off compromise into persistent access. Mitigations include only offering enrolment after an unusually strong challenge, delaying activation for high-value usage, and notifying the customer through an independent channel.

The third path is enrolment through a wallet or SRC profile, where a passkey protects access to enrolled cards in the profile. EMVCo notes that SRC 1.5 supports this and that it can remove repeated OTP entry. Here the relying party is the SRC system, so the issuer must decide whether it will accept the wallet’s authentication as SCA under a delegation arrangement, which pushes the question back into contracts and liability allocation.

Step-up policy: where the passkey sits in the decision tree

Passkeys do not make the risk engine redundant. The issuer still decides, per transaction, whether to approve frictionlessly, challenge, or decline, and exemptions under the RTS such as low-value payments, transaction risk analysis and trusted beneficiaries continue to apply. The passkey replaces the challenge step, and also improves the frictionless path because a recent, device-bound FIDO authentication is a strong risk signal.

Figure 3: Step-up decision flow. Exempt or low-risk payments stay frictionless, registered passkeys run the dynamically linked challenge, and everything else routes through enrolment or a fallback.

Figure 3 shows the shape of the policy. Note two things. First, the fallback branch is where attackers aim: downgrade attacks work by making the passkey path fail and then phishing the OTP path. A mature programme measures the fallback rate as a security metric, not only a conversion metric, and investigates sudden increases in passkey-failure-then-OTP sequences. Second, a successful challenge ends with the electronic commerce indicator and authentication value that the merchant passes into authorisation. The exact values depend on the scheme, so take them from the scheme’s 3DS implementation guide rather than assuming them from this diagram.

Worked example: what the issuer verifies

Consider a GBP 84.50 purchase at a merchant whose identifier is registered as a canonical string. The ACS builds a challenge by hashing a canonical encoding of the amount in minor units (8450), the ISO 4217 currency code (826), the payee name or identifier, the 3DS transaction ID and a 16-byte random nonce. These values are illustrative, not drawn from any real implementation. The browser or ACS page presents the amount and the payee. The cardholder verifies with a fingerprint, and the authenticator signs.

On return, the ACS performs a fixed sequence. It looks up the credential ID and fetches the stored public key. It confirms the RP ID hash in the authenticator data equals the SHA-256 of its own RP ID. It checks the UV flag is set. It parses the client data JSON, confirms the type is the expected one, confirms the origin is permitted, and compares the challenge to the value it generated. It verifies the signature over authenticator data and the client data hash using the stored key. It then checks the signature counter where the authenticator supports it, and the BE and BS flags against its policy. Only then does it mark the transaction authenticated and produce the authentication value.

Every one of those checks addresses a distinct attack. The RP ID hash defeats a phishing site on another domain, because the browser will not release an assertion for an RP ID the site is not entitled to. The origin check defeats a malicious frame. The challenge comparison defeats replay and amount tampering. The UV flag defeats a stolen unlocked device used with a bare touch. The counter, where meaningful, flags cloned authenticators, although synced passkeys typically report a zero counter, so a zero counter is not by itself suspicious.

What WebAuthn Level 3 changes for payments

WebAuthn Level 3 reached Candidate Recommendation Snapshot status on 26 May 2026 according to the W3C document I fetched, which means it is feature-complete for implementation feedback but not yet a full Recommendation. Several additions are relevant to payments programmes. Related origins let one RP ID be used across a bounded set of related domains, which matters to issuers and processors that run authentication from more than one brand domain. The signal API, with methods such as signalUnknownCredential and signalAllAcceptedCredentials, lets a relying party tell the credential manager that a credential has been revoked or no longer exists, helping the user’s device clean up stale payment passkeys. User agent hints let the RP suggest whether to prefer a phone, a security key or a platform authenticator. The client capabilities query lets the RP detect support at runtime, and new attestation formats include Apple’s anonymous attestation and compound attestation.

None of these change the cryptographic core, so existing deployments will not break. The signal API and related origins will, however, reduce the operational pain that early passkey rollouts hit: orphaned credentials and domain sprawl.

Latency, availability and cost considerations

A passkey assertion adds one client-side ceremony, typically a fraction of a second of user interaction, and one server-side signature verification, which is trivial compared with the risk-engine and network hops already in the 3DS path. The meaningful operational costs are elsewhere: storing credentials with strong consistency, because a challenge issued by one region must be verifiable in the region that receives the assertion; building enrolment and recovery tooling; and retaining the evidence package for the dispute window.

Compare that with SMS. Per-message telecom cost is real, delivery failures create declined-and-retry loops, and each failure is a support contact. Machine-learning risk models that decide who needs a challenge consume compute as well, and their economics follow the same logic described in our look at custom AI silicon from the hyperscalers. I have deliberately not quoted conversion-uplift or fraud-reduction percentages here: public figures vary by merchant and issuer, are usually vendor-reported, and I have not found a neutral benchmark that holds across segments. Measure your own cohorts against an SMS control group instead.

Regulatory mapping: does a passkey satisfy two factors?

A passkey assertion with user verification maps cleanly to two elements when the credential is device-bound. Possession is the private key held in hardware that the EBA recognises as device binding. The second element is the local gesture that unlocks it: inherence if a biometric, knowledge if a PIN. The RTS requirement that a breach of one element must not compromise the other holds because the biometric template or PIN never leaves the device and is not the secret the server verifies.

The independence requirement is where nuance enters. The EBA opinion expects that a possession element can be shown by a dynamic validation element generated on the device. A signature over a fresh, transaction-derived challenge meets that. What the regulator has said specifically about synced passkeys under PSD2 is not something I could verify from primary sources during research, and I would treat any statement that synced credentials are formally approved as possession as unverified. NIST’s digital identity guidance has addressed the phishing resistance of synced passkeys, and the FIDO Alliance cites that reference, but NIST authenticator assurance levels and the EU SCA possession test are different yardsticks and should not be conflated.

Recovery and Credential Lifecycle: Designing the Part Attackers Target

A passkey programme that is cryptographically perfect and recoverable by a support-desk phone call is, in effect, an SMS programme with extra steps. Recovery is therefore the most security-critical flow in the system and deserves the same rigour as enrolment.

Figure 4: Recovery and lifecycle for lost or replaced devices, branching on whether the credential is synced or device-bound, and ending in revocation of the old credential.

Synced credentials: convenience with a dependency

Synced passkeys survive a lost phone because the platform provider restores them from an end-to-end encrypted backup tied to the user’s cloud account. For the issuer this is wonderful for adoption, because a new device often just works. It also means the security of the payment credential now includes the security of the user’s platform account and its recovery process, which the issuer neither controls nor audits.

The backup flags in authenticator data let the issuer see this. A sensible policy treats a synced credential as sufficient for low and medium-value payments and for logins, but requires a fresh, strong step-up the first time a synced credential is used on a device the issuer has not seen, or for transactions above a threshold the issuer’s risk team sets. That is a design choice, not a regulatory requirement, and the right thresholds depend on the issuer’s loss data.

Device-bound credentials: strength with an enrolment tax

Device-bound credentials give the strongest possession story and the cleanest regulatory argument, because the key demonstrably cannot leave the hardware. The cost is that every new device needs re-enrolment, and every re-enrolment is an attack surface. Where an issuer already runs a registered mobile app with its own device binding, re-enrolment is manageable: the app is the strong channel. For web-only customers it is harder.

Revocation and hygiene

Every recovery event should end with explicit revocation of the old credential at the issuer’s FIDO server and, where supported, a signal to the credential manager so that the stale credential is removed from the user’s device. Without revocation, the issuer accumulates dormant credentials that are valid forever. Add expiry or periodic re-validation for credentials unused for a long period, notify the customer on every enrolment and recovery through an independent channel, and rate-limit enrolment attempts per card and per device.

Account recovery as an attack path

Fraudsters follow the cheapest route. When the passkey path is robust they will attack the recovery path, social-engineer call centres, or pivot to the account-opening flow. The EU’s PSR direction on liability for impersonation fraud, which per the PwC summary refunds customers deceived by fraudsters posing as their bank unless gross negligence is shown, raises the price of getting this wrong. A passkey that signs a transaction the customer was tricked into approving is still cryptographically valid; this is why the secure display path and the risk engine matter as much as the key pair. For the broader trend of AI-assisted social engineering and why stronger identity primitives are rising up the agenda, see the discussion of emergent abilities in large language models, which explains why generated voice and text have become harder to distinguish from the real thing.

Trade-offs, Gotchas, and What Goes Wrong

Browser and platform coverage is uneven. SPC is the cleanest dynamic-linking path but depends on browser implementation, and the W3C specification itself needs two independent interoperable implementations to advance. Plan for a fallback that renders the transaction in the relying party’s own interface, and measure how many of your sessions can use each path before you promise a uniform experience.

The cross-origin ceremony is a new attack surface. An assertion requested from a merchant page for a credential owned by a bank is deliberately permitted only through explicit opt-in at registration, but every opt-in is a trust decision. Restrict the payment extension to the credentials that need it, keep the allowed-origin logic on the issuer side, and log every cross-origin request.

Signed does not mean understood. Dynamic linking proves the payer signed a specific amount and payee. It does not prove the payer understood why. Authorised push payment scams succeed with perfectly valid strong authentication. The PSR direction is to stop treating authentication as the end of the argument, so build behavioural and payee-reputation checks next to the passkey, and show the payee name clearly in the signed display.

Synced credentials blur the possession story. A credential that can be replicated through a cloud account is not demonstrably tied to one device. Some issuers will accept it for lower-risk flows and require device-bound credentials or an additional browser-bound key for high-value ones. Record the backup flags, make policy explicit, and get your compliance team to document the reasoning rather than relying on vendor assurances.

Counters and cloning signals disappear. Synced passkeys commonly report a signature counter of zero, so the classic clone-detection check does not apply. You need device and behavioural signals instead, such as new-device velocity and impossible travel.

Attestation is optional and can cost privacy. Requiring attestation lets the issuer restrict credentials to known authenticator models via the AAGUID, which is attractive for assurance but excludes users with unlisted authenticators and raises privacy questions. Many consumer deployments request no attestation and rely on risk signals instead; choose by segment.

Conversion can fall before it rises. Enrolment prompts add a step, and customers who dismiss them are still on SMS. Expect a long tail where two authentication systems run in parallel. Retire SMS for a customer only after their passkey has worked reliably, and keep an accessible, non-biometric alternative for users who cannot use the primary gesture, which accessibility law and good practice both require.

Evidence retention is easy to forget. If a dispute arises months later and you cannot reconstruct the challenge derivation, the cryptography will not rescue you. Define the retention schedule up front, with legal input.

Practical Recommendations

Start from the issuer-as-relying-party model if you are a bank or issuer processor, because it is the model that stands on its own as SCA. If you are a merchant or PSP, use passkeys for the merchant login and pass FIDO authentication data to the issuer in the 3DS request; it will not replace the issuer’s challenge but it improves frictionless approval rates and reduces unnecessary step-ups. Do not tell your customers it makes the payment strong-customer-authenticated unless the issuer says so.

Treat dynamic linking as a testable property. Write automated tests that change the amount or payee after the challenge is issued and assert that verification fails. Test with and without SPC, in each target browser, and in the in-app webviews where payments often happen, since embedded browsers are a frequent source of WebAuthn failures.

Design recovery before launch. Decide which events force a strong step-up, how stale credentials are revoked, and how you detect and alert on enrolment from unfamiliar devices. Measure the fallback-to-OTP rate and set an alert threshold.

Finally, keep an eye on the standards. WebAuthn Level 3 and SPC are Candidate Recommendation documents, EMV 3DS continues to evolve, and the PSD3 and PSR text is still moving through adoption. Pin your implementation to named versions and review them quarterly.

A short checklist for a first production pilot:

Issuer is the RP; RP ID and allowed origins documented and reviewed.
User verification required and verified from the returned flag, never trusted from the request.
Challenge derived from amount, currency, payee, transaction ID and nonce; canonical encoding specified.
SPC path and RP-rendered fallback both built, with measured browser coverage.
BE and BS flags stored; policy written for synced versus device-bound credentials.
Enrolment only after a strong session; independent notification on every enrolment.
Recovery and revocation flows tested, including signal calls to credential managers.
Evidence package and retention schedule agreed with compliance.
Fallback-to-OTP rate, enrolment failure rate and new-device velocity monitored.

Frequently Asked Questions

Do passkeys satisfy PSD2 strong customer authentication?

A passkey with user verification can satisfy two SCA elements: possession of a private key bound to a device and a biometric or PIN gesture to unlock it. The EBA’s 2019 opinion accepts device binding as possession and biometrics as inherence. Whether a synced passkey counts as possession is less settled, and I found no primary-source regulatory statement either way. Confirm interpretation with your regulator or counsel, and document your policy for synced credentials.

How do passkeys work with 3-D Secure?

In EMV 3-D Secure, the issuer’s ACS can act as a WebAuthn relying party during the challenge flow. The 3DS messages carry the challenge and the signed assertion, and EMV 3DS 2.3 added support for WebAuthn and Secure Payment Confirmation, with 3DS 2.3.1 adding SPC data elements. A merchant-side passkey login can also be reported to the issuer as FIDO authentication data to improve frictionless approval, though that is a risk signal rather than SCA.

What is dynamic linking and how does a passkey provide it?

Dynamic linking requires the authentication code to be specific to the amount and payee, so changing either invalidates it. With a passkey, the relying party derives the WebAuthn challenge from the amount, currency, payee and a random nonce. The signature then covers that challenge, so tampering breaks verification. Secure Payment Confirmation strengthens this by having the browser display the transaction in trusted user interface rather than a merchant page.

What is Secure Payment Confirmation?

Secure Payment Confirmation (SPC) is a W3C specification that combines the Payment Request API with WebAuthn. The browser shows a standard dialog with the payee, amount and instrument, collects the user-verification gesture, and returns a signed payment-specific assertion. It uses a payment WebAuthn extension for cross-origin use. As of the version I reviewed, dated 2 July 2026, it is a Candidate Recommendation Draft, and browser support should be verified.

Are synced passkeys safe enough for payments?

Synced passkeys are phishing-resistant because they are bound to the relying party’s domain, which is a large improvement over OTPs. They are less clearly bound to a single device, so their recovery security depends on the user’s platform account. A pragmatic approach is risk-based: accept them for low and medium-value flows, check the backup flags, and require a stronger step-up for new devices or high-value payments.

What happens when a customer loses their phone?

For a synced passkey, the credential may restore on a new device through the platform’s backup, after which the issuer should apply a fresh step-up for the first sensitive use. For a device-bound passkey the customer must re-enrol through a strong channel. In both cases the issuer should revoke the old credential, notify the customer through an independent channel, and monitor for abnormal enrolment patterns.

Passkeys and FIDO2 for Payment Authentication: PSD2 SCA Architecture Guide