Passkeys change who gets to vouch at checkout

A passkey does not simply replace the password or one-time code in a checkout. It redistributes the right to make a trust claim. The device verifies a local gesture and signs with a credential private key. The relying party—possibly a merchant, wallet service, payment service provider or issuer—decides which account that key represents. The merchant supplies the purchase context. The issuer still decides whether the payment may proceed.1239

That makes the familiar face scan deceptively ambiguous. A merchant passkey can establish access to a shopper account. A Click to Pay passkey can unlock a card tray. An issuer-linked payment passkey can authenticate a cardholder relationship across participating merchants. Those are three different statements from three different guarantors.234 None, on its own, says that this amount was confirmed for this payee or that the issuer approved the transaction.79

The authenticator vouches for a ceremony, not a biography

At registration, a WebAuthn authenticator creates an asymmetric key pair. The relying party stores the public key; the authenticator manages the private key. At authentication, the relying party supplies a server-generated challenge, and the authenticator returns a signed assertion that the relying party verifies.1 Because the credential is scoped to a relying-party identifier, a phishing origin cannot ask the authenticator to use a credential registered for another relying party.15

The device also reports whether user presence or user verification occurred. Verification may use a biometric, device PIN or password, but that check happens inside the authenticator boundary; biometric information is not sent to the relying party.15 What arrives at the server is cryptographic evidence about the ceremony, not a fingerprint image and not a portable identity credential.

Even “user verified” has a precise limit. WebAuthn says it does not give the relying party a concrete identification of the user. Repeated verified ceremonies indicate the same user of that credential, but shared access to an authenticator can mean that this is not always the same natural person.1 The passkey therefore inherits its business meaning from enrollment. If a bank established the cardholder relationship before registration, the later signature can stand for that relationship. If a merchant registered it after a weak account-recovery flow, the same cryptography stands on a weaker foundation.

The relying party determines who is speaking

In conventional EMV 3-D Secure, the merchant sends transaction, account and device data through the 3DS system. The issuer, or its Access Control Server, performs risk assessment and may request a challenge. Low-risk transactions can proceed through a frictionless flow without explicit credential verification.2

Passkeys make more than one allocation of responsibility possible. The W3C, EMVCo and FIDO joint architecture describes an issuer as both relying party and validator in one flow. In another, a merchant or PSP is the relying party, validates its own FIDO or Secure Payment Confirmation assertion, and supplies that prior authentication as evidence through 3DS. A third model lets the merchant initiate an SPC ceremony for an issuer-owned credential and return the assertion to the issuer for validation.2

The biometric prompt can look similar in all three. The trust path is not. When the merchant is the relying party, it is effectively saying, “the holder of the credential registered to this merchant account approved here.” The issuer may use that evidence but can still challenge. When the issuer is the relying party, the merchant is carrying a claim it cannot itself validate; the issuer holds the public key and interprets the enrollment.2 Integration fields must preserve that distinction instead of flattening every outcome into passkey_success.

A wallet can vouch for access without vouching for payment

Wallet language often compresses identity, card discovery and payment authorization into one action. The mechanisms remain separate. EMVCo’s Click to Pay guidance says an SRC system can use a passkey to verify a customer and unlock the card tray.3 That establishes access to a wallet profile and its linked instruments. It does not automatically establish that one displayed card was authorized for one purchase.

The selected instrument may carry a different proof. An EMV payment token substitutes for a PAN and may be constrained to a merchant, device or payment scenario.6 A token service can therefore vouch that a payment credential is valid within a defined domain, while the passkey vouches that a locally verified user accessed the wallet or payment account. Combining them is useful precisely because they answer different questions.

This separation exposes a concrete failure mode. A checkout can successfully authenticate the wallet user, then send a token outside its permitted domain or lose the authentication evidence expected by the issuer. Conversely, a valid domain-constrained token does not prove that a passkey ceremony confirmed the current purchase.6 “Wallet authenticated” should never silently substitute for “transaction confirmed.”

Transaction binding gives the browser a new job

Plain WebAuthn signs a challenge and origin-bound client data, but it does not specify a trusted display for a payee, amount and payment instrument. Secure Payment Confirmation adds that payment layer. It allows a merchant or another entity to initiate a ceremony on a relying party’s behalf, if the relying party opted in when the credential was created.7

