Passkeys are emerging as the most effective method for securing and authorizing online transactions, significantly improving security and convenience compared to traditional multi-factor authentication (MFA). Recently, PayPal adopted passkeys as their primary self-contained MFA solution, setting a clear trend for payment providers worldwide.

However, passkeys were originally designed with first-party contexts in mind, meaning they function optimally when users authenticate directly on the website or app that owns the credentials. Payment providers, in contrast, typically operate within third-party contexts, where their services (such as payment forms or SDKs) are embedded into merchants’ websites and apps. This fundamental mismatch between passkey design and payment providers’ operational models presents critical limitations for seamless integration. To address these challenges, we must explore two critical questions:

1. What are the current limitations of using passkeys within third-party contexts for payment providers?

2. How can payment providers overcome these limitations to successfully implement third-party passkey integrations?

By examining these questions, we will reveal that ongoing industry efforts to adapt passkeys to third-party contexts - particularly through web standards like Secure Payment Confirmation (SPC) - are blocked by strategic barriers implicitly imposed by Apple. Specifically, Apple’s limited support for cross-origin passkey creation in Safari and missing support from the Secure Payment Confirmation Standard represents a significant roadblock, complicating the seamless adoption of passkey-based authentication by third-party payment providers. Understanding and overcoming these hurdles is essential for any provider aiming to deliver frictionless, secure payment experiences.

Passkeys bring phishing-resistant, biometric-based login to every layer of the payment stack. Below is a breakdown of how each player in the payment value chain can benefit from integrating passkey authentication.

Impact: Faster checkout, higher conversion, fewer cart abandonments.
Opportunity: Merchants offering passkeys via SDKs or redirect flows can mimic Apple Pay-level UX and reduce reliance on passwords or OTPs - leading to higher trust and sales.

Impact: Seamless, passwordless authentication across devices.
Opportunity: Passkeys offer a better UX than OTPs or SMS codes and eliminate phishing risk. Broad adoption could turn passkeys into the new default for cardholder verification.

Impact: Stronger fraud prevention.
Opportunity: Issuers can offer passkey-based step-up authentication in 3DS flows, lowering OTP costs and improving user satisfaction.

Impact: Higher transaction acceptance and fewer failed authentications.
Opportunity: Supporting passkeys through PSPs can improve merchant outcomes and reduce friction during checkout or recurring billing flows.

Impact: Reduced fraud, better merchant UX, and improved compliance.
Opportunity: By embedding or redirecting passkey flows, PSPs can provide next-gen authentication while maintaining compatibility across browsers and native apps.

Impact: Streamlined transaction approvals with fewer declined payments.
Opportunity: Payment processing companies can integrate passkey verification into their APIs to reduce risk and support biometric SCA alternatives for compliant flows.

Impact: Secure credential storage and frictionless reauthentication.
Opportunity: Wallet providers like Apple Pay and Google Pay already use passkey-like flows.

In the following, we take a short look at major payment and credit card providers and analyze if and how they have implemented passkeys:

Mastercard has officially launched its Payment Passkey Service, providing a passwordless authentication experience that’s embedded into EMV 3DS flows. Users can create and use passkeys tied to Mastercard’s authentication domain (e.g. verify.mastercard.com), enabling secure, biometric login across participating merchants. This rollout represents a major step towards phishing-resistant, PSD2-compliant authentication in the payment industry.
Read more: Mastercard Passkeys

Visa has introduced its Visa Payment Passkey Service, integrating passkeys into the “Click to Pay” flow. By allowing users to authenticate seamlessly using biometrics instead of passwords or OTPs, Visa is aiming to modernize the online checkout experience with enhanced security and user convenience.
Read more: VISA Passkeys

American Express has not publicly launched a passkey offering yet. However, as a board-level member of the FIDO Alliance, it is likely that American Express will roll out a passkey-based authentication solution in the near future, in line with broader industry trends.

PayPal was one of the first payment providers to adopt passkeys. Their rollout supports seamless biometric login for personal and business accounts across devices. The passkey is bound to PayPal’s domain and is already available in many regions. However, their implementation has room for improvement, especially when it comes to multi-device flows and platform detection.
Read more: PayPal Passkeys

Klarna has not officially introduced passkey support yet. From our observations, Klarna heavily relies on embedded WebViews in their app and checkout SDKs. Since Safari and iOS restrict passkey creation in iframes / WebViews, this might be a reason why Klarna hasn’t rolled out passkeys so far.

Square has introduced passkey login for their developer dashboard and management console, allowing secure, passwordless access to internal tools. However, no announcement has been made regarding passkey support in payment flows or APIs for end users or merchants.

Stripe has rolled out passkey login for their dashboard, enabling developers to authenticate using biometrics. Passkeys for Stripe Checkout or Elements are not yet available. Given Stripe’s strong advocacy for redirect-based flows, it’s likely that passkeys - if implemented in payments - would follow that same redirect architecture.

As of now, BILL has not made any public announcements or product updates related to passkeys for authentication..

Remitly has not disclosed any plans or public information about implementing passkey authentication in their services..​

There are no public reports or product documentation indicating that Payoneer has adopted or is testing passkey-based login or transaction flows.​

Adyen has not yet introduced passkeys into their authentication or payment flows. No public statement or developer documentation mentions passkey support.

Worldpay has not announced any support for passkeys as of now. Their authentication stack still relies on traditional methods such as passwords, OTPs, and 3DS-based flows.

Checkout.com has not publicly rolled out passkey support. There are no developer updates, blog posts, or official announcements regarding passkey adoption.​

AliPay has not officially launched passkeys. Given the growing trend in biometric authentication within Chinese payment ecosystems, a rollout may happen in the future, but no current documentation confirms this.​

