Passkeys Payments Checkout: FIDO2, WebAuthn and Secure Payment Confirmation (2026)

A one-time password texted to a phone is the weakest link in most card checkouts. It can be phished in real time, intercepted through SIM swaps, and abandoned by customers who never receive it. Yet for years it has been the default way to satisfy strong customer authentication when a bank challenges an online card payment.

The cryptographic alternative has been sitting in every modern phone and laptop. Passkeys payments checkout flows replace the shared-secret code with a device-bound signature that cannot be replayed on a fake site, and the W3C’s Secure Payment Confirmation (SPC) specification goes one step further by making the browser itself show the amount and the payee before the user signs. That second step is what regulators mean by dynamic linking.

This is a systems-architecture analysis, not advice. You will leave with a clear model of who holds which key, how a WebAuthn assertion travels through a EMV 3-D Secure (3DS) flow, where SPC fits and where its browser support stops, how PSD2 strong customer authentication (SCA) maps onto each element, and how to design recovery and fallback so that passkeys reduce friction without creating a lockout problem.

What this covers: the state of passkeys in payments, a reference architecture with the issuer as the credential owner, the WebAuthn and SPC ceremonies in detail with code, 3DS and PSD2 interplay, delegated authentication, failure modes, and a practical rollout checklist.

Disclaimer: this article describes system design and public specifications. It is not legal, compliance or financial advice; regulatory interpretation belongs with your compliance function and acquirer.

Context and Background

Card-not-present payments sit under two overlapping control systems. The first is the card scheme’s authentication protocol, EMV 3DS, where the merchant’s 3DS Server talks through a scheme Directory Server to the issuer’s Access Control Server (ACS). We covered that machinery in our walk-through of 3-D Secure 2 and EMV 3DS SCA flows. The second is regulation, most visibly the European PSD2 regime, whose technical standards require SCA for most electronic payments unless an exemption applies.

Inside a 3DS challenge, the ACS has to prove that the cardholder presented two of three factors: knowledge, possession, inherence. Historically the ACS chose among SMS one-time passwords, knowledge-based answers, and banking-app push approvals. Each of those is a shared or relayable secret. Passkeys change the primitive. A passkey is a discoverable WebAuthn credential: a public-private key pair whose private half stays in a secure element, trusted execution environment, or a credential manager, and which only unlocks after local user verification such as a fingerprint, face scan or device PIN.

The relevant standards form a stack. FIDO2 is the umbrella from the FIDO Alliance, combining the W3C Web Authentication (WebAuthn) browser API with the Client to Authenticator Protocol (CTAP) for external authenticators. WebAuthn defines two ceremonies, registration (navigator.credentials.create()) and authentication (navigator.credentials.get()). Every credential is scoped to a Relying Party ID (RP ID), normally a registrable domain, which is the property that defeats phishing: a credential made for the issuer’s domain simply will not sign for a lookalike.

Payments added two problems that login does not have. First, whoever receives the assertion needs evidence of what was approved, not merely who approved. A generic WebAuthn assertion signs a challenge, and a merchant page could display one amount while sending a challenge built for another. Second, the party running the checkout page (the merchant) is not the Relying Party that owns the credential (usually the issuing bank). WebAuthn was designed for same-site login, and cross-party use needed extra specification work.

EMVCo and the FIDO Alliance began addressing the first generation of this in October 2020, when EMVCo published a white paper on using FIDO authentication data inside 3DS messages. That paper defined a FIDO attestation data set that merchants can pass to issuers to show that merchant-side strong authentication took place, with the stated aim of reducing how often issuers must re-authenticate. EMVCo’s later 3DS 2.3 material says it collaborated with W3C and FIDO to support WebAuthn and SPC within the 3DS flow, and MDN states that SPC is supported by EMV 3DS version 2.3.1 and EMV Secure Remote Commerce version 1.3. Read the W3C Secure Payment Confirmation specification alongside this article; it is the normative source.

One status point deserves honesty up front. The SPC document is a W3C Candidate Recommendation Draft dated 2 July 2026. Moving to a Proposed Recommendation requires two independent, interoperable implementations. In other words, the API is real and shipping in some browsers, but it is not yet a finished W3C Recommendation, and your design must tolerate browsers that lack it.

