Passkeys represent a fundamental shift in how users authenticate online. Built on the FIDO2 and WebAuthn open standards backed by Apple, Google, and Microsoft, they replace the password model entirely — not just adding a second factor on top of a weak foundation, but removing the shared-secret problem at its root. For payment professionals and ecommerce merchants, this matters because compromised credentials are one of the top vectors for account takeover fraud and checkout abandonment.
How Passkey Works
Passkey authentication follows a well-defined cryptographic handshake. Understanding each step helps payment teams assess integration complexity and explain the flow to compliance stakeholders.
Registration
The user visits your site and initiates passkey creation. The browser or app calls the WebAuthn API, which asks the user's device to generate a public/private key pair. The private key is stored securely on the device (in the Secure Enclave, TPM, or synced keychain). The public key is sent to your server and stored against the user's account — no secret is held server-side.
Authentication challenge
On a subsequent login or payment confirmation, your server issues a random cryptographic challenge. This challenge is unique per session and time-limited, preventing replay attacks.
Local verification
The user's device prompts for a local gesture — a fingerprint scan, face recognition, or device PIN. This unlocks access to the private key stored on the device. The biometric authentication data never leaves the device.
Signature and response
The device signs the server's challenge with the private key and returns the signature to your server. The server verifies it against the stored public key. If it matches, the user is authenticated. No password was typed, stored, or transmitted.
Domain binding
Every passkey is cryptographically bound to a specific origin (domain). A passkey registered on checkout.example.com cannot be triggered by a phishing page at checkout-example.com. This makes passkeys inherently phishing-resistant in a way no password or OTP can match.
Why Passkey Matters
The payments industry has long struggled with the tension between security and conversion. Passwords fail on both fronts — they are both the leading cause of account compromise and a leading cause of checkout abandonment.
The scale of the problem is significant. According to the FIDO Alliance's 2023 Online Authentication Barometer, 54% of consumers abandoned a purchase in the past 30 days because they forgot a password or couldn't log in. Separately, Verizon's 2024 Data Breach Investigations Report found that stolen credentials remain the number-one attack vector, involved in over 68% of breaches. Passkeys address both simultaneously.
Adoption is accelerating rapidly. By late 2024, more than 13 billion user accounts had passkey support available across major platforms (FIDO Alliance). Google reported that passkey sign-ins complete 4× faster than password-based sign-ins and convert at a higher rate. For merchants operating under PSD2, passkeys satisfy strong customer authentication requirements natively — combining possession and inherence factors — which can reduce the friction introduced by SMS OTP during SCA challenges.
FIDO2 and WebAuthn
Passkeys are built on two open standards: FIDO2 (the overarching framework) and WebAuthn (the browser API). The W3C and FIDO Alliance jointly govern these standards, ensuring cross-platform interoperability across iOS, Android, Windows, and macOS.
Passkey vs. Password + MFA
Traditional password-plus-MFA flows remain the dominant authentication pattern in ecommerce, but they come with well-documented weaknesses. The comparison below highlights where passkeys diverge.
| Dimension | Password + MFA | Passkey |
|---|---|---|
| Phishing resistance | Low–Medium (OTPs can be relayed in real time) | High (domain-bound, no secret to relay) |
| Server breach risk | High (password hashes can be cracked) | None (only public keys stored server-side) |
| User friction | High (remember password + retrieve OTP) | Low (biometric gesture or PIN) |
| SCA compliance (PSD2) | Depends on MFA type | Native (possession + inherence) |
| Recovery complexity | Password reset + MFA re-enroll | Cloud sync or backup codes |
| Credential stuffing exposure | High | None |
| Implementation cost | Low (mature ecosystem) | Medium (WebAuthn integration required) |
| Browser/OS support (2024) | Universal | ~95% of active browsers |
Types of Passkey
Not all passkey deployments are identical. The underlying credential storage model affects both the user experience and the security posture.
Synced passkeys are stored in a cloud-backed keychain (iCloud Keychain, Google Password Manager, 1Password) and are available across all devices signed into the same account. These offer the best user experience for consumers — if they buy on mobile and later visit on desktop, the passkey follows them. The trade-off is that the private key is managed by the platform vendor.
Device-bound passkeys (also called hardware-bound or non-discoverable credentials) are stored only on a specific device and do not sync. They offer higher assurance for regulated or high-value transactions. Used extensively with hardware security keys (FIDO2 hardware tokens). More appropriate for merchant staff authentication or high-value B2B payment flows than for consumer checkout.
Conditional UI passkeys surface automatically in the browser's autofill prompt when a user focuses on a username or email field, enabling a near-invisible authentication experience. This is the recommended pattern for consumer checkout flows where two-factor authentication fatigue is a concern.
Best Practices
Deploying passkeys in a payment context requires thinking about both the merchant-facing configuration and the developer integration.
For Merchants
Offer passkey enrollment at account creation and post-purchase, not only at login. Users who have just completed a successful checkout are in a high-trust moment and more likely to opt in. Display a clear value proposition — "Sign in faster next time with Face ID" — rather than technical terminology.
Maintain a fallback authentication path. Passkeys cover the majority of users, but edge cases exist: older devices without biometric sensors, users who reset their devices, or users who use shared devices. A verified email link or fraud prevention-screened OTP should remain available.
Track passkey adoption as a conversion metric. Segment checkout conversion rates by authenticated users (passkey vs. password) to build a business case for further investment in the rollout.
For Developers
Set the rpId (Relying Party ID) to the effective top-level domain, not a subdomain, so passkeys work across www., checkout., and app. subdomains. Use the WebAuthn mediation: "conditional" parameter to enable autofill-style passkey prompts on login forms.
Store the full credentialId, publicKey, signCount, and aaguid for each registered credential. The signCount should be validated on every authentication to detect cloned credentials. The aaguid identifies the authenticator model and can be used for risk-based routing decisions.
Implement attestation verification for high-assurance flows (e.g., first-time high-value payments) to confirm the credential was generated by a genuine FIDO-certified authenticator rather than a software emulator.
Common Mistakes
Treating passkeys as a drop-in password replacement without a recovery path. If a user loses access to their device and has no backup, they are locked out permanently. Always implement account recovery before deploying passkeys at scale.
Using a subdomain as the rpId. Setting rpId to checkout.example.com means passkeys registered there cannot be used on www.example.com. Use example.com as the rpId and list permitted origins explicitly.
Skipping signCount validation. The sign count is a monotonically increasing counter that detects credential cloning. Ignoring it removes one of the few server-side signals available for detecting compromised authenticators.
Failing to communicate the UX clearly. Passkeys are new enough that many users do not recognize the browser prompt. Without clear in-product messaging, users dismiss the prompt and fall back to passwords, undermining adoption.
Not testing cross-platform flows. A passkey enrolled on an iPhone should be testable on a Windows browser via QR code cross-device flow. Many teams test only the same-device path and ship a broken cross-device experience, which affects users who switch devices mid-session — common in payment flows started on mobile and completed on desktop.
Passkey and Tagada
Using passkeys in payment orchestration flows
Tagada is a payment orchestration platform that sits between your commerce layer and your processors. When you implement passkeys for customer authentication, Tagada can use the authentication signal — specifically the userVerification result and aaguid — as an input to dynamic routing and risk-scoring logic. A passkey-verified session can be flagged as lower-risk, enabling Tagada to route that transaction through a processor with more favorable SCA exemption rules, reducing unnecessary 3DS friction for your highest-confidence buyers. Work with your Tagada integration team to pass authentication context as transaction metadata.