Mollie has not made any public statements or product updates regarding the adoption of passkeys in its authentication or checkout systems..

Amazon has rolled out passkey support for user logins on its main platform. Extending this technology to Amazon Pay would be a natural next step, especially since many users already have a passkey registered with Amazon, which would significantly simplify user onboarding during checkout.

Braintree, a PayPal company, has not officially adopted passkey authentication yet. Their current documentation does not mention passkeys in the context of user login or merchant APIs.​

Link, Stripe’s one-click checkout solution, has rolled out passkeys might serve as the foundation for Stripe’s passkey strategy in consumer payments. However, Stripe has not officially announced passkey support for Link or any specific plans for rollout.

Afterpay has not released any statements or features related to passkey support. Like Klarna, their checkout integration is heavily app-based, which may pose technical hurdles for passkey adoption due to embedded WebView constraints.​

The adoption of passkeys by third-party payment providers faces strategic obstacles, primarily driven by Apple’s restrictive policies in Safari. Two critical standardization attempts have been consistently impeded:

• Secure Payment Confirmation (SPC)

• Third-Party Passkey Creation in Iframes

Secure Payment Confirmation (SPC) represents the industry’s most significant effort - primarily driven by Google to enable seamless, cross-origin use of passkeys specifically tailored for secure payment authorizations. SPC standardizes how payment providers authenticate users across multiple merchant sites without compromising security or user experience. However, Apple has consistently withheld support for SPC within Safari, likely as a strategic move to ensure that Apple Pay remains the preferred, most frictionless payment solution within its ecosystem. Apple’s refusal to adopt SPC not only limits the widespread deployment of passkeys in third-party contexts but also effectively delays broader industry adoption of standardized payment authentication.

Read this blog post about SPC if you want to learn more about the details.

Another critical barrier involves Apple’s deliberate restriction of passkey creation within cross-origin iframes. While Safari permits using existing passkeys for authentication (navigator.credentials.get()) in a third-party iframe, it explicitly blocks passkey registration (navigator.credentials.create()) in such contexts.

This limitation severely restricts payment providers who depend on creating new passkeys seamlessly during the merchant checkout flow. Consequently, providers are forced either into redirect-based approaches or must rely on existing passkeys previously established directly on their own domains. This decision by Apple directly affects the practicality and fluidity of merchant integrations, creating a significant friction point for consumers and providers alike.

In this approach, the merchant includes your payment form in an <iframe> served from your payment-provider domain - for example, https://pay.provider.com. The user stays on the merchant’s domain (e.g. https://www.mystore.com), sees your payment UI in the embedded iframe and authenticates with a passkey bound to the Relying Party ID pay.provider.com.

Key Points:

• Cross-Origin: Because the iframe is on a different domain, you must configure permission policies for publickey-credentials-get and publickey-credentials-create to allow passkey operations inside the iframe.

• Creation Limitation: Some browsers (particularly older versions and Safari) still do not allow passkey creation in cross-origin iframes. Authentication (navigator.credentials.get()) is more widely supported, but registration (navigator.credentials.create()) may fail in certain environments, especially in Safari.

• User Activation: Passkey flows typically require “transient activation” (e.g. a direct button click from the user). Ensure that your iframe interface triggers the passkey ceremony within a user-initiated event.

• Security & UX: The iframe approach provides a smooth, inline checkout experience, but if a user’s browser blocks or restricts third-party cookies or local storage, it may disrupt the passkey flow.

With a redirect-based flow, you send the user from the merchant’s domain to your payment domain, or open a new tab/window pointing to something like https://pay.provider.com/checkout. Passkeys are then created or used directly on your domain in a first-party context.

Key Points:

• First-Party Simplicity: The entire passkey workflow (creation, authentication) happens on the payment provider’s domain, so there are no cross-origin restrictions. All major browsers support passkey creation and login in first-party contexts.

• Redirect UX: The user leaves the merchant page (or sees a pop-up) to complete authentication. This can be less seamless, but it simplifies the passkey architecture and reduces cross-origin complexities.

• Fallback for Incompatible Browsers: You can gracefully degrade if passkeys are unavailable (e.g. older browsers) by providing alternative login methods on your payment domain without needing extra cross-origin permission handling.

Integrating passkeys within native mobile apps presents unique challenges compared to web-based scenarios. Native apps for merchants (on both iOS and Android) often embed payment flows within the application using embedded WebViews to maintain a seamless user experience. However, implementing third-party passkey authentication in these embedded contexts can be problematic due to strict browser-origin policies and platform-specific limitations.

Passkeys are inherently bound to a specific domain (the “Relying Party ID”), which is a core security principle ensuring that credentials cannot be misused across unrelated websites or apps. When a payment provider creates passkeys under its own domain - e.g., pay.provider.com - those passkeys are strictly scoped to that domain in both iOS and Android. As a result, a merchant’s native app (which naturally operates under the merchant’s own app identifier and domain) cannot directly invoke the provider’s passkeys as a “first-party” credential. Doing so would require cross-origin sharing of private keys, which the operating systems and WebAuthn specifications explicitly disallow to prevent phishing and credential theft.

From the device’s perspective, the merchant’s native app is a different “origin” than the payment provider’s domain. Attempting to authenticate natively against credentials registered to a separate origin would break the fundamental origin-bound security model of passkeys. This is precisely why third-party passkey usage in a merchant context depends on a system browser or a system-based WebView (like ASWebAuthenticationSession on iOS or Chrome Custom Tabs on Android). These special flows preserve the provider’s original domain context - ensuring passkeys remain securely origin-bound - while still allowing users to authenticate with the payment provider inside a merchant’s app. In the following sections, we’ll explore how this works.

