支付提供商 Passkey：如何构建第三方 SDK

Passkey 正在成为保护和授权在线交易的最有效方法，与传统的多因素认证 (MFA) 相比，它显著提升了安全性和便利性。最近，PayPal 采用 Passkey 作为其主要的独立 MFA 解决方案，为全球支付提供商设定了明确的趋势。

然而，Passkey 最初是为第一方场景设计的，这意味着当用户直接在拥有凭证的网站或应用上进行认证时，其功能表现最佳。相比之下，支付提供商通常在第三方场景中运营，他们的服务（例如支付表单或 SDK）被嵌入到商户的网站和应用中。Passkey 设计与支付提供商运营模式之间的这种根本性不匹配，为实现无缝集成带来了关键限制。为了应对这些挑战，我们必须探讨两个关键问题：

1. 目前在第三方场景中为支付提供商使用 Passkey 存在哪些限制？ 2. 支付提供商如何克服这些限制，成功实施第三方 Passkey 集成？

通过研究这些问题，我们将揭示，行业内正在进行的、旨在使 Passkey 适应第三方场景的努力——特别是通过像安全支付确认 (SPC) 这样的 Web 标准——正受到苹果公司含蓄施加的战略性障碍的阻挠。具体来说，苹果在 Safari 中对跨域Passkey 创建的有限支持，以及安全支付确认标准中缺失的支持，构成了一个重大障碍，使得第三方支付提供商难以无缝采用基于 Passkey 的认证。对于任何旨在提供无摩擦、安全支付体验的提供商来说，理解并克服这些障碍至关重要。

Passkey 为支付体系的每一层都带来了抗网络钓鱼、基于生物识别的登录方式。以下是支付价值链中每个参与者如何从集成 Passkey 认证中获益的分析。

影响： 更快的结账、更高的转化率、更少的购物车放弃率。 机遇： 通过 SDK 或重定向流程提供 Passkey 的商户可以模仿 Apple Pay 级别的用户体验，减少对密码或一次性密码 (OTP) 的依赖，从而带来更高的信任度和销售额。

影响： 跨设备的无缝无密码认证。 机遇： Passkey 提供了比 OTP 或短信验证码更好的用户体验，并消除了网络钓鱼风险。广泛采用可能使 Passkey 成为持卡人验证的新标准。

影响： 更强的欺诈防范能力。 机遇： 发卡行可以在 3DS 流程中提供基于 Passkey 的增强认证，从而降低 OTP 成本并提高用户满意度。

影响： 更高的交易接受率和更少的认证失败。 机遇： 通过支付服务提供商 (PSP) 支持 Passkey 可以改善商户成果，并减少结账或循环计费流程中的摩擦。

影响： 减少欺诈、更好的商户用户体验和改进的合规性。 机遇： 通过嵌入或重定向 Passkey 流程，PSP 可以提供下一代认证，同时保持跨浏览器和原生应用的兼容性。

影响： 简化的交易审批，减少被拒支付的次数。 机遇： 支付处理公司可以将 Passkey 验证集成到其 API 中，以降低风险并支持生物识别 SCA 替代方案，实现合规流程。

影响： 安全的凭证存储和无摩擦的重新认证。 机遇： 像 Apple Pay 和 Google Pay 这样的钱包提供商已经在使用类似 Passkey 的流程。

接下来，我们简要看看主要的支付和信用卡提供商，并分析他们是否以及如何实施了 Passkey：

Mastercard 已正式推出其支付 Passkey 服务，提供嵌入到 EMV 3DS 流程中的无密码认证体验。用户可以创建和使用绑定到 Mastercard 认证域名（例如 verify.mastercard.com）的 Passkey，从而在参与的商户中实现安全的生物识别登录。这一举措代表了支付行业在实现抗网络钓鱼、符合 PSD2 的认证方面迈出的重要一步。 阅读更多：Mastercard Passkey

Visa 推出了其Visa 支付 Passkey 服务，将 Passkey 集成到“Click to Pay”流程中。通过允许用户使用生物识别技术无缝认证，而不是使用密码或 OTP，Visa 旨在通过增强的安全性和用户便利性来现代化在线结账体验。 阅读更多：VISA Passkey

American Express 尚未公开发布 Passkey 产品。然而，作为 FIDO 联盟的董事会级别成员，American Express 很可能会在不久的将来推出基于 Passkey 的认证解决方案，以顺应更广泛的行业趋势。

PayPal 是最早采用 Passkey 的支付提供商之一。他们的推广支持个人和企业账户在各种设备上进行无缝的生物识别登录。Passkey 绑定到 PayPal 的域名，并已在许多地区可用。然而，他们的实现在某些方面还有改进空间，尤其是在多设备流程和平台检测方面。 阅读更多：PayPal Passkey

Klarna 尚未正式引入 Passkey 支持。根据我们的观察，Klarna 在其应用和结账 SDK 中严重依赖嵌入式 WebView。由于 Safari 和 iOS 限制在 iframe / WebView 中创建 Passkey，这可能是 Klarna 至今未推出 Passkey 的原因之一。

Square 已为其开发者仪表板和管理控制台引入了 Passkey 登录，允许安全、无密码地访问内部工具。然而，尚未宣布在支付流程或 API 中为最终用户或商户提供 Passkey 支持。

Stripe 已为其仪表板推出了 Passkey 登录，使开发者能够使用生物识别技术进行认证。Stripe Checkout 或 Elements 的 Passkey 尚不可用。鉴于 Stripe 强烈倡导基于重定向的流程，如果 Passkey 在支付中实施，很可能会遵循同样的重定向架构。

截至目前，BILL 尚未发布任何与 Passkey 认证相关的公开声明或产品更新。

Remitly 尚未披露任何在其服务中实施 Passkey 认证的计划或公开信息。

没有公开报告或产品文档表明 Payoneer 已采用或正在测试基于 Passkey 的登录或交易流程。

Adyen 尚未在其认证或支付流程中引入 Passkey。没有公开声明或开发者文档提及 Passkey 支持。

Worldpay 截至目前尚未宣布任何对 Passkey 的支持。其认证体系仍然依赖于传统方法，如密码、OTP 和基于 3DS 的流程。

Checkout.com 尚未公开发布 Passkey 支持。没有关于采用 Passkey 的开发者更新、博客文章或官方公告。