Reference Architecture: The Issuer Owns the Credential

The simplest correct mental model is that the issuer (or its ACS provider) is the Relying Party. It registers the passkey, stores the public key against a card or account, verifies assertions, and then tells the scheme the cardholder was authenticated. The merchant and its payment service provider (PSP) are orchestrators: they invoke the browser API and ferry the assertion, but they never hold the private key and cannot forge a signature.

Figure 1: Reference architecture for passkeys payments checkout. The issuer ACS verifies the assertion; the merchant and PSP only transport it.

The diagram shows five trust zones. On the shopper device, a platform authenticator holds the private key. The browser mediates the WebAuthn and SPC calls and renders the transaction dialog. The merchant checkout page triggers the flow through its 3DS Server and PSP. The Directory Server, run by the card scheme, routes the authentication request to the right ACS. Finally the issuer ACS looks up the cardholder’s public keys, verifies the signature, and consults a risk engine that decides whether SCA is required or an exemption can be claimed. A successful result returns an authentication value that the acquirer later includes in the authorisation message.

Why the issuer, not the merchant, should be the Relying Party

If the merchant ran its own passkey login and merely told the bank “this user authenticated”, the bank would have to trust a claim it cannot verify. That is the problem the original FIDO-data-in-3DS work tried to ease with structured data elements, leaving the issuer to weigh the claim as one risk input. It cannot, by itself, give the issuer a signature to verify.

When the issuer is the Relying Party, verification is cryptographic and end to end. The issuer chose the challenge, the issuer holds the public key, and the issuer sees the signed client data. No intermediary can alter the amount without invalidating the signature. For regulatory purposes the issuer is also the party responsible for applying SCA under the technical standards, so aligning the credential owner with the accountable party is architecturally clean.

Three credential scopes

Teams usually confuse three distinct passkey scopes, and each has a different trust model.

Merchant-scoped passkeys are ordinary WebAuthn credentials bound to the merchant’s RP ID. They authenticate the shopper to the merchant account (login, stored cards) and reduce account takeover. They are valuable but they do not by themselves satisfy an issuer’s SCA obligation.

Issuer-scoped payment passkeys are bound to the bank’s RP ID and enrolled for payment use. These are the credentials SPC and 3DS challenges consume. Enrollment normally happens inside the bank’s own app or site, after the cardholder has already been strongly authenticated.

Wallet or network-scoped credentials are held by a party that sits between the two, such as a wallet provider or a scheme token service. They enable delegated models, discussed later, but they require an agreement defining who performs SCA and who bears liability.

For a practical build, choose the issuer-scoped model first. It is the one that maps cleanly onto both 3DS and PSD2 vocabulary, and it avoids contractual novelty.

What lives in the credential store

The ACS needs a table that links a cardholder identity to one or more credentials. A minimal schema holds the credential ID, the COSE public key, the signature counter if the authenticator reports one, the RP ID, the creation time, an attestation summary, a flag recording that the credential was enrolled with the payment extension, and a mapping to the cards or accounts it may approve. Keep the mapping explicit: a passkey enrolled on a phone for a debit card should not silently authorise a business credit card unless policy says so.

Because passkeys can sync through platform credential managers, the signature counter is often zero or unreliable and should not be treated as clone detection. Use anomaly signals instead: a new device fingerprint, an unusual geolocation, or a burst of assertions across many cards.

The Ceremonies: WebAuthn Registration and SPC Authentication

The answer in brief: a payment passkey is created once through a WebAuthn registration ceremony flagged with the payment extension, and is then used at checkout through a PaymentRequest whose only payment method is secure-payment-confirmation. The browser displays payee, amount and instrument, collects biometric consent, and returns an assertion whose signed client data contains those very values.

Registration with the payment extension

Enrollment is a standard navigator.credentials.create() call with an extra extension. The following example mirrors the one in MDN’s guide to Secure Payment Confirmation; the server-provided values are placeholders.