Embedded WebViews (e.g., WKWebView on iOS or Android’s WebView) are widely favored because they allow apps to embed web content directly into their native interfaces, offering tight integration and UX consistency. However, these embedded environments are significantly restricted when handling third-party passkeys due to origin and security policies:

• Origin Mismatch: Passkeys rely strictly on domain origins for secure credential handling. An embedded WebView operates under the domain of the content it displays (often the merchant’s), making it challenging or impossible to create or authenticate passkeys tied explicitly to a third-party payment provider’s domain.

• Platform Security Constraints: Both Apple (iOS) and Google (Android) have progressively restricted embedded WebViews’ capabilities for authentication, particularly when dealing with secure credentials. These constraints are designed to protect user privacy and security but make third-party passkey implementation notably more complicated.

Overall, while embedded WebViews are attractive for merchants from a UX perspective, they introduce significant practical limitations for implementing robust third-party passkey authentication flows.

Given the limitations associated with embedded WebViews, payment providers typically adopt one of two alternative strategies to reliably implement third-party passkeys in native mobile apps:

iOS (ASWebAuthenticationSession):

Apple provides ASWebAuthenticationSession as a secure, browser-like environment outside the host application’s context. It shares cookie storage with the default Safari browser and supports third-party passkeys reliably because credentials align with the payment provider’s origin domain.

The following example demonstrates the “Check out with PayPal” functionality within the BOSS native app. It shows how an ASWebAuthenticationSession system webview is opened, which shares its state with Safari cookies, allowing the passkey dialogue to start immediately.

Android (Chrome Custom Tabs):

Similarly, Android’s Custom Tabs offer a near-browser environment allowing consistent passkey creation and authentication. Like ASWebAuthenticationSession, Custom Tabs run separately from the merchant’s app context, ensuring domain and credential integrity.

See the same example from the BOSS native app on Android here:

Another approach involves redirecting users out of the native app into the mobile device’s default web browser (Safari on iOS, Chrome on Android). This ensures the payment flow - and thus passkey management - occurs entirely in a trusted, first-party context associated with the payment provider’s domain. Users then return to the merchant app after successful authentication or payment completion. This option is very inconvenient for customers because they have to leave the app.

Both solutions require temporarily transitioning users out of the merchant’s native app environment. Although slightly less seamless compared to embedded solutions, these approaches significantly improve compatibility, security and reliability of third-party passkey operations.

Ultimately, payment providers developing native SDKs must carefully balance user experience considerations with practical technical constraints. Despite merchant preferences for fully embedded experiences, leveraging system WebViews or external browser redirection remains the best practice for ensuring secure, dependable third-party passkey authentication within native apps.

Choosing between an embedded (iframe) approach and a redirect-based approach for integrating third-party passkeys into payment SDKs involves evaluating trade-offs across user experience, browser compatibility, technical complexity and merchant preferences.

Both solutions have distinct advantages and disadvantages, which payment providers should carefully consider based on their target market, desired UX and technical infrastructure.

The embedded (iframe) approach offers a seamless, merchant-branded user experience highly attractive to merchants, but is hindered by limited browser compatibility, particularly Safari's refusal to allow cross-origin passkey creation. This limitation forces merchants and providers into complex, workaround-based solutions that often compromise functionality or lead to incomplete support for passkey registration.

Conversely, the redirect approach offers comprehensive compatibility across browsers and native mobile platforms by operating in a first-party domain context. It significantly simplifies integration, improves reliability and ensures full passkey creation and authentication support. The main drawback is the potential friction created by redirecting users away from the merchant’s website or app, though this can be mitigated with careful UX design, clearly communicated expectations or integrations with trusted platforms like Corbado.

Given these considerations, a hybrid approach is often ideal, allowing payment providers to leverage the embedded iframe model when the user’s browser supports it and gracefully fallback to a redirect approach otherwise. This combined strategy maximizes compatibility, merchant attractiveness, and customer satisfaction across diverse environments.

Implementing a third-party passkeys payment SDK involves balancing user experience, browser compatibility, native app constraints, analytics and security - especially given Apple-specific hurdles (e.g. blocking cross-origin passkey creation, missing SPC support). Below are key recommendations to ensure the best possible outcome when integrating passkeys into web or native payment flows.

Because of varying browser support and inconsistent Apple behaviors, supporting both an embedded (iframe-based) approach and a redirect approach is critical:

• Iframe Checkout (Embedded)

  • Provides a seamless, on-page experience for modern browsers that do allow cross-origin passkey operations (primarily for authentication).

  • Must set the correct Permissions-Policy for publickey-credentials-get/publickey-credentials-create.

  • Note that Safari and some older browsers block cross-origin passkey creation in iframes.

• Redirect Flow

  • Reliably supports both passkey registration and login in a first-party context.

  • Slightly more friction due to the extra redirect or pop-up, but universally safer for cross-browser compatibility.

  • Ideal fallback for Safari, which does not currently permit third-party passkey creation in iframes.

By offering both approaches, you can dynamically decide - or let merchants decide - which to use, maximizing compatibility for all user environments.

Detecting browser capabilities accurately remains challenging due to reduced User-Agent granularity and inconsistent support for Client Hints across platforms.

Traditional parsing is increasingly unreliable as browsers reduce the detail in User-Agent strings to protect user privacy. Differentiating essential details - such as Windows 10 vs. Windows 11, precise macOS versions or CPU architectures - is now difficult or impossible using User-Agent alone.

While Client Hints provide high-entropy data in a privacy-respecting way, only Chromium-based browsers fully support them. Safari and Firefox offer no Client Hint support, severely restricting precise feature detection on Apple devices.