支付宝 (AliPay) 尚未正式推出 Passkey。鉴于中国支付生态系统中生物识别认证的增长趋势，未来可能会推出，但目前没有文档证实这一点。

Mollie 尚未就其认证或结账系统中采用 Passkey 发表任何公开声明或产品更新。

亚马逊已在其主平台上推出了用于用户登录的 Passkey 支持。将这项技术扩展到 Amazon Pay 将是自然的下一步，特别是因为许多用户已经注册了亚马逊的 Passkey，这将大大简化结账时的用户引导流程。

Braintree 是 PayPal 旗下公司，尚未正式采用 Passkey 认证。其当前文档在用户登录或商户 API 的背景下没有提及 Passkey。

Link 是 Stripe 的一键结账解决方案，已推出的 Passkey 可能成为 Stripe 在消费者支付领域 Passkey 战略的基础。然而，Stripe 尚未正式宣布对 Link 的 Passkey 支持或任何具体的推出计划。

Afterpay 尚未发布任何与 Passkey 支持相关的声明或功能。与 Klarna 类似，其结账集成严重依赖于应用，这可能因嵌入式 WebView 的限制而给采用 Passkey 带来技术障碍。

第三方支付提供商采用 Passkey 面临着战略性障碍，这主要是由苹果在 Safari 中的限制性政策造成的。两个关键的标准化尝试一直受到阻碍：

• 安全支付确认 (SPC)

• 在 iframe 中进行第三方 Passkey 创建

安全支付确认 (SPC) 代表了行业内最重要的努力——主要由谷歌推动，旨在实现专为安全支付授权量身定制的无缝、跨域 Passkey 使用。SPC 规范了支付提供商如何在多个商户网站上认证用户，而不损害安全性或用户体验。然而，苹果一直拒绝在 Safari 中支持 SPC，这很可能是一项战略举措，以确保 Apple Pay 在其生态系统中保持首选、最无摩擦的支付解决方案。苹果拒绝采用 SPC 不仅限制了 Passkey 在第三方场景中的广泛部署，还实际上推迟了行业对标准化支付认证的更广泛采用。

如果您想了解更多关于 SPC 的细节，请阅读这篇关于 SPC 的博客文章。

另一个关键障碍涉及苹果故意限制在跨域 iframe 内创建 Passkey。虽然 Safari 允许在第三方 iframe 中使用现有 Passkey 进行认证 (navigator.credentials.get())，但它明确禁止在这种情况下注册 Passkey (navigator.credentials.create())。

这一限制严重制约了那些依赖于在商户结账流程中无缝创建新 Passkey 的支付提供商。因此，提供商被迫采用基于重定向的方法，或者必须依赖于之前直接在其自己域名上建立的现有 Passkey。苹果的这一决定直接影响了商户集成的实用性和流畅性，为消费者和提供商都制造了一个显著的摩擦点。

在这种方法中，商户将您的支付表单包含在一个从您的支付提供商域名（例如 https://pay.provider.com）提供的 <iframe> 中。用户停留在商户的域名上（例如 https://www.mystore.com），在嵌入的 iframe 中看到您的支付 UI，并使用绑定到信赖方 ID pay.provider.com 的 Passkey 进行认证。

关键点：

• 跨域：由于 iframe 位于不同的域名上，您必须为 publickey-credentials-get 和 publickey-credentials-create 配置权限策略，以允许在 iframe 内进行 Passkey 操作。

• 创建限制：一些浏览器（特别是旧版本和 Safari）仍然不允许在跨域 iframe 中创建 Passkey。认证 (navigator.credentials.get()) 的支持更广泛，但注册 (navigator.credentials.create()) 在某些环境中可能会失败，尤其是在 Safari 中。

• 用户激活：Passkey 流程通常需要“瞬时激活”（例如，用户的直接按钮点击）。确保您的 iframe 界面在用户发起的事件中触发 Passkey 仪式。

• 安全性与用户体验：iframe 方法提供了流畅的内联结账体验，但如果用户的浏览器阻止或限制第三方 cookie 或本地存储，可能会中断 Passkey 流程。

通过基于重定向的流程，您将用户从商户的域名发送到您的支付域名，或者打开一个指向类似 https://pay.provider.com/checkout 的新标签页/窗口。然后，Passkey 直接在您的域名上以第一方上下文创建或使用。

关键点：

• 第一方简易性：整个 Passkey 工作流程（创建、认证）都发生在支付提供商的域名上，因此没有跨域限制。所有主流浏览器都支持在第一方上下文中创建和登录 Passkey。

• 重定向用户体验：用户离开商户页面（或看到一个弹出窗口）来完成认证。这可能不那么无缝，但它简化了 Passkey 架构并减少了跨域复杂性。

• 不兼容浏览器的后备方案：如果 Passkey 不可用（例如，旧版浏览器），您可以通过在您的支付域名上提供替代登录方法来优雅降级，而无需额外的跨域权限处理。

与基于 Web 的场景相比，在原生移动应用中集成 Passkey 带来了独特的挑战。商户的原生应用（在 iOS 和 Android 上）通常使用嵌入式 WebView 在应用程序内嵌入支付流程，以保持无缝的用户体验。然而，由于严格的浏览器源策略和平台特定的限制，在这些嵌入式环境中实施第三方 Passkey 认证可能会出现问题。

Passkey 天生绑定到一个特定的域名（“信赖方 ID”），这是一个核心安全原则，确保凭证不能在不相关的网站或应用之间被滥用。当支付提供商在其自己的域名下（例如 pay.provider.com）创建 Passkey 时，这些 Passkey 在 iOS 和 Android 上都严格限定在该域名范围内。因此，商户的原生应用（自然在其自己的应用标识符和域名下运行）不能直接调用提供商的 Passkey 作为“第一方”凭证。这样做需要跨域共享私钥，而操作系统和 WebAuthn 规范明确禁止这样做，以防止网络钓鱼和凭证盗窃。

从设备的角度来看，商户的原生应用与支付提供商的域名是不同的“源”。尝试针对注册到不同源的凭证进行原生认证会破坏 Passkey 的基本源绑定安全模型。这正是为什么在商户环境中使用第三方 Passkey 依赖于系统浏览器或基于系统的 WebView（如 iOS 上的 ASWebAuthenticationSession 或 Android 上的 Chrome Custom Tabs）。这些特殊流程保留了提供商的原始域名上下文——确保 Passkey 保持安全的源绑定——同时仍然允许用户在商户应用内向支付提供商进行认证。在接下来的部分中，我们将探讨这是如何工作的。