During SPC, the user agent must communicate the payment details and collect consent. The signed client data can include the payee, amount, currency and instrument, allowing the verifier to compare what the browser presented with the transaction it expects.7 This changes the browser from a pipe for an authentication prompt into a participant that vouches for the integrity of the confirmation display. The EU’s dynamic-linking rule expresses the same security objective: the payer must be aware of the amount and payee, and any change to either must invalidate the authentication code.8

The protection is not automatic. The merchant still supplies transaction data. The SPC specification explicitly tells the bank to verify the assertion against the expected details because a third party provided the values shown to the user.7 If the amount changes after authentication, if the payee identifier is mapped inconsistently, or if the verifier checks only the signature and not the signed payment fields, the system has authenticated a ceremony while losing the purchase it was meant to bind.

The issuer keeps the last word

Authentication produces evidence; authorization produces a payment decision. Visa’s public definition of authorization is an approval or decline for a specific transaction request from the issuer, or from the network standing in for it.9 A successful passkey assertion cannot establish available funds, account status, issuer risk policy or whether this particular request should be approved.29

That boundary survives even when passkey authentication is issuer-backed. EMV 3DS is designed to give the issuer transaction context for risk assessment and a challenge path when more evidence is required.24 SPC can strengthen that evidence by binding user verification to payment details. It does not collapse authentication and authorization into one cryptographic event.

The operational consequence is sharp. A system must preserve the authentication result and the authorization result as separate records. It should be possible to see who was the relying party, who initiated the ceremony, who validated the assertion, what transaction fields were signed, what payment credential was presented and which issuer decision followed. Without that lineage, disputes and retries turn several trust claims back into one misleading green check.

Recovery is where the trust shift becomes visible

Passkeys can be device-bound or synced across devices.45 Synced credentials improve recovery, but they introduce the passkey provider’s platform account and recovery controls into the trust chain. FIDO’s high-assurance guidance notes that a relying party may not know when a synced passkey was recovered, and that the credential is only as secure as the platform account with which it is associated.10

Device-bound credentials keep tighter control over where the private key resides, but a lost device requires another recovery route or a separately registered authenticator.10 Either design makes enrollment and recovery part of payment authentication, not peripheral account settings. An attacker who cannot forge a signature may instead target the process that registers a new credential, restores a synced one or falls back to an SMS code.10

The old question at checkout was often, “Did the issuer authenticate the cardholder?” Passkeys require a more exact set: Which party enrolled the credential? Which authenticator verified the user? Which relying party verified the signature? Which component vouched for the wallet or token? Which actor bound the amount and payee? Which issuer approved the payment?

That is the real change. Passkeys make authentication stronger by making the proof scoped and cryptographic.15 They also make trust allocation impossible to ignore. Checkout is no longer one party asking for a secret and another accepting it. It is a chain of bounded claims, and the system is only as trustworthy as the hand-offs between them.

Sources

“Web Authentication: An API for accessing Public Key Credentials — Level 3” — World Wide Web Consortium — https://www.w3.org/TR/webauthn-3/ (opens in a new tab)

“How EMVCo, FIDO, and W3C Technologies Relate” — World Wide Web Consortium — https://www.w3.org/TR/htr/ (opens in a new tab)

“Using a passkey” — EMVCo — https://www.emvco.com/dynamic/click-to-pay-cx-guidelines/cx-moments/using-a-passkey/ (opens in a new tab)

“Understanding the Use of Passkeys in Payments” — EMVCo — https://www.emvco.com/knowledge-hub/understanding-the-use-of-passkeys-in-payments/ (opens in a new tab)

“User Authentication Specifications” — FIDO Alliance — https://fidoalliance.org/specifications/ (opens in a new tab)

“EMV Payment Tokenisation” — EMVCo — https://www.emvco.com/emv-technologies/payment-tokenisation/ (opens in a new tab)

“Secure Payment Confirmation” — World Wide Web Consortium — https://www.w3.org/TR/secure-payment-confirmation/ (opens in a new tab)

“Commission Delegated Regulation (EU) 2018/389” — EUR-Lex — https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32018R0389 (opens in a new tab)

“Glossary: Authorization” — Visa Developer — https://developer.visa.com/pages/glossary (opens in a new tab)

“White Paper: High Assurance Enterprise FIDO Authentication” — FIDO Alliance — https://fidoalliance.org/white-paper-high-assurance-enterprise-fido-authentication/ (opens in a new tab)