const publicKey = {
  challenge: serverChallengeBytes,          // random, single use, from the issuer
  rp: { name: "Example Bank" },             // rp.id defaults to the issuer domain
  user: { id: userHandleBytes, name: "jane@example.org", displayName: "Jane" },
  pubKeyCredParams: [
    { type: "public-key", alg: -7 },        // ES256
    { type: "public-key", alg: -257 }       // RS256
  ],
  authenticatorSelection: {
    authenticatorAttachment: "platform",
    residentKey: "required",
    userVerification: "required"
  },
  extensions: { payment: { isPayment: true } }
};
const cred = await navigator.credentials.create({ publicKey });
// POST cred to the issuer; verify attestation policy, store public key and credential ID

The specification is strict about this call. The payment extension requires authenticatorAttachment to be platform, residentKey to be required or preferred, and userVerification to be required; otherwise the browser throws a TypeError. Those constraints encode a policy decision: payment credentials must be on-device and must verify the user, which maps naturally to the possession plus inherence (or knowledge) combination that SCA demands.

The extension also supports a browser bound key. The spec lets a relying party request an additional key pair, tied to one device and browser, through browserBoundPubKeyCredParams (default algorithms ES256 and RS256). At registration the client returns a browserBoundPublicKey, and at authentication it adds a browserBoundSignature. The security rationale, as I read the spec, is that a synced passkey might exist on several devices, while a browser bound key lets the issuer confirm that a particular browser instance participated. Treat that as an optional risk signal, not a replacement for the passkey signature, and check implementation status before depending on it.

Authentication through PaymentRequest

At checkout the merchant page, or an iframe that has been granted the right permission policy, constructs a PaymentRequest. Unlike a card-wallet request, the data object carries issuer-provided material, because the merchant needs the issuer’s challenge and the list of credential IDs enrolled for this card.

const request = new PaymentRequest(
  [{
    supportedMethods: "secure-payment-confirmation",
    data: {
      challenge: issuerChallengeBytes,       // replay protection only
      rpId: "bank.example",
      credentialIds: [credIdBytes],          // non-empty
      instrument: {
        displayName: "Example Card ****1234",
        icon: "https://bank.example/card-art.png"
      },
      payeeName: "Shop Name",
      payeeOrigin: "https://shop.example",   // must be https
      timeout: 60000
    }
  }],
  { total: { label: "Total", amount: { currency: "EUR", value: "42.50" } } }
);

const status = await PaymentRequest.securePaymentConfirmationAvailability();
if (status === "available" && await request.canMakePayment()) {
  const response = await request.show();
  await response.complete("success");
  // send response.details (a PublicKeyCredential) to the issuer or 3DS Server
}

Several details in the specification are worth memorising because they surface as production bugs. The secure-payment-confirmation method must be the only payment method in the request, otherwise a RangeError is thrown. credentialIds must be non-empty. At least one of payeeName and payeeOrigin is required, and payeeOrigin must be https. The transaction total comes from the PaymentRequest details, not from the SPC data dictionary, so there is a single source of truth for the amount. The timeout is capped at one hour. Optional members include paymentEntitiesLogos, locale, and showOptOut, which lets the browser offer the user a way to decline SPC and fall back (an opt-out surfaces as an OptOutError).

The canMakePayment() check deserves a caveat that MDN spells out: it examines only public information and does not confirm that the supplied credentials match the current device. Availability checks therefore reduce, but never eliminate, the chance of a dead-end dialog. The spec also describes PaymentRequest.getSecurePaymentConfirmationCapabilities(), which currently defines a single capability key, browserBoundKeyHardware.

What the browser signs

Figure 2: The SPC sequence. The browser, not page JavaScript, builds the client data that includes payee, amount and instrument.

The critical property is in step four of the diagram. The user agent must display the payee name or origin, the currency and value of the total, and the instrument details, and obtain consent. After that the authenticator signs client data of type payment.get. That structure includes rpId, topOrigin, payeeName, payeeOrigin, any entity logos, the total, the instrument, and the browser bound public key where used. Page script cannot edit these fields after the dialog is shown, so a compromised merchant page cannot show 10 euros to the user and ask for a signature over 1,000.

The payment extension also cannot be used by calling navigator.credentials.get() directly; the spec says doing so yields a NotAllowedError. Only the SPC payment handler may drive it. That restriction prevents a rogue page from triggering the payment-flavoured signature path without the transaction dialog.

Verifying the assertion at the issuer