嵌入式 WebView（例如，iOS 上的 WKWebView 或 Android 的 WebView）之所以广受欢迎，是因为它们允许应用将 Web 内容直接嵌入其原生界面，提供紧密的集成和一致的用户体验。然而，在处理第三方 Passkey 时，由于源和安全策略，这些嵌入式环境受到严重限制：

• 源不匹配：Passkey 严格依赖域名源来进行安全的凭证处理。嵌入式 WebView 在其显示内容的域名（通常是商户的域名）下运行，这使得创建或认证明确绑定到第三方支付提供商域名的 Passkey 变得困难或不可能。

• 平台安全限制：苹果 (iOS) 和谷歌 (Android) 都逐步限制了嵌入式 WebView 在认证方面的能力，尤其是在处理安全凭证时。这些限制旨在保护用户隐私和安全，但使得第三方 Passkey 的实施变得更加复杂。

总的来说，虽然从用户体验的角度来看，嵌入式 WebView 对商户很有吸引力，但它们在实施稳健的第三方 Passkey 认证流程方面引入了重大的实际限制。

鉴于与嵌入式 WebView 相关的限制，支付提供商通常采用以下两种替代策略之一，以便在原生移动应用中可靠地实施第三方 Passkey：

iOS (ASWebAuthenticationSession):

苹果提供 ASWebAuthenticationSession 作为一个安全的、类似浏览器的环境，它独立于宿主应用程序的上下文。它与默认的 Safari 浏览器共享 cookie 存储，并可靠地支持第三方 Passkey，因为凭证与支付提供商的源域名一致。

以下示例展示了 BOSS 原生应用中的“使用 PayPal 结账”功能。它显示了如何打开一个 ASWebAuthenticationSession 系统 WebView，该 WebView 与 Safari cookie 共享其状态，从而允许 Passkey 对话框立即启动。

Android (Chrome Custom Tabs):

同样，Android 的 Custom Tabs 提供了一个接近浏览器的环境，允许一致的 Passkey 创建和认证。与 ASWebAuthenticationSession 类似，Custom Tabs 与商户的应用上下文分开运行，确保了域名和凭证的完整性。

请看这里来自 BOSS 原生应用的相同示例在 Android 上的表现：

另一种方法是将用户从原生应用重定向到移动设备的默认网络浏览器（iOS 上的 Safari，Android 上的 Chrome）。这确保了支付流程——以及因此的 Passkey 管理——完全在与支付提供商域名相关的受信任的第一方上下文中进行。用户在成功认证或完成支付后返回到商户应用。这个选项对客户来说非常不方便，因为他们必须离开应用。

这两种解决方案都需要暂时将用户从商户的原生应用环境中转换出去。尽管与嵌入式解决方案相比稍显不那么无缝，但这些方法显著提高了第三方 Passkey 操作的兼容性、安全性和可靠性。

最终，开发原生 SDK 的支付提供商必须在用户体验考虑和实际技术限制之间仔细权衡。尽管商户偏爱完全嵌入的体验，但利用系统 WebView 或外部浏览器重定向仍然是确保在原生应用中实现安全、可靠的第三方 Passkey 认证的最佳实践。

在将第三方 Passkey 集成到支付 SDK 中时，选择嵌入式 (iframe) 方法还是基于重定向的方法，需要评估用户体验、浏览器兼容性、技术复杂性和商户偏好之间的权衡。

两种解决方案各有其独特的优缺点，支付提供商应根据其目标市场、期望的用户体验和技术基础设施仔细考虑。

嵌入式 (iframe) 方法提供了无缝的、商户品牌化的用户体验，对商户极具吸引力，但受到有限的浏览器兼容性的阻碍，特别是 Safari 拒绝允许跨域 Passkey 创建。这一限制迫使商户和提供商采用复杂的、基于变通方案的解决方案，这些方案通常会损害功能或导致对 Passkey 注册的支持不完整。

相反，重定向方法通过在第一方域名上下文中运行，提供了跨浏览器和原生移动平台的全面兼容性。它显著简化了集成，提高了可靠性，并确保了完整的 Passkey 创建和认证支持。主要缺点是重定向用户离开商户网站或应用可能产生的摩擦，尽管这可以通过精心的用户体验设计、清晰传达的期望或与像 Corbado 这样的可信平台集成来缓解。

鉴于这些考虑，混合方法通常是理想的，它允许支付提供商在用户浏览器支持时利用嵌入式 iframe 模型，否则则优雅地回退到重定向方法。这种组合策略在各种环境中最大化了兼容性、商户吸引力和客户满意度。

实施第三方 Passkey 支付 SDK 涉及平衡用户体验、浏览器兼容性、原生应用限制、分析和安全性——尤其是在考虑到苹果特定的障碍（例如，阻止跨域 Passkey 创建、缺少 SPC 支持）的情况下。以下是确保在将 Passkey 集成到 Web 或原生支付流程中时获得最佳结果的关键建议。

由于浏览器支持各不相同以及苹果行为的不一致，同时支持嵌入式（基于 iframe）方法和重定向方法至关重要：

• Iframe 结账（嵌入式）

  • 为允许跨域 Passkey 操作（主要用于认证）的现代浏览器提供无缝的页面内体验。

  • 必须为 publickey-credentials-get/publickey-credentials-create 设置正确的 Permissions-Policy。

  • 请注意，Safari 和一些旧版浏览器在 iframe 中阻止跨域 Passkey 创建。

• 重定向流程

  • 在第一方上下文中可靠地支持 Passkey 注册和登录。

  • 由于额外的重定向或弹出窗口，摩擦稍大，但对于跨浏览器兼容性来说普遍更安全。

  • 对于 Safari 来说是理想的后备方案，因为它目前不允许在 iframe 中创建第三方 Passkey。

通过提供这两种方法，您可以动态决定——或让商户决定——使用哪一种，从而为所有用户环境最大化兼容性。

由于 User-Agent 粒度降低以及各平台对 Client Hints 的支持不一致，准确检测浏览器能力仍然具有挑战性。

随着浏览器为保护用户隐私而减少 User-Agent 字符串中的细节，传统的解析变得越来越不可靠。现在，仅使用 User-Agent 很难或不可能区分关键细节——例如 Windows 10 与 Windows 11、精确的 macOS 版本或 CPU 架构。

