Payment Provider Passkeys: How to Build a 3rd Party SDK

1. Introduction: Why do Payment Providers need Passkeys?#

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.

2. Passkey Benefits across the Payment Ecosystem#

Passkeys bring phishing-resistant, biometric-based login to every layer of the payment stack. The following diagram illustrates how each player in the payment value chain benefits from passkey authentication.

2.1 Passkeys for Merchants#

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.

2.2 Passkeys for Cardholders / Customers#

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.

2.3 Passkeys for Issuers (Issuing Bank)#

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

2.4 Passkeys for Acquirers (Acquiring Bank)#

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.

2.5 Passkeys for Payment Service Providers (PSP) / Payment Gateways#

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.

2.6 Passkeys for Payment Processors#

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.

2.7 Passkeys for Tokenization & Wallet Providers#

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

3. Which Payment Providers have rolled out Passkeys?#

Please see our dedicated overview of payment providers that have deployed passkeys.

4. Why Are Industry Efforts to Standardize Passkeys Blocked by Apple?#

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

4.1 Where Does Apple Block Secure Payment Confirmation (SPC)?#

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.

4.2 How Safari’s Iframe Restrictions Affect Third-Party Passkey Creation#

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.

5. How to Build a Third-Party Passkeys Payment SDK for Web#

5.1 Strategy A: Embedding a Cross-Origin iframe (Pros & Cons)#

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.

5.2 Strategy B: Redirect-Based Approach for Broader Compatibility#

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.

6. Third-Party Passkeys Payment SDK for Native Apps#

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.

6.1 Why Passkey Provider Passkeys cannot be used directly in Merchant Native Apps#

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.

6.2 Challenges with Embedded WebViews: Why They Break Passkeys#

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.

6.3 Using System WebView or Redirect for Third-Party Passkeys#

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:

6.3.1 Use System WebView#

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:

6.3.2 Redirect to Default Browser#

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.

7. Iframe vs. Redirect: Which Approach for Passkey Checkout?#

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.

7.1 Detailed Comparison Table of Embedded & Redirect Approaches#

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

7.2 Summary: Choosing the Best Flow for Your Payment SDK#

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.

8. Best Practices & Recommendations for Cross-Origin Passkey SDKs#

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.

8.1 How to Set Up an SDK Approach for Passkey 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.

8.2 Detecting Browser Capabilities (Safari vs. Chrome vs. Edge vs. Firefox)#

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

8.2.1 User-Agent Parsing Complexity#

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.

8.2.2 Inconsistent Client Hints Support#

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.

8.2.3 Embedded and Native App Constraints:#

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.

8.3 Handling Native Apps Carefully: Embedded WebView vs. System WebView#

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.

8.4 Ensuring Security & Compliance (PCI)#

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.

8.5 Continuous Testing & Monitoring of Passkey#

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.

8.6 Essential Passkey KPIs: How to Track Creation & Login#

A robust KPI framework helps you track whether your third-party passkey integration truly improves security and user experience. The dashboard below summarizes the six key metrics every payment provider should monitor, along with target ranges for healthy adoption.

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.

8.6.1 Passkey Acceptance Rate#

• 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%

8.6.2 Passkey Creation Success Rate#

• 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.

8.6.3 Passkey Usage Rate#

• 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.

8.6.4 Passkey Login Success Rate#

• 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.”

8.6.5 Fallback Usage#

• 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%

8.6.6 Conversion & Fraud Metrics#

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.

9. How Corbado can help#

The three environments this article keeps separating, the bank portal, the payment provider's own account area and the merchant checkout, are one problem for the user and three integrations for you. Corbado Connect runs the passkey ceremony across all three on top of the identity stack you already have, and Corbado Observe, the authentication observability layer, reports how each of them actually performs.

9.1 Passkey creation across bank, platform and merchant environments#

One of the most critical challenges in building a third-party passkeys SDK is orchestrating a smooth and consistent creation flow, the point 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:

9.1.1 Uniform Creation Screens & UI Components#

Regardless of where a user is prompted to create a passkey, whether that is a bank’s online banking environment, the payment provider’s own website/app or a merchant’s checkout, Corbado Connect ships those screens as components rather than as a specification you rebuild three times: the append prompt, the success confirmation and separate soft and hard error screens for the ceremonies that fail.

Branding those screens runs through CSS. The mounted markup sits inside a cb-connect container with a cb-connect-custom-style layer under it, and each bank or merchant restyles the flow by writing rules against those classes while the ceremony underneath stays identical. CorbadoConnectProvider declares theme and customTranslations props that are never forwarded anywhere today, so plan the stylesheet as the whole customization surface.

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

9.1.2 Centralized Tracking & Analytics#

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.

9.1.3 KPIs & A/B Testing#

Corbado Observe evaluates split tests on the creation screen. You tag the variant on the events you already send (the tracking layer reserves the experiment_ key prefix for exactly this), then define the run and read the arms side by side under Experiments in the Observe panel. 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.

9.1.4 Flexible Creation Context: Bank, Payment Provider or Merchant#

Users can create passkeys in the following contexts:

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

• 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 absorbs the cross-origin constraints (if embedded) or the first-party domain context (if redirected) in the background.

9.1.5 Consistent Metadata & Identifier Linking#

Corbado attaches each new passkey to the identifier your own system already uses for that person. Connect passes it through the login and append calls, and Observe stores it as a user reference on the flow, so every later ceremony resolves back to the same account.

That linkage is what lets the analytics answer real questions: how one issuing bank’s passkey creation campaign performs against another’s, or how creation rates differ between merchant checkouts and direct “account settings” flows.

9.1.6 Adaptive UI & Error Handling#

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.

Every abort and every error code is recorded as its own event, so you can tell whether a subset of users consistently fails passkey creation (e.g., older iOS versions, corporate Windows devices) and the product team can refine instructions or fallback strategies.

9.1.7 Corbado’s Deep Experience in Passkey Creation Flows#

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 scalable passkey adoption, mirroring the user experience of native solutions like Apple Pay.

9.2 Maximize Passkey Usage for an Apple Pay-Like Checkout#

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.

9.2.1 OneTap Flow: No Re-Enter of Credentials#

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.

See how Corbado Connect ships this →

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

9.2.2 Passkey Intelligence: Environment Detection & Scoring#

Corbado’s SDK keeps two things in the browser: an opaque handle for this client environment and a record of the last login on this device, including which identifier type was used and which passkey ceremony ran. Together they answer the question a checkout actually has to answer, which is whether a passkey is likely to work here.

That matters more for a payment SDK than for an ordinary login. When the flow leaves the merchant page for a first-party redirect, the state travels with it: the SDK encodes the handle and the last-login record into the URL and reads them back on the other side, so the redirect target knows what the merchant page knew.

The rules that turn those signals into a decision are configurable in the Connect panel under Decision Rules. If the evidence is thin, the UI offers the fallback flows instead of starting a ceremony that would fail.

9.2.3 No PII Storage, yet Context-Aware#

The detection above runs on an opaque environment handle and a timestamped last-login record. Corbado needs neither full emails nor names to decide whether the one-tap button should appear.

You control what identifier reaches Corbado. A merchant can pass a hashed or masked value (e.g. an email hash or an internal user ID) and Connect 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 resolve the value the merchant sent to the internal user ID.

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

9.2.4 Fallback Logic & Automatic Recovery#

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 weighs whether auto-starting a passkey prompt makes sense.

Where it does not, the user sees the alternative fallback flows or the hybrid “use a passkey from another device” screen, which preserves a quick path back to passkey usage for anyone who does have one.

9.2.5 Advanced Tracking & Coverage Insights#

Every time Corbado initiates or skips a one-tap passkey prompt, the decision is written as an event, including the moment a user switches away from one-tap and the cases where an append was deliberately suppressed. 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.