Embedded WebViews typically restrict access to detailed device information and rarely support Client Hints. This limitation makes passkey capability detection especially challenging within native app contexts.

Given these constraints, reliably detecting cross-origin passkey support - particularly in third-party payment SDKs - requires careful combination of dynamic Client Hint queries (where available), fallback User-Agent heuristics and conservative default behaviors for browsers like Safari and Firefox.

Native merchant apps often embed web content in WKWebView (iOS) or Android WebView, which are very restrictive for passkeys. Common strategies include:

• System Browser Sessions: Use ASWebAuthenticationSession (iOS) or Custom Tabs (Android) to shift passkey creation/login to a secure “first-party” browser context.

• Redirect to Default Browser: A less seamless but highly reliable approach to ensure domain integrity for passkey operations.

As a payment provider, strong security and regulatory compliance (PCI, PSD2 SCA, etc.) are key:

• Headers & Content Security: Implement strict Permissions-Policy headers and robust CSP rules for cross-origin flows.

• Logging & Monitoring: Thoroughly log passkey creation and usage events for fraud prevention and compliance audits.

• Minimal PII Storage: Map users to passkeys using hashed identifiers, reducing exposure under GDPR or similar data protection laws.

• Audit Trails: Log each passkey creation and authentication event to detect anomalies and satisfy compliance audits.

Passkeys are still evolving, so you’ll need ongoing checks:

• Cross-Browser & Cross-OS Testing: Automate tests in Safari, Chrome, Edge, Firefox and major mobile OS versions.

• Frequent Updates: Track changes in W3C WebAuthn specs, FIDO Alliance guidelines or SPC proposals.

• User Feedback & Error Rates: Log passkey errors (creation or login) to rapidly fix issues, especially for Apple-based users.

A robust KPI framework helps you track whether your third-party passkey integration truly improves security and user experience. Even though this article is about implementing SDKs it’s important to keep in mind that passkey adoption is also key in this use case. Creation-rate and usage-rate of passkeys needs careful analysis and optimization.

• Definition: Percentage of users who successfully create a passkey when prompted (e.g. at checkout or account setup).

• Why It Matters: A high creation rate means your onboarding/nudge flow for passkeys is compelling and friction-free.

• Target: You should aim for a rate for 50-80%

• Definition: Among users who begin the creation ceremony (click “Create Passkey”), how many finalize without aborting or error?

• Why It Matters: Indicates how well your cross-origin or redirect flow is working.

• Target: Ideally, you have a number of ~95–100% once a user opts in.

• Definition: The percentage of total payment authorizations (or logins) done via passkeys, as opposed to fallback methods.

• Why It Matters: Creation is meaningless if users default back to older methods.

• Target: A rate of 50–80% signals strong passkey adoption.

• Definition: Percentage of passkey login attempts that succeed without error or fallback.

• Why It Matters: A reflection of your real-world usability.

• Target: Typically you should exceed 90–95% to consider passkeys “frictionless.”

• Definition: How often do users fail on passkeys mid-ceremony and switch to a password or OTP?

• Why It Matters: High fallback usage suggests technical or UX hurdles are preventing passkeys from replacing legacy methods.

• Target: Ideally, the fallback usage is less than 1-5%

For payment providers, measure whether passkeys reduce fraud, accelerate checkout or lower cart abandonment. Combine passkey usage data with payment conversion or 3-D Secure success metrics for a holistic view.

Monitoring these KPIs helps you pinpoint which environments or user journeys need improvement - e.g. if Safari iOS has a higher abandonment rate due to cross-origin blocks, you can systematically direct those users to a redirect flow.

One of the most critical challenges in building a third-party passkeys SDK is orchestrating a smooth and consistent creation flow - where users actually register their passkeys. Whether this occurs in a bank’s portal, within the payment provider’s own account settings or right on a merchant’s checkout page, the core passkey registration steps are very similar. Consequently, the approach to passkey creation does not fundamentally change based on whether you embed the flow in an iframe or redirect the user to a first-party page; what matters most is providing clear, user-friendly screens, managing cross-origin constraints and tracking the essential metrics that show how effectively users adopt passkeys. Below are the key aspects of a best-practice passkey creation flow and how Corbado supports them:

Regardless of where a user is prompted to create a passkey - be it a bank’s online banking environment, the payment provider’s own website/app or a merchant’s checkout - Corbado provides pre-built, customizable components for user prompts, success confirmations, and error handling.

These components ensure a consistent look and feel while allowing white-label branding so that each bank or merchant can retain its unique design elements if required.

See the following UI component for the passkey creation screen branded in VicRoads design:

Corbado collects and unifies data from all creation endpoints:

• Bank websites or apps where passkeys are initially offered.

• The payment provider’s personal account settings (where users can manage credentials).

• Merchant checkout pages that optionally allow passkey creation “on the fly.”

This unified approach makes it easy to measure passkey creation rate, creation success rate, user drop-off points and any technical errors - no matter which channel initiates the passkey registration.

Corbado offers A/B testing features to fine-tune on-screen instructions, button text and timing of prompts. Subtle changes in wording (e.g., “Create a passkey now - no more passwords!” vs. “Secure your next payment with a passkey!”) often yield significant differences in user acceptance.

Based on the results of the A/B test, the following KPIs can be optimized:

• Creation Rate: Percentage of users who, once prompted, successfully set up a passkey.

• Creation Success Rate: The share of users who finish the ceremony without aborting or error.

• Fallback Usage: The rate at which users skip passkey creation in favor of older login methods.

• Conversion Impact: For merchants, measure whether passkey creation at checkout reduces cart abandonment.