Verification is ordinary WebAuthn verification plus payment-specific checks. In pseudocode terms the issuer should perform these steps in order:

Look up the credential by ID and confirm it is enrolled for this cardholder and the payment extension.
Confirm the client data type is payment.get and that the challenge equals the one the issuer issued for this specific authentication, still unexpired and unused.
Confirm rpId and the RP ID hash in authenticator data match the issuer’s domain, and that the user-verified flag is set.
Check the payment fields: the total and currency equal the amount in the 3DS authentication request, and payeeOrigin or payeeName matches the merchant identity the 3DS Server declared.
Verify the signature over authenticator data and the client data hash using the stored public key, and the browser bound signature if you required one.
Mark the challenge consumed and record the outcome for risk analytics.

Step four is where SPC earns its keep. Without it the issuer would have to take the merchant’s word about what was shown. With it, the signed data is the evidence, and a mismatch is a hard decline of the authentication. Note the spec’s own statement that the challenge is used only to prevent replay; it is not the thing that binds the amount. Teams that previously folded a hash of the amount into the challenge (a valid pattern for plain WebAuthn step-up) should understand that SPC gives them a standard place for those values instead.

Cross-origin and third-party use

Merchants want to keep the checkout in their own page, without a redirect to the bank. SPC supports that by letting a party other than the Relying Party start the authentication. The spec calls credentials the relying party has opted in at creation “third-party enabled SPC credentials”. When rpId differs from the calling origin, the browser checks third-party enablement and removes credentials that fail. A third-party call also throws if the extensions member is non-empty, protecting the relying party’s own extension data.

There is an honest gap to flag: the spec says the process for silently detecting third-party enablement is left undefined and points to an open WebAuthn issue. In practice that means behaviour across browsers may differ, and a sensible design keeps an iframe or redirect path hosted by the ACS as a fallback. Also note the cross-origin credential creation story has moved: MDN observes that the ability to call create() in a cross-origin iframe is now part of WebAuthn Level 3 using the publickey-credential-create permission policy, and encourages developers to use that where available instead of the SPC payment policy.

Deeper Analysis: 3DS, PSD2 SCA and Delegated Authentication

A passkey does not replace 3DS. It replaces the challenge method inside 3DS. The rest of the pipeline, from the 3DS Server’s authentication request to the authentication value consumed at authorisation, is unchanged. That framing helps in design reviews, because it separates the question “how does the user prove presence” from the question “how does the result reach the acquirer and scheme”.

Where the passkey slots into the 3DS flow

In a normal EMV 3DS transaction the ACS first decides, from the data the merchant supplied and its own risk model, between frictionless approval, an SCA challenge, or decline. We described these branches in the EMV 3DS authentication flow article. With passkeys, the challenge branch gains a third mechanism beside OTP and app push. Where the ACS sees that the cardholder has a payment passkey and the browser supports the needed APIs, it issues a challenge and credential IDs and lets the requestor invoke SPC or runs WebAuthn inside its own challenge window.

Figure 3: Decision logic at challenge time. SPC is the preferred path, ACS-hosted WebAuthn is the middle path, and the legacy challenge is the guaranteed floor.

The decision tree has three tiers by design. The first question is whether a usable passkey exists for this card. The ACS knows that from its credential store, but the browser can only report availability of SPC and a coarse hint through canMakePayment(), not whether the credential lives on this particular device. The second question is whether SPC is supported. If not, the ACS can still run ordinary WebAuthn within its own challenge page. That loses the browser-rendered transaction dialog, so the issuer’s own page must display and sign the amount, for instance by embedding transaction details in the challenge. The last tier is the traditional challenge, which must stay available forever, since not every cardholder, device or browser will cooperate.

Mapping to PSD2 strong customer authentication

The PSD2 regulatory technical standard (Commission Delegated Regulation (EU) 2018/389) requires, for electronic remote payments, that authentication elements dynamically link the transaction to a specific amount and a specific payee. Where the final amount is unknown at initiation, the authentication must be specific to the maximum amount the payer agreed. It also requires that the authentication code resists forgery and that the elements are independent so that a breach of one does not compromise the others. You can read the consolidated text on legislation.gov.uk.

Here is a mapping table. The right-hand column is my architectural interpretation, not a regulator’s ruling.