9.2.6 Unified One-Tap Experience Across Use Cases#

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

One-tap passkey usage is the payoff for creating passkeys in the first place. Passkey Intelligence combines environment detection, minimal identifier usage and fallback logic so that users are offered 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.

9.3 Rich Analytics for Passkey Creation & Login KPIs#

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. Corbado Observe is the authentication observability layer that lets you track, segment and optimize passkey performance, and the Buy vs. Build Passkey Guide sets out which of those numbers are worth watching.

Below are the key highlights.

9.3.1 Unified Passkey Funnel: Creation → Usage#

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). Observe keeps the two halves as separate diagrams over the same event stream, one for login and one for enrollment.

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

9.3.2 Core KPIs from the Buy vs. Build Passkey Guide#

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.

9.3.3 Granular OS & Browser Segmentation#

Corbado automatically tags each event with operating system (Windows, macOS, iOS, Android) and browser (Chrome, Safari, Edge, Firefox, etc.), and the Technology page in Observe splits login flows by OS, OS version and browser. Two things to know before you read it: the page covers web sessions, so an in-app checkout is counted elsewhere, and outcome is not among its dimensions, so it sizes each combination rather than ranking them by failure.

The outcome comparison sits on Device Health, which ranks completion and abort per device, OS and OS version. That is where "iOS Safari abandons more often than Windows Chrome" becomes a sortable row.

It is also how you size the problem this article opens with. If Apple’s cross-origin restrictions affect more of your user base than anticipated, the Safari column is where it surfaces first.

9.3.4 Dynamic Reporting & Scheduled Digests#

Executive Reporting pulls the stages of the passkey funnel onto one board: creation prompts, successful registrations, user logins and fallback usage.

Page subscriptions then deliver that board to a recipient on a schedule, carrying the filters and the time window you selected, so the weekly number reaches the product team without anyone opening the panel.

When a number moves, two things help you explain it. Annotations keep dated notes on the project (a release, a copy change, an OS rollout) behind a badge next to the date picker, so the day the chart bends has a written reason attached to it rather than a marker drawn over it. And clicking a metric in Markets or Touchpoints opens it in the Investigator, which pivots that single number by country or touchpoint. The breakdown underneath groups by browser and OS by default and switches to touchpoint, country or the last step users reached, each row carrying the gap against how that same key performs in every other pivot, until the segment responsible is visible.

9.3.5 Debugging & Process Logs#

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

User Search accepts Corbado user IDs, flow IDs, your own external IDs or a security key serial number, and returns the identifiers, passkeys and environments on that account alongside the event trail, so you can see exactly where a user struggled and 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.

9.3.6 Funnel Optimization with A/B Testing#

Experiments sit on the same event stream as the funnel: tag the variant on your events, define the run in the Observe panel and compare the arms. Test different CTA text, creation prompts, fallback messages or the 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, and the funnel itself carries the same variant split.

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

9.3.7 Flexible Data Access & Integration#

While Corbado’s dashboards provide an out-of-the-box visual interface, the numbers do not have to stay there. Tables and charts export to CSV straight from the panel as an ordinary browser download with no key involved. For a scheduled pull into your own systems there are daily Parquet table exports, listed and fetched over short-lived signed links that an API key reaches with the observe:tableExports:read permission, while observe:dataExports:read covers the separate per-user subject export.

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 go past confirming that passkeys are enabled: they show 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.

9.4 Multi-Device Sync & “Intelligence” for High Adoption#

For payment providers, simply creating one passkey per user is often not enough to deliver a frictionless authentication experience. In reality, users frequently switch devices: laptops at work, 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 gets this for free, because an iCloud account already spans every iCloud-connected device.

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

9.4.1 First Passkey Creation vs. Additional Devices#

• 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.

9.4.2 Hybrid Auth for Device “Healing”#

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.

9.4.3 Detecting & Guiding Users to Add Missing Devices#

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.

9.4.4 Adaptive UI Flows#

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.