Users can create passkeys in the following contexts:

• Bank Context: Creation flows triggered after a user logs in to their bank, leveraging the trust and familiarity of the banking environment.

• Payment Provider Account Settings: Users set up passkeys directly in their “My Profile” or “Security” settings of the payment provider’s domain.

• Merchant Checkout: Prompt on the final payment step, especially if the user hasn’t previously created a passkey. This can be embedded (iframe) or via redirect.

In each scenario, the underlying passkey ceremony follows the same steps - user confirmation, biometric/PIN prompt and credential registration. Corbado’s SDK ensures that cross-origin constraints (if embedded) or first-party domain context (if redirected) are handled seamlessly in the background.

Corbado attaches each new passkey to the appropriate user identifier - whether that’s “bankPrefix_userId” or an internal user reference in the payment provider’s system - so that all subsequent usage is traceable to the correct user account.

This metadata is also crucial for advanced analytics: for example, seeing how RBC’s passkey creation campaigns perform compared to TD’s, or how creation rates differ between merchant checkouts and direct “account settings” flows.

The same Corbado SDK logic can adapt to whether cross-origin passkey creation is allowed (in modern Chrome or Edge) or must gracefully switch to a redirect for Safari.

Built-in error reporting helps identify if any subset of users consistently fails passkey creation (e.g., older iOS versions, corporate Windows devices), so the product team can refine instructions or fallback strategies.

Our team has run extensive passkey creation experiments with enterprise clients, learning which phrases, button placements and timing yield the best adoption rates.

We incorporate these best practices into every creation screen, while still allowing full customization for branding and compliance needs.

Overall, passkey creation stands as the single most important phase to ensure high adoption: even the most elegant passkey login flow won’t matter if users never register credentials in the first place. By offering uniform, trackable creation screens across all possible channels - bank, payment-provider domain or merchant checkout - and instrumenting them with KPI analytics and A/B testing, Corbado helps payment providers drive truly scalable passkey adoption, mirroring the user experience of native solutions like Apple Pay.

Once a user has created a passkey, the next step is ensuring they actually use that passkey for quick, frictionless payments like Apple Pay presents a Apple Pay payment flow.

At Corbado, we’ve developed a “Passkey Intelligence” mechanism that automatically detects when a user’s environment likely contains a valid passkey, enabling a true one-tap payment experience. Below are the core elements that make this possible.

When a returning user is recognized, Corbado’s front-end displays a dedicated button (e.g. “Pay with Passkey”) rather than forcing fallback credentials entry.

One tap on this button triggers the WebAuthn get() flow (or native passkey prompt), letting the user authenticate instantly via biometrics/PIN - no additional steps or form inputs required.

Corbado’s SDK gathers signals (e.g. local storage cookies, prior successful passkey usage, environment detections) to predict if the current device + browser likely has a valid passkey for this user.

If cookies are deleted or unavailable, Corbado falls back to additional heuristics (e.g., existing known environment of the user, user hints provided by the merchant) to decide whether it’s safe to auto-start a passkey flow.

If insufficient evidence suggests a passkey is present, the UI gracefully offers fallback flows or prompts the user to confirm they have a passkey.

Corbado does not store personally identifiable information (PII) like full emails or names.

Instead, the merchant can pass a hashed or masked identifier (e.g. an email hash or internal user ID). Corbado uses that to look up potential passkey registrations, then decides whether to start a passkey authentication or to revert to a more generic approach. If supported by the payment provider we can look up the provided information by the merchant to look up the internal user ID.

This ensures user privacy while still allowing high-accuracy environment matching.

In scenarios where the user’s passkey might have existed but can’t be detected (e.g., cookies are wiped, new device), Corbado’s Passkey Intelligence carefully analyzes if auto-start a passkey prompt makes sense.

Instead, the user would see alternative fallback flows or a “scan passkey from another device” option while still preserving a quick path back to passkey usage if the user can manually confirm they do have one.

Every time Corbado chooses to initiate or skip a one-tap passkey prompt, that decision is logged. Over time, you can see precisely which browsers or device types yield the highest passkey coverage vs. those that frequently revert to fallback.

This analytics feedback loop allows you to identify underperforming environments (e.g., specific iOS or Android versions) or user segments where passkey usage remains low - so you can refine onboarding or education strategies.

Regardless of whether the user arrives from a bank’s passkey creation campaign or directly at a merchant’s checkout, the one-tap logic remains consistent.

Corbado ensures that if a passkey is found (based on domain cookies, local storage tokens, or passkey intelligence signals), the user is immediately presented with the most frictionless login/payment flow.

Summary

In short, one-tap passkey usage is the ultimate payoff for creating passkeys in the first place. By leveraging Passkey Intelligence - a blend of environment detection, minimal PII usage, and fallback logic - Corbado ensures users are presented with passkey authentication only when it is truly likely to succeed. This dramatically reduces failed attempts, avoids user frustration and fosters habit-forming passkey usage, culminating in a one-tap payment flow that rivals the convenience of Apple Pay or other native payment experiences.

Beyond simply enabling passkeys, understanding how effectively they’re adopted and used across different devices, browsers, and user journeys is crucial. Payment providers need hard data on whether passkeys genuinely reduce friction, cut fraud, and improve conversion. Drawing on the Buy vs. Build Passkey Guide best practices, Corbado offers a rich analytics layer that lets you track, segment, and optimize passkey performance in real time.

Below are the key highlights.

Corbado organizes all passkey events into a funnel: from the moment a user is prompted to create a passkey, through successful registration, to subsequent logins/payments (passkey usage).

This funnel visualization allows you to see where users drop off - e.g., how many never start creation, how many abandon mid-ceremony, or how many revert to fallback methods at login.