SCA requirement	How a payment passkey addresses it	Residual question
Two independent factors	Possession of the device-held private key plus inherence (biometric) or knowledge (device PIN) via user verification	Whether the supervisor accepts the platform’s local verification as the second factor
Dynamic linking to amount and payee	SPC signs `total`, `payeeName` or `payeeOrigin` and `instrument` in client data	Plain WebAuthn needs the issuer to bind these itself
Code resistant to forgery	Asymmetric signature, per-origin credential	Credential sync across devices changes the possession story
Independence of elements	Biometric stays on-device and is not transmitted	Single multi-purpose device used for both instruction and authentication
Authentication code limited to the transaction	Single-use issuer challenge, consumed on verification	Challenge expiry and replay storage

A classic OTP cannot satisfy dynamic linking by itself unless the message that delivers the code also shows the amount and payee, which is the reason banks put those details into SMS text. A passkey with SPC shifts the display responsibility from the bank’s messaging channel to the browser, which is a stronger position because it is harder to spoof the dialog than to socially engineer an SMS reader.

Two interpretations remain open and deserve caution. First, synced passkeys: if a credential manager replicates the private key across a user’s devices through a cloud account, then possession becomes “possession of any device or account that can unlock the sync fabric”. Whether that is acceptable possession is a supervisory and scheme-policy question, and some issuers restrict payment credentials to device-bound or attested authenticators. Second, exemptions: the same RTS allows exemptions such as low-value payments and transaction risk analysis under conditions. An issuer using passkeys is not required to challenge every time; frictionless approval remains available when risk analysis supports it, and the passkey is simply the most convenient challenge when one is needed.

FIDO data in 3DS versus SPC

Teams often conflate two mechanisms. The 2020 EMVCo white paper on using FIDO data in 3DS messages describes a merchant-side pattern: the merchant authenticates the shopper with FIDO, and passes structured attestation data in the 3DS message so the issuer can treat the event as a strong signal and challenge less often. That is a signal and the issuer decides.

SPC is a different category. It produces a transaction-specific assertion that the issuer itself verifies cryptographically. EMV 3DS 2.3 adds support for WebAuthn and SPC in the specification, and MDN names version 2.3.1 as a supported release. The two can coexist: a merchant-scoped passkey login can feed risk data, while an issuer-scoped SPC credential can satisfy the challenge. In an exam-style summary, FIDO data is evidence about the session, whereas SPC is evidence about the transaction.

Delegated authentication

Delegated authentication is the pattern where the issuer, instead of authenticating every cardholder itself, trusts a third party (often the merchant, a wallet, or a platform) that already authenticated the user with a strong method, subject to an agreement and technical attestation. Card schemes run programmes of this kind for FIDO-based authentication; I could not verify programme names, eligibility or current rules in this research pass, so treat vendor and scheme documents as the authority and check them directly.

Architecturally, delegation needs four things. The delegate must enrol the credential under a process the issuer accepts. The delegate must present verifiable evidence per transaction, typically a signed assertion or an attestation the issuer can validate. A binding must exist between the credential and the payment instrument, because a login passkey that has never been linked to a card proves nothing about the card. And liability must be written down: who covers fraud losses if the delegate’s authentication is later shown to be weak.

In an SPC-based world the delegation is cleaner than in a login-based one. If the delegate registers third-party-enabled credentials with the relying party’s blessing, the delegate can launch the ceremony without redirects, but the assertion still verifies against the issuer’s public key. For PII-minimising designs, consider tokenising cardholder identifiers before they reach credential-management services, the pattern discussed in our piece on reversible tokenisation for PII pipelines.

Relationship to FAPI and bank-to-bank payments

Not every payment passes through card rails. In open-banking payment initiation, the strong authentication happens at the bank during an OAuth redirect, and the integrity of the payment request is protected by profiles such as FAPI 2.0 with sender-constrained tokens and pushed authorization requests. See our FAPI 2.0 security profile explainer for that layer. A passkey is a natural authentication method inside the bank’s consent page; SPC is not required there, because the bank itself renders the consent screen. The two worlds share the WebAuthn core and differ in who draws the amount on screen.

Sizing and operations