虽然 Client Hints 以尊重隐私的方式提供高熵数据，但只有基于 Chromium 的浏览器完全支持它们。Safari 和 Firefox 不提供 Client Hint 支持，这严重限制了在苹果设备上进行精确的特性检测。

嵌入式 WebView 通常限制对详细设备信息的访问，并且很少支持 Client Hints。这一限制使得在原生应用上下文中检测 Passkey 能力尤其具有挑战性。

鉴于这些限制，可靠地检测跨域 Passkey 支持——尤其是在第三方支付 SDK 中——需要仔细结合动态 Client Hint 查询（在可用时）、后备的 User-Agent 启发式方法以及对 Safari 和 Firefox 等浏览器的保守默认行为。

原生商户应用通常将 Web 内容嵌入到 WKWebView (iOS) 或 Android WebView 中，这些对于 Passkey 来说限制性很强。常用策略包括：

• 系统浏览器会话：使用 ASWebAuthenticationSession (iOS) 或 Custom Tabs (Android) 将 Passkey 创建/登录转移到安全的“第一方”浏览器上下文中。

• 重定向到默认浏览器：一种不那么无缝但高度可靠的方法，以确保 Passkey 操作的域名完整性。

作为支付提供商，强大的安全性和法规遵从性（PCI、PSD2 SCA 等）是关键：

• 标头与内容安全：为跨域流程实施严格的 Permissions-Policy 标头和稳健的 CSP 规则。

• 日志与监控：为欺诈预防和合规审计，彻底记录 Passkey 创建和使用事件。

• 最少 PII 存储：使用哈希标识符将用户映射到 Passkey，减少在 GDPR 或类似数据保护法下的暴露风险。

• 审计追踪：记录每个 Passkey 创建和认证事件，以检测异常并满足合规审计要求。

Passkey 仍在不断发展，因此您需要进行持续的检查：

• 跨浏览器和跨操作系统测试：在 Safari、Chrome、Edge、Firefox 和主要移动操作系统版本中自动化测试。

• 频繁更新：跟踪 W3C WebAuthn 规范、FIDO 联盟指南或 SPC 提案的变化。

• 用户反馈与错误率：记录 Passkey 错误（创建或登录），以快速修复问题，特别是针对基于苹果的用户。

一个稳健的 KPI 框架可以帮助您跟踪您的第三方 Passkey 集成是否真正提高了安全性和用户体验。尽管本文是关于实施 SDK 的，但重要的是要记住，Passkey 采用率在这种用例中也是关键。Passkey 的创建率和使用率需要仔细分析和优化。

• 定义：在被提示时（例如在结账或账户设置时）成功创建 Passkey 的用户百分比。

• 重要性：高创建率意味着您的 Passkey 引导/推送流程引人注目且无摩擦。

• 目标：您应该以 50-80% 的比率为目标。

• 定义：在开始创建仪式（点击“创建 Passkey”）的用户中，有多少人最终完成而没有中止或出错？

• 重要性：表明您的跨域或重定向流程工作得如何。

• 目标：理想情况下，一旦用户选择加入，您应该有约 95–100% 的数字。

• 定义：通过 Passkey 完成的总支付授权（或登录）的百分比，而不是通过后备方法。

• 重要性：如果用户默认回到旧方法，创建就毫无意义。

• 目标：50–80% 的比率表明 Passkey 采用率很高。

• 定义：成功且没有错误或后备的 Passkey 登录尝试的百分比。

• 重要性：反映了您的真实世界可用性。

• 目标：通常您应该超过 90–95% 才能认为 Passkey 是“无摩擦的”。

• 定义：用户在 Passkey 仪式中失败并切换到密码或 OTP 的频率有多高？

• 重要性：高后备使用率表明技术或用户体验障碍正在阻止 Passkey 取代传统方法。

• 目标：理想情况下，后备使用率低于 1-5%。

对于支付提供商，衡量 Passkey 是否减少了欺诈、加速了结账或降低了购物车放弃率。将 Passkey 使用数据与支付转化或 3-D Secure 成功指标相结合，以获得全面的视图。

监控这些 KPI 可以帮助您查明哪些环境或用户旅程需要改进——例如，如果 Safari iOS 由于跨域阻止而有更高的放弃率，您可以系统地将这些用户引导到重定向流程。

构建第三方 Passkey SDK 最关键的挑战之一是协调一个顺畅且一致的创建流程——用户实际注册其 Passkey 的地方。无论这发生在银行的门户网站、支付提供商自己的账户设置中，还是直接在商户的结账页面上，核心的 Passkey 注册步骤都非常相似。因此，Passkey 创建的方法不会因为您是将流程嵌入 iframe 还是将用户重定向到第一方页面而发生根本性改变；最重要的是提供清晰、用户友好的界面，管理跨域限制，并跟踪显示用户采用 Passkey 效果的关键指标。以下是最佳实践 Passkey 创建流程的关键方面以及 Corbado 如何支持它们：

无论用户在何处被提示创建 Passkey——无论是在银行的在线银行环境、支付提供商自己的网站/应用，还是商户的结账页面——Corbado 都提供预构建的、可定制的组件，用于用户提示、成功确认和错误处理。

这些组件确保了一致的外观和感觉，同时允许白标品牌化，以便每个银行或商户在需要时可以保留其独特的设计元素。

请看以下以 VicRoads 设计品牌化的 Passkey 创建界面 UI 组件：

Corbado 从所有创建端点收集和统一数据：

• 最初提供 Passkey 的银行网站或应用。

• 支付提供商的个人账户设置（用户可以在其中管理凭证）。

• 可选择允许“即时”创建 Passkey 的商户结账页面。

这种统一的方法使得测量 Passkey 创建率、创建成功率、用户流失点和任何技术错误变得容易——无论哪个渠道发起了 Passkey 注册。

Corbado 提供 A/B 测试功能，以微调屏幕上的说明、按钮文本和提示的时机。措辞上的细微变化（例如，“立即创建 Passkey——不再需要密码！” vs. “使用 Passkey 保护您的下一次支付！”）通常会产生显著的用户接受度差异。

根据 A/B 测试的结果，可以优化以下 KPI：

• 创建率：一旦被提示，成功设置 Passkey 的用户百分比。