9.4.5 Handling Mismatches & Errors#

Sometimes passkey creation fails mid-ceremony, sometimes the platform reports that a credential for this account already exists and sometimes the user’s OS is outdated. Each of those cases has its own screen, and Corbado records the partial attempt with the error code the browser returned.

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.

9.4.6 Ongoing Coverage Metrics#

Coverage shows up in three places in the panel. Passkey Insights groups the credentials you have collected by whether they sync across a user’s devices or stay bound to one, which is the difference between an account that is covered everywhere and an account that is covered once. Device Health splits activity into web and app. User Search lists the passkeys and environments on a single account when you need the individual case.

Read together they show where the gaps sit, which 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, which drives higher overall adoption and removes those frustrating fallback moments.

9.5 Accelerated Time to Market: Why Holistic Solutions Matter#

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.

9.5.1 Unknown Unknowns & Beyond the Ceremony#

• 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 dependable 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.

9.5.2 Adoption Is the True Goal#

• Ceremony vs. Adoption: Even if you have a perfect WebAuthn ceremony, a passkey usage rate that stays in the low single digits 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, all of it well beyond the basic ceremony calls.

• Insights from the Buy vs. Build Guide: The guide emphasizes that ROI follows adoption rather than availability. If users don’t enroll and actively use passkeys, the project is effectively stalled at “MFA 2.0” without conversion rate improvement.

9.5.3 Risks of a “Do It Yourself” Minimal Implementation#

• 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.

9.5.4 Holistic Solutions: More Than Just an API#

• 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, e-mail-based fallback or how to handle corporate devices among them, aren’t obvious until users start encountering them in real deployments.

9.5.5 Recommendation to Read the Buy vs. Build Guide#

• 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 dependable 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: 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.

9.6 Flexible Hosting & Deployment (Multi-AZ, Region-Agnostic)#

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 addresses these concerns:

9.6.1 Region-Agnostic Cloud Deployments#

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.

Corbado’s infrastructure is defined as Terraform modules that are instantiated per environment, with the AWS region as a per-environment setting. Shared production runs in eu-central-1, and the same modules stand up separate environments elsewhere, including ap-southeast-2 for an Australian deployment.

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

9.6.2 Multi-AZ (Availability Zone) High Availability#

For critical payment authentication flows, downtime is not an option. The services run as container tasks spread across the private subnets of the region, which places them in more than one availability zone, and shared storage is mounted per zone.

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.

9.6.3 Stand-Alone or Hybrid Managed Hosting#

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

Both extremes run in production today:

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

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

9.6.4 Scalable & Elastic Infrastructure#

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

The API services carry a target-tracking autoscaler with a configured minimum and maximum capacity, so the running task count follows the load without manual intervention.

9.6.5 Security & Compliance Tooling#

Industry standards like PCI-DSS, PSD2 SCA or ISO 27001 often apply to payment providers. What a passkey provider brings to those conversations:

• Certifications and data location: ISO 27001 and SOC 2 Type II, with EU data centers for the shared production environment.

• A full event history per flow: every ceremony step is stored as a timestamped event and stays queryable per user, which is what an incident investigation or a regulator’s question actually needs.

• Deletion on demand: project-level data deletion and reset jobs remove collected telemetry when a retention rule or a subject request calls for it.

9.6.6 Disaster Recovery & Geo-Redundancy#

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

Corbado’s shared production environment has a disaster recovery counterpart defined in a second region, eu-west-1 against eu-central-1 for production, so 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 keeps payment passkey services both available and compliant, no matter where your users or data reside.

10. Conclusion: Overcoming Apple’s Barriers & Embracing Passkeys#

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.

10.1 Key Questions Answered: Cross-Origin & SPC Limitations#

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.

10.2 How Corbado Bridges the Gap for Payment Providers#

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.

10.3 Final Takeaway: Building a Frictionless and Scalable Passkey Experience#

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.

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (+80% passkey activation). Talk to a Passkey Expert →