Based on our extensive experience helping enterprises implement passkeys, we focus on metrics that directly impact ROI and user satisfaction:

• Passkey Acceptance Rate: How many users who see a creation prompt actually complete passkey registration?

• Passkey Creation Success Rate: Of those who begin the ceremony (click “Create Passkey”), what percentage finalize without error or abandonment?

• Passkey Usage Rate: How often do returning users actually choose passkeys for day-to-day authentication or payment, rather than passwords or OTP?

• Passkey Login Success Rate: The percentage of passkey attempts that succeed without fallback or user frustration.

• Fallback Usage: How many users initiate a passkey flow but revert to older methods? This signals potential UX or technical barriers.

Corbado automatically tags each event with operating system (Windows, macOS, iOS, Android) and browser (Chrome, Safari, Edge, Firefox, etc.).

With this segmentation, you can see if, for example, iOS Safari has a higher passkey abandonment rate, or if Windows Chrome yields better passkey adoption.

This data also helps you fine-tune fallback strategies - especially if Apple’s cross-origin restrictions affect your user base more than anticipated.

We provide dashboard views for each stage of the passkey funnel: creation prompts, successful registrations, user logins, fallback usage.

Real-time charts let product managers spot trends quickly (e.g., if a new OS update breaks passkey flows).

Automated alerts can notify your team if passkey success rates drop significantly - so you can promptly investigate a new browser bug or configuration issue.

Every passkey flow (from creation to login) is logged with timestamped step-by-step events, allowing deep forensic analysis.

You can quickly search by user hash, session ID, or device signature to see exactly where a user struggled or which error code was returned.

This is critical for large-scale rollouts, where you can’t rely on anecdotal support tickets but need precise data to solve user issues.

Corbado’s analytics platform supports A/B testing integrated into the passkey funnel: test different CTA text, creation prompts, fallback messages, or placement of “Create Passkey” buttons in the checkout flow.

Metrics like “Passkey Acceptance Rate” or “Fallback Rate” can be measured side by side for each variant.

This approach ensures continuous improvement, mirroring the success of leading passkey adopters who refine flows over time.

While Corbado’s dashboards provide an out-of-the-box visual interface, you can also export or webhook key data points (e.g., passkey creation success, logins) into your BI or SIEM tools.

This allows payment providers to incorporate passkey KPIs into broader analytics suites - tracking ROI from passkeys alongside other security, marketing, or operational metrics.

Summary

By measuring and visualizing every step of the passkey journey - across OS/browser combinations, creation flows, and login scenarios - Corbado gives you the insights needed to continuously refine your passkey offering. These analytics don’t just confirm that passkeys are enabled; they prove whether users are actually adopting them at scale, identify friction points, and help you drive usage rates to the point where passkeys genuinely replace passwords for secure, frictionless payments.

For payment providers, simply creating one passkey per user is often not enough to deliver a truly seamless authentication experience. In reality, users frequently switch devices - from laptops at work to personal smartphones, tablets, and even shared family computers. Ensuring every device has a valid passkey for the same account is critical for reducing friction and preventing fallback to passwords. Apple Pay achieves this by being able to leverage iCloud Account over all iCloud connected devices.

Below is how Corbado helps maintain multi-device coverage throughout the user lifecycle.

• Primary Passkey Creation Screens: Corbado initially focuses on getting each user to register at least one passkey - the “primary” passkey - wherever they first encounter your payment flow (e.g., at checkout, in a bank’s online portal, or in your account settings).

• Secondary Passkey Creation Screens: After a user has successfully registered their first passkey, subsequent logins on other devices can automatically prompt a short “Add this device” flow. This ensures the user quickly gains frictionless passkey access on all relevant devices without re-entering a password or toggling to fallback methods.

Even if a user has a passkey on one device, they might appear with no local passkey on a second device (due to fresh OS installations, cookie deletions, or simply never having created a passkey on that device).

Corbado’s approach often uses a hybrid step: the user can log in with an existing passkey on their phone or a fallback method, then instantly “heal” the gap by creating a passkey on the current device.

This self repair process helps keep coverage high and eliminates repeated fallback usage in the future.

Through cross-device signals and Corbado’s “Passkey Intelligence,” the system can detect when a user with an existing passkey has switched to an unregistered device.

If your UX strategy aims for maximum coverage, Corbado can automatically prompt: “Would you like to add a passkey on this device so you don’t have to fallback next time?”

Users can skip this if they’re on a one-off device, but typically appreciate the convenience of passkey-based biometric login once it’s explained.

Corbado’s SDK provides distinct screen flows for “first passkey creation” (i.e., the user’s very first time registering a credential) and “secondary device” creation.

The messaging can differ: e.g., “Secure this new device with a passkey” vs. “Set up your first passkey.”

This ensures clarity for end-users, who understand the difference between initial enrollment and expanding coverage to additional devices.

Sometimes passkey creation can fail mid-ceremony or the user’s OS is outdated. In those scenarios, Corbado records the partial attempt and gracefully suggests possible remedies (redirect, manual fallback, or cross-device QR flow).

The user can always retry adding a passkey on that device at the next login attempt, or rely on an existing passkey from another device.

Corbado’s analytics show not only how many users created a passkey initially, but also how many have expanded passkeys to multiple devices.

You can track device coverage rates (e.g., 1 device vs. 2 or more) and see how that correlates with reduced fallback usage or improved payment success.

This helps your team prioritize user education, app prompts, or bank-based enrollment flows to raise multi-device passkey penetration.

Summary: Why Multi-Device Coverage Matters