• 创建成功率：完成仪式而没有中止或出错的用户份额。

• 后备使用率：用户跳过 Passkey 创建而选择旧登录方法的比率。

• 转化影响：对于商户，衡量在结账时创建 Passkey 是否减少了购物车放弃率。

用户可以在以下上下文中创建 Passkey：

• 银行上下文：在用户登录其银行后触发的创建流程，利用银行环境的信任和熟悉度。

• 支付提供商账户设置：用户直接在支付提供商域名的“我的个人资料”或“安全”设置中设置 Passkey。

• 商户结账：在最终支付步骤提示，特别是如果用户之前没有创建过 Passkey。这可以是嵌入式 (iframe) 或通过重定向。

在每种情况下，底层的 Passkey 仪式都遵循相同的步骤——用户确认、生物识别/PIN 提示和凭证注册。Corbado 的 SDK 确保跨域限制（如果嵌入）或第一方域名上下文（如果重定向）在后台无缝处理。

Corbado 将每个新的 Passkey 附加到适当的用户标识符——无论是“bankPrefix_userId”还是支付提供商系统中的内部用户引用——以便所有后续使用都可以追溯到正确的用户账户。

这些元数据对于高级分析也至关重要：例如，查看 RBC 的 Passkey 创建活动与 TD 的表现如何，或者商户结账和直接“账户设置”流程之间的创建率有何不同。

相同的 Corbado SDK 逻辑可以适应跨域 Passkey 创建是否被允许（在现代 Chrome 或 Edge 中）或必须为 Safari 优雅地切换到重定向。

内置的错误报告有助于识别是否有任何用户子集持续无法创建 Passkey（例如，旧版 iOS、企业 Windows 设备），以便产品团队可以完善说明或后备策略。

我们的团队与企业客户进行了广泛的 Passkey 创建实验，了解了哪些短语、按钮位置和时机能产生最佳的采用率。

我们将这些最佳实践融入到每个创建界面中，同时仍然允许为品牌和合规需求进行完全定制。

总的来说，Passkey 创建是确保高采用率的最重要阶段：即使用户从未注册凭证，最优雅的 Passkey 登录流程也无关紧要。通过在所有可能的渠道——银行、支付提供商域名或商户结账——提供统一、可跟踪的创建界面，并用 KPI 分析和 A/B 测试来检测它们，Corbado 帮助支付提供商推动真正可扩展的 Passkey 采用，模仿像 Apple Pay 这样的原生解决方案的用户体验。

一旦用户创建了 Passkey，下一步是确保他们真正使用该 Passkey 进行快速、无摩擦的支付，就像 Apple Pay 展示的 Apple Pay 支付流程一样。

在 Corbado，我们开发了一种“Passkey 智能”机制，它能自动检测用户的环境何时可能包含有效的 Passkey，从而实现真正的一键式支付体验。以下是实现这一目标的核心要素。

当识别出返回用户时，Corbado 的前端会显示一个专用按钮（例如“使用 Passkey 支付”），而不是强制用户输入后备凭证。

只需轻点此按钮，即可触发 WebAuthn get() 流程（或原生 Passkey 提示），让用户通过生物识别/PIN 立即进行认证——无需额外的步骤或表单输入。

Corbado 的 SDK 收集信号（例如本地存储 cookie、先前成功的 Passkey 使用、环境检测）来预测当前设备+浏览器是否可能拥有该用户的有效 Passkey。

如果 cookie 被删除或不可用，Corbado 会回退到其他启发式方法（例如，用户已知的现有环境、商户提供的用户提示）来决定是否安全地自动启动 Passkey 流程。

如果没有足够的证据表明存在 Passkey，UI 会优雅地提供后备流程或提示用户确认他们拥有 Passkey。

Corbado 不存储个人身份信息 (PII)，如完整的电子邮件或姓名。

取而代之的是，商户可以传递一个哈希或掩码的标识符（例如电子邮件哈希或内部用户 ID）。Corbado 使用它来查找潜在的 Passkey 注册，然后决定是启动 Passkey 认证还是恢复到更通用的方法。如果支付提供商支持，我们可以查找商户提供的信息来查找内部用户 ID。

这确保了用户隐私，同时仍然允许高精度的环境匹配。

在用户的 Passkey 可能存在但无法被检测到的情况下（例如，cookie 被清除、新设备），Corbado 的Passkey 智能会仔细分析自动启动 Passkey 提示是否有意义。

取而代之的是，用户会看到替代的后备流程或“从另一台设备扫描 Passkey”的选项，同时如果用户可以手动确认他们确实有 Passkey，仍然保留一个快速返回 Passkey 使用的路径。

每当 Corbado 选择启动或跳过一键式 Passkey 提示时，该决定都会被记录下来。随着时间的推移，您可以精确地看到哪些浏览器或设备类型产生了最高的 Passkey 覆盖率，而哪些则频繁地恢复到后备方案。

这个分析反馈循环使您能够识别表现不佳的环境（例如，特定的 iOS 或 Android 版本）或 Passkey 使用率仍然较低的用户群体——这样您就可以完善引导或教育策略。

无论用户是来自银行的 Passkey 创建活动还是直接在商户的结账处，一键式逻辑都保持一致。

Corbado 确保如果找到 Passkey（基于域名 cookie、本地存储令牌或Passkey 智能信号），用户会立即被呈现最无摩擦的登录/支付流程。

总结

简而言之，一键式 Passkey 使用是创建 Passkey 的最终回报。通过利用 Passkey 智能——一种环境检测、最少 PII 使用和后备逻辑的结合——Corbado 确保仅在 Passkey 认证真正可能成功时才向用户呈现。这大大减少了失败的尝试，避免了用户挫败感，并培养了习惯性的 Passkey 使用，最终形成了一个可与 Apple Pay 或其他原生支付体验相媲美的一键式支付流程。

除了简单地启用 Passkey，了解它们在不同设备、浏览器和用户旅程中的采用和使用效果至关重要。支付提供商需要确凿的数据来证明 Passkey 是否真正减少了摩擦、降低了欺诈并提高了转化率。借鉴购买 vs. 构建 Passkey 指南的最佳实践，Corbado 提供了一个丰富的分析层，让您可以实时跟踪、细分和优化 Passkey 性能。

以下是关键亮点。

Corbado 将所有 Passkey 事件组织成一个漏斗：从用户被提示创建 Passkey 的那一刻起，到成功注册，再到后续的登录/支付（Passkey 使用）。