Some numbers worth modelling, all as illustrative assumptions rather than measurements: an assertion verification is a single public-key signature check plus a few table reads, which is trivial next to the network round trips through the Directory Server. The real capacity costs are the credential-store read path (keyed by credential ID, so a plain key-value lookup suffices), the challenge store (one write and one atomic consume per authentication, with a TTL of minutes), and the audit log that records the client data for dispute handling. Retain the full signed client data, since it is the evidence that the cardholder consented to a given amount and payee, and plan retention with your legal team.

Latency budgets matter more than throughput. The SPC dialog adds user think time, not network time, and a biometric prompt typically completes faster than typing a six-digit code, but you should measure this on your own population instead of assuming it. Instrument four timestamps: dialog shown, consent given, assertion received, ACS decision. Funnel analytics on those four points will tell you whether abandonment is happening before the prompt (availability problems), during it (UX problems), or after it (verification failures).

Trade-offs, Gotchas, and What Goes Wrong

Browser and platform coverage

SPC is not baseline web platform. MDN’s Payment Request API page states plainly that the feature is not Baseline because it does not work in some of the most widely used browsers, and its SPC guide illustrates the dialog with a Chrome M118 screenshot. I did not verify the current per-browser support matrix for Safari, Firefox or mobile webviews during this research, so check the MDN compatibility table and the vendors’ own documentation before you commit. Whatever you find, build for the case where a large minority of sessions cannot use SPC. Webviews embedded in native apps are a notable trouble spot, because they often lack the WebAuthn and Payment Request surface of the full browser.

Recovery is the real product

Passkeys fail not in cryptography but in life events: a lost phone, a factory reset, a switch from one ecosystem to another, a shared family device. Every unrecoverable credential becomes a support ticket or an abandoned cart, and the temptation is to recover via the weakest channel, undoing the security gain.

Figure 4: Recovery paths. A synced passkey restores access cheaply; otherwise the issuer re-enrols through a strong step-up and revokes the stale credential IDs.

The design principle is that the recovery path must be at least as strong as the authenticator being recovered, or an attacker simply targets recovery. A good pattern is to allow re-enrolment only after the cardholder authenticates in the bank app or with another bound factor plus an identity check appropriate to the risk, to register the new credential with the payment extension, and to revoke the old credential IDs at the ACS. Notify the customer on every enrolment and revocation through a channel the attacker does not control.

EMV 3DS 2.3 introduced a device binding feature that lets consumers ask to be remembered on a device, as documented in EMVCo’s description of that release. It is not a passkey mechanism, but it illustrates the same design direction: shifting repeated friction onto an already-proven device, with explicit user consent.

Gotchas that cause production incidents

Empty credential list. The merchant must receive a non-empty credentialIds from the issuer. An issuer with no passkey for the card must tell the 3DS Server to use another method rather than letting the merchant call the API and fail.
Single payment method rule. Putting SPC next to a card or wallet method in the same PaymentRequest raises a RangeError. Run SPC as its own request.
Challenge reuse. The spec calls the challenge a replay defence only. If your store does not consume it atomically, concurrent submissions can both pass.
Amount mismatch. Currency minor units, rounding and shipping added after authentication produce signed totals that differ from the authorisation amount. Decide and document tolerance rules; for variable amounts the RTS expects the maximum agreed amount to be what is linked.
Opt-out and automation. showOptOut produces OptOutError, and automation modes exist for test tooling, so your error handling must distinguish refusal, opt-out, abort and unsupported.
Attestation expectations. Platform authenticators may return no useful attestation, so a policy demanding vendor-attested hardware will exclude real users.

Privacy and tracking concerns

Availability checks leak a bit: whether the browser can do SPC is information a page can learn. The spec limits canMakePayment() to public information, and the browser, not the merchant, controls what the dialog reveals. Keep issuer-provided credential IDs out of long-lived merchant logs, since they are stable identifiers tied to a cardholder, and apply your normal data minimisation duty to them.

Operational anti-patterns

Do not store the assertion only on the PSP side; the issuer needs it for disputes. Do not build a proprietary bridge that re-signs data on the merchant server, because that breaks the very property SPC offers. And do not remove the legacy challenge path after a successful pilot: devices change, browsers update, and the fallback is what keeps every cardholder able to complete payment.