Without consistent coverage across all user devices, you risk users being forced back to fallback authentication measures whenever they’re on a “non-passkey” device. This breaks the frictionless experience and keeps operational costs high (e.g., SMS fees, support overhead). By offering secondary passkey creation screens, hybrid fallback healing, and environment-driven prompts, Corbado ensures every user can eventually maintain passkeys on all the devices they use - driving higher overall adoption and minimizing those frustrating fallback moments.

One of the biggest misconceptions when building a third-party passkeys SDK is that the hardest part is implementing the WebAuthn calls (e.g., navigator.credentials.create() or navigator.credentials.get()).

In reality, this is the “easy” portion - an API call or two to trigger the basic ceremony. The true complexity and the real determinant of success, lies in ensuring large-scale adoption and building a full ecosystem around those API calls.

Below are the key points - reinforced by the Buy vs. Build Passkey Guide - that highlight why minimal, ceremony-only implementations often fail to deliver real-world results.

• Ceremony Implementation: Creating or authenticating a passkey usually involves just a few lines of JavaScript to call navigator.credentials.create() or navigator.credentials.get().

• Real Complexity: Ensuring the passkey flow works across many browsers, gracefully handles failures, and offers fallback for older systems. You’ll also need robust session management, error logging, analytics, device coverage strategies, and more.

• Unforeseen Pitfalls: Once you move beyond a “tech demo” of passkeys, you discover edge cases like cross-origin blocks, embedded WebView restrictions, and multi-device sync complexities. These are the unknown unknowns that derail naive in-house builds.

• Ceremony vs. Adoption: Even if you have a perfect WebAuthn ceremony, low user adoption (e.g., <5% passkey usage rate) will yield minimal security or UX benefits.

• Holistic Approach: A successful passkey rollout demands everything from compelling user prompts and A/B-tested copywriting to multi-device coverage flows, fallback handling, and continuous analytics - far beyond the basic ceremony calls.

• Insights from the Buy vs. Build Guide: The guide emphasizes that driving passkey adoption - not just enabling passkeys - ultimately determines ROI. If users don’t enroll and actively use passkeys, the project is effectively stalled at “MFA 2.0” without conversion rate improvement.

• Incomplete Fallback & Error Handling: Missing advanced fallback logic or real-time debugging can lead to user lockouts and higher support costs.

• Fragmented Multi-Device Coverage: Without a plan for syncing additional devices or “healing” passkey gaps, users revert to passwords whenever they switch platforms.

• Limited Analytics & A/B Testing: Lacking data on passkey creation funnels or environment usage means you can’t systematically improve adoption or quickly troubleshoot new browser quirks.

• Pre-Built UI & Best Practices: Instead of just exposing ceremony endpoints, a proper solution (like Corbado) bundles white-labeled screens, fallback flows, error handling, and cross-device coverage.

• Adaptive Intelligence & Logging: Auto-detecting likely passkey presence, guiding users to create or fix missing passkeys, and capturing granular event logs.

• Adoption-Focused “Unknown Unknowns”: Many details - like e-mail-based fallback or how to handle corporate devices - aren’t obvious until users start encountering them in real deployments.

• Deeper Dive into Adoption Strategy: The Buy vs. Build Passkey Guide highlights how to balance cost, time-to-market, and the hidden complexities of a robust passkey solution.

• Real-World Benchmarks: Learn how large-scale rollouts from major banks and e-commerce providers overcame the unknown unknowns that arise after you’ve coded the “simple” ceremony logic.

• Sustained Success: Investing in an established platform with proven adoption patterns ensures you aren’t stuck reinventing the wheel - and discovering costly surprises along the way.

In Summary

Merely wiring up the WebAuthn ceremony is not enough to achieve meaningful passkey adoption. True success depends on orchestrating end-to-end flows- like fallbacks, analytics, multi-device expansions and A/B-tested user journeys. By addressing the nuanced complexities beyond “just the ceremony,” you can transform your passkey project from a technical curiosity into a genuinely frictionless, widely used and cost-saving authentication solution.

In addition to the complexities around cross-origin flows, user adoption, and passkey lifecycle management, hosting and deployment considerations are critical for any large-scale passkey solution. Payment providers often deal with strict compliance, data residency demands, and resilience requirements that can vary significantly across regions. Below is how Corbado (or similarly robust solutions) addresses these concerns:

To comply with data sovereignty or regulatory frameworks (e.g. GDPR in Europe, PIPEDA in Canada or NIST/HIPAA in the United States), some providers must keep data within specific geographic boundaries.

A region-agnostic architecture ensures the passkey service can be deployed in any desired AWS region, meeting local compliance mandates without sacrificing performance or scalability.

This flexibility is particularly important if your user base spans multiple countries, each enforcing different data-handling rules.

For critical payment authentication flows, downtime is not an option. Corbado employs multi-AZ deployments, distributing key components across multiple availability zones.

This setup helps ensure that if one AZ experiences an outage or connectivity issue, your passkey infrastructure in other zones remains online - so users can continue to authenticate.

The result is a more resilient system that meets stringent SLAs for financial services and e-commerce sites, where even brief downtime can lead to significant revenue impact.

Some payment providers prefer a private dedicated cluster - whether for tighter data isolation, custom compliance checks, or deeper control over patches and updates.

A flexible solution can support both extremes:

• SaaS / Multi-Tenant: Quick to implement, lower cost, well-suited for many mid-size deployments.

• Dedicated Cloud Instance: A separate account and database instance in your chosen region, for those needing additional isolation or compliance.

Passkeys must handle spiky workloads: huge traffic surges (e.g., holiday shopping peaks or event ticket sales) can overwhelm fixed-capacity systems.