这种漏斗可视化让您可以看到用户在哪里流失——例如，有多少人从未开始创建，有多少人在仪式中途放弃，或者有多少人在登录时恢复到后备方法。

基于我们帮助企业实施 Passkey 的广泛经验，我们专注于直接影响投资回报率和用户满意度的指标：

• Passkey 接受率：看到创建提示的用户中有多少人实际完成了 Passkey 注册？

• Passkey 创建成功率：在开始仪式（点击“创建 Passkey”）的人中，有多少百分比最终完成而没有错误或放弃？

• Passkey 使用率：返回用户在日常认证或支付中实际选择 Passkey 的频率，而不是密码或 OTP？

• Passkey 登录成功率：成功且没有后备或用户挫败感的 Passkey 尝试的百分比。

• 后备使用率：有多少用户启动了 Passkey 流程但恢复到旧方法？这表明存在潜在的用户体验或技术障碍。

Corbado 自动为每个事件标记操作系统（Windows、macOS、iOS、Android）和浏览器（Chrome、Safari、Edge、Firefox 等）。

通过这种细分，您可以看到，例如，iOS Safari 是否有更高的 Passkey 放弃率，或者 Windows Chrome 是否产生更好的 Passkey 采用率。

这些数据还帮助您微调后备策略——特别是如果苹果的跨域限制对您的用户群影响比预期的要大。

我们为 Passkey 漏斗的每个阶段提供仪表板视图：创建提示、成功注册、用户登录、后备使用。

实时图表让产品经理能够快速发现趋势（例如，如果一个新的操作系统更新破坏了 Passkey 流程）。

如果 Passkey 成功率显著下降，自动警报可以通知您的团队——这样您就可以迅速调查新的浏览器错误或配置问题。

每个 Passkey 流程（从创建到登录）都记录了带时间戳的逐步事件，允许进行深入的取证分析。

您可以按用户哈希、会话 ID 或设备签名快速搜索，以确切地看到用户在哪里遇到困难或返回了哪个错误代码。

这对于大规模推广至关重要，因为您不能依赖零星的支持工单，而需要精确的数据来解决用户问题。

Corbado 的分析平台支持集成到 Passkey 漏斗中的 A/B 测试：测试不同的 CTA 文本、创建提示、后备消息或在结账流程中放置“创建 Passkey”按钮的位置。

可以并排测量每个变体的“Passkey 接受率”或“后备率”等指标。

这种方法确保了持续改进，模仿了领先的 Passkey 采用者随着时间的推移完善流程的成功经验。

虽然 Corbado 的仪表板提供了一个开箱即用的可视化界面，但您也可以将关键数据点（例如，Passkey 创建成功、登录）导出或通过 webhook 发送到您的 BI 或 SIEM 工具中。

这使得支付提供商能够将 Passkey KPI 整合到更广泛的分析套件中——将 Passkey 的投资回报率与其他安全、营销或运营指标一起跟踪。

总结

通过测量和可视化 Passkey 旅程的每一步——跨操作系统/浏览器组合、创建流程和登录场景——Corbado 为您提供了持续完善 Passkey 产品所需的洞察力。这些分析不仅确认了 Passkey 已启用；它们证明了用户是否真正在大规模采用它们，识别了摩擦点，并帮助您将使用率提高到 Passkey 真正取代密码以实现安全、无摩擦支付的程度。

对于支付提供商来说，仅仅为每个用户创建一个 Passkey 通常不足以提供真正无缝的认证体验。实际上，用户经常切换设备——从工作时的笔记本电脑到个人智能手机、平板电脑，甚至是共享的家庭电脑。确保每个设备都拥有同一账户的有效 Passkey 对于减少摩擦和防止回退到密码至关重要。Apple Pay 通过能够利用 iCloud 账户在所有连接 iCloud 的设备上实现这一点。

以下是 Corbado 如何帮助在整个用户生命周期中保持多设备覆盖率。

• 主要 Passkey 创建界面：Corbado 最初专注于让每个用户至少注册一个 Passkey——“主要” Passkey——无论他们首次在何处遇到您的支付流程（例如，在结账时、在银行的在线门户中，或在您的账户设置中）。

• 次要 Passkey 创建界面：在用户成功注册其第一个 Passkey 后，随后在其他设备上的登录可以自动提示一个简短的“添加此设备”流程。这确保用户在所有相关设备上快速获得无摩擦的 Passkey 访问，而无需重新输入密码或切换到后备方法。

即使用户在一台设备上拥有 Passkey，他们也可能在第二台设备上显示没有本地 Passkey（由于全新的操作系统安装、cookie 删除，或者只是从未在该设备上创建过 Passkey）。

Corbado 的方法通常使用一个混合步骤：用户可以使用手机上的现有 Passkey 或后备方法登录，然后通过在当前设备上创建 Passkey 来立即“修复”这个缺口。

这种自我修复过程有助于保持高覆盖率，并消除未来重复的后备使用。

通过跨设备信号和 Corbado 的“Passkey 智能”，系统可以检测到拥有现有 Passkey 的用户何时切换到了未注册的设备。

如果您的用户体验策略旨在实现最大覆盖率，Corbado 可以自动提示：“您想在这台设备上添加一个 Passkey，这样下次就不用回退了吗？”

如果用户使用的是一次性设备，他们可以跳过此步骤，但一旦解释清楚，他们通常会欣赏基于 Passkey 的生物识别登录的便利性。

Corbado 的 SDK 为“首次 Passkey 创建”（即用户第一次注册凭证）和“次要设备”创建提供了不同的界面流程。

消息传递可以有所不同：例如，“使用 Passkey 保护这台新设备” vs. “设置您的第一个 Passkey”。

这确保了最终用户的清晰度，他们理解初始注册和将覆盖范围扩展到其他设备之间的区别。

有时 Passkey 创建可能会在仪式中途失败，或者用户的操作系统已过时。在这些情况下，Corbado 会记录部分尝试，并优雅地建议可能的补救措施（重定向、手动后备或跨设备 QR 流程）。

用户总可以在下次登录时重试在该设备上添加 Passkey，或者依赖来自另一台设备的现有 Passkey。

Corbado 的分析不仅显示了有多少用户最初创建了 Passkey，还显示了有多少用户已将 Passkey 扩展到多个设备。