Practical Recommendations

Treat the rollout as three layered capabilities rather than a launch. First, ship issuer-scoped enrolment inside the bank’s authenticated app or site, using the registration ceremony above with the payment extension, and measure enrolment rates before touching checkout. Second, add ACS-hosted WebAuthn in the challenge window, which works wherever WebAuthn works and requires no merchant change. Third, expose SPC to merchants and PSPs that can invoke it, gated by availability checks.

Keep authority where it belongs. The issuer verifies; the merchant and PSP transport. Refuse designs where a merchant asserts “the user passed FIDO” without producing a signature the issuer can verify, unless you intend to use it only as a risk signal in the way EMVCo’s FIDO-data white paper describes.

Write the policy decisions down before engineers do it implicitly: which authenticator types are acceptable, whether synced passkeys count as possession for your supervisor, how amount mismatch is handled, how long challenges live, and what the recovery strength requirement is. Review them with compliance, since regulatory interpretation is outside what an architecture document can settle.

A short checklist for go-live:

[ ] Payment credentials enrolled with isPayment, platform attachment, resident key and required user verification
[ ] Challenge single-use, bound to the 3DS transaction ID, TTL in minutes
[ ] Verifier checks type payment.get, RP ID, user verification flag, total, currency and payee
[ ] Full client data retained for disputes under a documented retention rule
[ ] Three-tier fallback tested: SPC, ACS WebAuthn, legacy challenge
[ ] Recovery requires strength equal to or greater than the lost credential, with revocation and customer notification
[ ] Funnel metrics at dialog, consent, assertion and decision stages
[ ] Browser and webview support matrix reviewed against current vendor docs

Frequently Asked Questions

Secure Payment Confirmation is a W3C specification that runs a WebAuthn authentication through the Payment Request API. Instead of only signing a challenge, the browser shows the payee, amount and payment instrument, collects consent, and signs client data containing those values. A login passkey proves who the user is; an SPC assertion also proves what the user approved, which is the evidence regulators describe as dynamic linking.

Do passkeys satisfy PSD2 strong customer authentication?

A device-held private key unlocked by a biometric or PIN plausibly combines possession with inherence or knowledge, and SPC supplies the amount-and-payee linkage that the technical standard requires for remote payments. Whether a particular implementation is accepted depends on the issuer, scheme rules and the supervisor, particularly for synced passkeys. Treat this as an architectural mapping, and confirm the interpretation with your compliance team and acquirer.

Does SPC replace 3-D Secure?

No. 3DS remains the messaging framework that carries the authentication request from the merchant’s 3DS Server through the Directory Server to the issuer’s ACS and returns an authentication value. SPC and WebAuthn change how the cardholder proves consent during the challenge. EMVCo states that 3DS 2.3 added support for WebAuthn and SPC, and MDN says SPC is supported by EMV 3DS 2.3.1.

Which browsers support Secure Payment Confirmation?

Support is not universal. MDN labels the Payment Request API as not Baseline because some widely used browsers lack it, and its SPC guide shows a Chrome dialog. I did not verify a full current matrix, so consult MDN’s compatibility data and each vendor’s documentation. In every case, call the availability check first and keep a WebAuthn-in-ACS or legacy challenge fallback.

What happens if a user loses their phone?

If the passkey is synced through a platform credential manager, the user may recover it on a new device. Otherwise the issuer should require re-enrolment after a strong step-up, such as the bank app plus an identity check, register a new credential with the payment extension, revoke the old credential IDs, and notify the customer. Recovery must not be weaker than the credential it replaces.

Can a merchant run SPC without redirecting to the bank?

Yes, within limits. The specification supports third-party use when the relying party opted in at credential creation, so a merchant or PSP can launch the ceremony from its own page or iframe. The assertion still verifies against the issuer’s public key. The detection process for third-party enablement is left undefined in the spec, so keep an ACS-hosted fallback.

Passkeys for Payments: FIDO2, WebAuthn and Secure Payment Confirmation in Checkout Flows (2026)

Passkeys Payments Checkout: FIDO2, WebAuthn and Secure Payment Confirmation (2026)

Context and Background

Reference Architecture: The Issuer Owns the Credential