A modern passkey back end scales horizontally in real time, adding or removing compute instances based on usage patterns. This auto-scaling ensures consistent performance without manual intervention.

Industry standards like PCI-DSS, PSD2 SCA, or ISO 27001 often apply to payment providers. A robust passkey provider typically integrates with known compliance frameworks out of the box:

• Encryption at Rest and in Transit: Secure data with strong TLS and server-side or client-side encryption for stored credentials.

• Logging and Audit Trails: Detailed logs for each passkey operation, suitable for regulators or incident investigations.

• Regular Security Patching: Automatic OS and container patching to keep vulnerabilities at bay, especially relevant in a fluid multi-AZ environment.

True resilience extends beyond a single region. Some providers mandate cross-region replication to maintain business continuity during large-scale disasters.

Geo-redundancy can replicate passkey data in a different region or continent, ensuring that an entire region’s downtime does not halt authentication flows.

Summary: Multi-AZ and Region-Independent

Choosing a passkey solution that easily scales, geographically adapts, and resists both local outages and large-scale disasters is essential for modern payment providers - especially those operating in multiple countries or under strict compliance. By supporting multi-AZ deployments and region-agnostic configurations, Corbado (or comparable solutions) ensures payment passkey services remain both available and compliant, no matter where your users or data reside.

Passkeys indeed represent the next generation of secure, user-friendly authentication. Yet, payment providers face unique challenges that the traditional WebAuthn design doesn’t directly address. These limitations are most pronounced in:

1. Safari’s refusal to allow cross-origin passkey creation (particularly in iframes), forcing either a redirect-based approach or reliance on previously created passkeys.

2. Apple’s lack of support for Secure Payment Confirmation (SPC), preventing a frictionless, standardized payment flow across browsers and platforms.

Nevertheless, passkeys remain essential for payment providers looking to offer an Apple Pay–like checkout experience: streamlined, secure, and delightfully simple for end-users. Below is how these challenges can be addressed and how Corbado helps.

1. What are the current limitations of using passkeys within third-party contexts for payment providers?

• Cross-Origin Restrictions: Safari (and some older browsers) block navigator.credentials.create() when embedded via an iframe. This means you can’t seamlessly create new passkeys in a merchant-embedded flow on those browsers.

• Missing SPC Support: Apple’s refusal to adopt SPC limits the ability to standardize cross-origin payment confirmations, forcing providers to maintain separate approaches for Safari vs. Chrome/Edge.

• WebView & Native App Constraints: Embedded WebViews often break passkey flows, requiring system browser sessions or other specialized approaches to manage domain origin alignment.

• Fragmented Device Coverage: Even if the user creates a passkey on one device or browser, they might lack coverage on others, causing fallback usage.

2. How can payment providers overcome these limitations to successfully implement third-party passkey integrations?

• Leverage a Hybrid (Iframe + Redirect) Strategy:

  • Iframe for browsers that fully support cross-origin passkeys, offering a seamless embedded UI.

  • Redirect as a fallback for Safari or incompatible setups, ensuring robust passkey creation is always possible.

• System WebView or Browser Redirect in Native Apps:

  • Rather than embedding iframes in merchant apps, shift to ASWebAuthenticationSession (iOS) or Chrome Custom Tabs (Android) to preserve domain continuity.

  • Adoption-Focused Toolkit: Provide compelling passkey creation prompts, multi-device coverage flows, and fallback “healing” steps to keep usage high.

  • Advanced Analytics & A/B Testing:

    • Continuously measure passkey success/fallback rates, environment coverage, and user feedback to refine your flows.

    • Use passkey intelligence to automatically present passkeys only when success is likely.

Throughout this guide, we’ve highlighted that simply wiring up navigator.credentials.create() is not enough. True success hinges on high passkey adoption, consistent user experience and resilient multi-device coverage. That’s where Corbado excels:

• Unified Support for Iframe & Redirect: Corbado’s SDK automatically detects whether an embedded passkey flow is feasible (e.g., on Chrome or Edge) or if a redirect is necessary (e.g., Safari). This maximizes compatibility without requiring merchants to maintain multiple codepaths.

  • One-Tap Payment Experience: With Passkey Intelligence, Corbado instantly detects if a user’s environment likely has a valid passkey - triggering a frictionless “pay with passkey” flow. This approach parallels Apple Pay’s one-tap checkout, boosting everyday passkey usage rather than relegating it to a rarely used MFA step.

  • Robust Multi-Device Coverage: Corbado provides special flows for initial passkey creation versus secondary passkey expansions, so that each user can quickly add coverage for new devices after logging in via fallback or cross-device QR.

  • Full-Stack Adoption Focus: Through integrated analytics, A/B testing, and error handling, Corbado helps providers identify friction points and systematically optimize passkey acceptance. This extends from banks’ first passkey prompts to merchants’ checkout experiences.

  • Flexible, Compliant Hosting: Corbado’s multi-AZ, region-agnostic deployments align with stringent payment industry compliance (PCI DSS, PSD2 SCA, etc.), ensuring uptime and adherence to data residency rules worldwide.

While Apple’s restrictive policies create unavoidable friction payment providers can still successfully implement third-party passkeys by:

1. Combining embedded appraoch (iframe) with redirect fallback.

2. Adopting specialized system webviews or external browser flows for native apps.

3. Focusing on robust adoption strategies: multi-device coverage, fallback “healing,” advanced analytics, and A/B testing.

Corbado brings all these elements together, offering a enterprise passkey platform that covers passkey enrollment, one-tap usage, analytics-driven optimization, and global-scale hosting. The result: a truly frictionless experience like Apple Pay for your own payment service, delivering both heightened security and a superior user journey. experience.