您可以跟踪设备覆盖率（例如，1 台设备 vs. 2 台或更多），并查看这与减少的后备使用或提高的支付成功率有何关联。

这有助于您的团队优先考虑用户教育、应用提示或基于银行的注册流程，以提高多设备 Passkey 的渗透率。

总结：为什么多设备覆盖率很重要

如果没有在所有用户设备上实现一致的覆盖，您将面临用户在“非 Passkey”设备上被迫回到后备认证措施的风险。这破坏了无摩擦的体验，并使运营成本居高不下（例如，短信费用、支持开销）。通过提供次要 Passkey 创建界面、混合后备修复和环境驱动的提示，Corbado 确保每个用户最终都能在他们使用的所有设备上维护 Passkey——从而推动更高的整体采用率并最大限度地减少那些令人沮丧的后备时刻。

在构建第三方 Passkey SDK 时，最大的误解之一是认为最难的部分是实现 WebAuthn 调用（例如，navigator.credentials.create() 或 navigator.credentials.get()）。

实际上，这是“简单”的部分——一两个 API 调用来触发基本仪式。真正的复杂性和成功的真正决定因素在于确保大规模采用并围绕这些 API 调用构建一个完整的生态系统。

以下是关键点——由购买 vs. 构建 Passkey 指南所强化——这些点突出了为什么最小化的、仅限仪式的实施方案往往无法带来实际效果。

• 仪式实现：创建或认证一个 Passkey 通常只需要几行 JavaScript 来调用 navigator.credentials.create() 或 navigator.credentials.get()。

• 真正的复杂性：确保 Passkey 流程在多种浏览器中都能工作，优雅地处理失败，并为旧系统提供后备方案。您还需要稳健的会话管理、错误日志记录、分析、设备覆盖策略等等。

• 未预见的陷阱：一旦您超越了 Passkey 的“技术演示”阶段，您就会发现边缘情况，如跨域阻止、嵌入式 WebView 限制和多设备同步复杂性。这些是使天真的内部构建脱轨的未知未知。

• 仪式 vs. 采用：即使您有一个完美的 WebAuthn 仪式，低用户采用率（例如，<5% 的 Passkey 使用率）也将产生最小的安全或用户体验效益。

• 整体方法：一个成功的 Passkey 推广需要从引人注目的用户提示和 A/B 测试的文案，到多设备覆盖流程、后备处理和持续分析的一切——远远超出了基本的仪式调用。

• 来自购买 vs. 构建指南的见解：该指南强调，推动 Passkey 采用——而不仅仅是启用 Passkey——最终决定了投资回报率。如果用户不注册并积极使用 Passkey，该项目实际上就停滞在“MFA 2.0”阶段，而没有转化率的提高。

• 不完整的后备与错误处理：缺少高级后备逻辑或实时调试可能导致用户被锁定和更高的支持成本。

• 碎片化的多设备覆盖：没有同步额外设备或“修复” Passkey 缺口的计划，用户在切换平台时会回到密码。

• 有限的分析与 A/B 测试：缺乏关于 Passkey 创建漏斗或环境使用情况的数据意味着您无法系统地提高采用率或快速排查新的浏览器怪癖。

• 预构建的 UI 与最佳实践：一个合适的解决方案（如 Corbado）不仅仅是暴露仪式端点，而是捆绑了白标界面、后备流程、错误处理和跨设备覆盖。

• 自适应智能与日志记录：自动检测可能的 Passkey 存在，引导用户创建或修复缺失的 Passkey，并捕获细粒度的事件日志。

• 以采用为中心的“未知未知”：许多细节——如基于电子邮件的后备或如何处理企业设备——直到用户在实际部署中开始遇到它们时才变得明显。

• 深入探讨采用策略：购买 vs. 构建 Passkey 指南强调了如何平衡成本、上市时间和稳健 Passkey 解决方案的隐藏复杂性。

• 真实世界基准：了解主要银行和电子商务提供商的大规模推广如何克服在您编写了“简单”的仪式逻辑后出现的未知未知。

• 持续成功：投资于一个具有成熟采用模式的既定平台，确保您不会陷入重新发明轮子的困境——并在此过程中发现代价高昂的意外。

总结

仅仅连接 WebAuthn 仪式不足以实现有意义的 Passkey 采用。真正的成功取决于协调端到端的流程——如后备方案、分析、多设备扩展和 A/B 测试的用户旅程。通过解决“不仅仅是仪式”之外的细微复杂性，您可以将您的 Passkey 项目从一个技术上的好奇心转变为一个真正无摩擦、广泛使用且节省成本的认证解决方案。

除了围绕跨域流程、用户采用和 Passkey 生命周期管理的复杂性之外，托管和部署考虑对于任何大规模 Passkey 解决方案都至关重要。支付提供商通常需要处理严格的合规性、数据驻留要求和弹性要求，这些要求在不同地区之间可能存在显著差异。以下是 Corbado（或类似稳健的解决方案）如何解决这些问题：

为了遵守数据主权或监管框架（例如欧洲的 GDPR、加拿大的 PIPEDA 或美国的 NIST/HIPAA），一些提供商必须将数据保留在特定的地理边界内。

一个区域无关的架构确保 Passkey 服务可以部署在任何期望的 AWS 区域，满足当地的合规要求，而不会牺牲性能或可扩展性。

如果您的用户群跨越多个国家，每个国家都执行不同的数据处理规则，那么这种灵活性尤为重要。

对于关键的支付认证流程，停机是不可接受的。Corbado 采用多可用区部署，将关键组件分布在多个可用区。

这种设置有助于确保如果一个可用区发生中断或连接问题，您在其他可用区的 Passkey 基础设施仍然在线——因此用户可以继续进行认证。

其结果是一个更具弹性的系统，满足金融服务和电子商务网站的严格 SLA，在这些网站中，即使是短暂的停机也可能导致重大的收入影响。

一些支付提供商更喜欢私有的专用集群——无论是为了更严格的数据隔离、自定义合规性检查，还是对补丁和更新的更深层控制。

一个灵活的解决方案可以支持两种极端情况：

• SaaS / 多租户：实施迅速，成本较低，非常适合许多中型部署。

• 专用云实例：在您选择的区域中拥有一个独立的账户和数据库实例，适用于需要额外隔离或合规性的用户。

Passkey 必须处理突发的工作负载：巨大的流量激增（例如，假日购物高峰或活动门票销售）可能会压垮固定容量的系统。

一个现代的 Passkey 后端可以实时水平扩展，根据使用模式添加或删除计算实例。这种自动扩展确保了无需手动干预的一致性能。

像 PCI-DSS、PSD2 SCA 或 ISO 27001 这样的行业标准通常适用于支付提供商。一个稳健的Passkey 提供商通常会开箱即用地与已知的合规框架集成：

• 静态和传输中加密：使用强 TLS 和服务器端或客户端加密来保护存储的凭证数据。

• 日志记录和审计追踪：为每个 Passkey 操作提供详细的日志，适用于监管机构或事件调查。

• 定期安全补丁：自动进行操作系统和容器补丁，以防止漏洞，尤其是在流动的多可用区环境中。

真正的弹性超越了单个区域。一些提供商强制要求跨区域复制，以在发生大规模灾难时保持业务连续性。

地理冗余可以在不同区域或大陆复制 Passkey 数据，确保整个区域的停机不会中断认证流程。

总结：多可用区和区域独立

选择一个易于扩展、地理适应性强、并能抵抗局部中断和大规模灾难的 Passkey 解决方案，对于现代支付提供商至关重要——特别是那些在多个国家运营或受严格合规约束的提供商。通过支持多可用区部署和区域无关的配置，Corbado（或可比的解决方案）确保支付 Passkey 服务在任何地方都能保持可用和合规，无论您的用户或数据位于何处。

Passkey 确实代表了下一代安全、用户友好的认证。然而，支付提供商面临着传统 WebAuthn 设计没有直接解决的独特挑战。这些限制在以下方面最为突出：

1. Safari 拒绝允许跨域 Passkey 创建（尤其是在 iframe 中），迫使采用基于重定向的方法或依赖于先前创建的 Passkey。

2. 苹果缺乏对安全支付确认 (SPC) 的支持，阻碍了跨浏览器和平台的无摩擦、标准化的支付流程。

尽管如此，对于希望提供类似 Apple Pay 结账体验的支付提供商来说，Passkey 仍然至关重要：为最终用户提供精简、安全且极其简单的体验。以下是如何解决这些挑战以及 Corbado 如何提供帮助。

1. 目前在第三方场景中为支付提供商使用 Passkey 存在哪些限制？

• 跨域限制：Safari（和一些旧版浏览器）在通过 iframe 嵌入时会阻止 navigator.credentials.create()。这意味着您无法在这些浏览器上的商户嵌入流程中无缝创建新的 Passkey。

• 缺少 SPC 支持：苹果拒绝采用 SPC 限制了标准化跨域支付确认的能力，迫使提供商为 Safari 与 Chrome/Edge 维护不同的方法。

• WebView 与原生应用限制：嵌入式 WebView 经常会破坏 Passkey 流程，需要系统浏览器会话或其他专门的方法来管理域名源对齐。

• 碎片化的设备覆盖：即使用户在一台设备或浏览器上创建了 Passkey，他们也可能在其他设备上缺乏覆盖，导致后备使用。

2. 支付提供商如何克服这些限制，成功实施第三方 Passkey 集成？

• 利用混合（Iframe + 重定向）策略：

  • 对于完全支持跨域 Passkey 的浏览器使用 Iframe，提供无缝的嵌入式 UI。

  • 对于 Safari 或不兼容的设置，使用重定向作为后备，确保始终可以进行稳健的 Passkey 创建。

• 在原生应用中使用系统 WebView 或浏览器重定向：

  • 与其在商户应用中嵌入 iframe，不如转向 ASWebAuthenticationSession (iOS) 或 Chrome Custom Tabs (Android) 来保持域名连续性。

  • 以采用为中心的工具包：提供引人注目的 Passkey 创建提示、多设备覆盖流程和后备“修复”步骤，以保持高使用率。

  • 高级分析与 A/B 测试：

    • 持续测量 Passkey 成功/后备率、环境覆盖率和用户反馈，以完善您的流程。

    • 使用 Passkey 智能来仅在成功可能性高时自动呈现 Passkey。

在本指南中，我们强调了仅仅连接 navigator.credentials.create() 是不够的。真正的成功取决于高 Passkey 采用率、一致的用户体验和弹性的多设备覆盖。这正是 Corbado 的优势所在：

• 对 Iframe 和重定向的统一支持：Corbado 的 SDK 会自动检测嵌入式 Passkey 流程是否可行（例如，在 Chrome 或 Edge 上），或者是否需要重定向（例如，Safari）。这最大化了兼容性，而无需商户维护多个代码路径。

  • 一键式支付体验：借助 Passkey 智能，Corbado 能即时检测用户的环境是否可能拥有有效的 Passkey——从而触发无摩擦的“使用 Passkey 支付”流程。这种方法与 Apple Pay 的一键式结账相似，提升了日常 Passkey 的使用率，而不是将其降级为一个很少使用的 MFA 步骤。

  • 稳健的多设备覆盖：Corbado 为初始 Passkey 创建与次要 Passkey 扩展提供了专门的流程，以便每个用户在通过后备或跨设备 QR 登录后可以快速为新设备添加覆盖。

  • 全栈以采用为中心：通过集成的分析、A/B 测试和错误处理，Corbado 帮助提供商识别摩擦点并系统地优化 Passkey 接受度。这从银行的首次 Passkey 提示延伸到商户的结账体验。

  • 灵活、合规的托管：Corbado 的多可用区、区域无关的部署符合严格的支付行业合规性（PCI DSS、PSD2 SCA 等），确保了全球范围内的正常运行时间和对数据驻留规则的遵守。

虽然苹果的限制性政策造成了不可避免的摩擦，但支付提供商仍然可以通过以下方式成功实施第三方 Passkey：

1. 将嵌入式方法 (iframe) 与重定向后备相结合。

2. 为原生应用采用专门的系统 WebView 或外部浏览器流程。

3. 专注于稳健的采用策略：多设备覆盖、后备“修复”、高级分析和 A/B 测试。

Corbado 将所有这些元素结合在一起，提供了一个企业级 Passkey 平台，涵盖了Passkey 注册、一键式使用、分析驱动的优化和全球规模的托管。其结果是：为您自己的支付服务提供真正无摩擦的体验，就像 Apple Pay 一样，既提高了安全性，又提供了卓越的用户旅程体验。