数字凭证与支付：Apple 与 Google 钱包策略对比

数字支付领域总是在不断变化。我们希望支付能更快、更安全、更易用。与此同时，像可验证凭证（VCs）和移动身份文件（mdocs）这样的数字身份工具也在不断进步。它们为人们证明身份提供了新方法。因此，一个重要的问题是：这些新的数字身份工具能否也让数字支付变得更好或更简单？

本文探讨了数字凭证（包括 ISO mdocs 和使用 OpenID4VC 发送的 VCs）如何与支付世界相连接。我们将涵盖以下内容：

• 当前的手机钱包（Apple Wallet、Google Wallet）如何处理身份信息与支付卡。
• 为什么当前的数字身份标准，如 ISO 18013-5/7 mdocs，实际上不适合作为直接的支付工具。
• 像 OpenID4VC 这样的协议在未来的支付方法中可能扮演什么角色。
• 其他（第三方）钱包应用可能如何处理支付功能。
• 在支付系统中使用可验证凭证时面临的主要问题和未来可能的发展。

本文是我们另一篇关于数字凭证与 Passkeys 讨论的补充，专门聚焦于支付领域。

要了解数字凭证如何用于支付，我们首先需要理解当今主流移动平台及其内置钱包（Apple Wallet、Google Wallet）是如何将身份信息与支付处理分离开的。

原生平台钱包已成为用户复杂的中枢，但它们通常在身份凭证和支付工具之间保持着明确的区分：

• 身份凭证（例如 mDLs）：
  • Apple Wallet： 主要支持符合 ISO/IEC 18013-5 标准的移动驾照（mDLs）和州身份证。截至 WWDC25，Apple 已确认 Safari 26（在 iOS 26 中）将支持 W3C 数字凭证 API 进行在线出示，且专门支持 org.iso.mdoc 协议。这用于验证身份属性（如姓名、年龄、地址），而非用于支付。
  • Google Wallet 和 Android Credential Manager： Google Wallet 也支持基于 ISO 18013-5 的 mDLs。底层的 Android Credential Manager 提供了一个更灵活的框架。虽然其对数字凭证 API 的实现与协议无关，但 Android 提供了一个使用 OpenID4VP 作为传输机制的默认实现。
• 支付工具（例如信用卡/借记卡）：
  • Apple Pay（在 Apple Wallet 内）和 Google Pay（在 Google Wallet 内）都利用了成熟且受到严格监管的支付技术。这些技术主要基于 EMV（Europay、Mastercard、Visa）标准，涉及代币化（使用设备 PANs 或 DPANs 替代实际卡号进行交易）、用于存储支付令牌的安全元件或硬件支持的安全机制，以及用于交易安全的动态密码。
  • 这些支付系统直接与现有的支付网络（Visa、Mastercard、Amex 等）和收单银行进行交互。

核心要点： 原生平台钱包目前使用不同的“堆栈”或技术来处理身份凭证和支付卡。出示 mdoc 是为了证明身份属性；出示代币化的卡是为了进行支付。在这些原生生态系统中，mdoc 并不能直接用作支付工具。

ISO/IEC 18013-5 标准定义了 mDLs 和其他移动身份证件（mdocs）的数据结构。虽然它非常适合身份验证，但其设计不适合直接用作支付工具：

即使理论上可以在 mdoc 中添加自定义数据字段来存储 PAN 或支付令牌（因为 ISO 18013-5 允许自定义命名空间），mdoc 标准本身并未定义：

• 如何生成或处理动态支付密码。
• 如何与支付网络进行在线授权。
• 支付交易所需的特定安全机制（超出身份数据完整性的范畴）。

因此，目前无法将 ISO 18013-5 mdoc 用作直接的支付工具。

虽然 mdoc 不是支付工具，但它可以在“升级认证”流程中发挥作用，即在高风险操作中需要明确验证用户身份。这与用它来执行支付本身是不同的。流程通常如下：

1. 主要认证： 用户登录服务，通常使用像 passkey 这样的低摩擦方法。
2. 触发升级： 对于高保障操作（例如大额银行转账、更新个人信息），服务要求进行明确的身份检查。
3. mdoc 出示： 服务请求用户出示其 mdoc（例如驾照）。用户从其钱包中出示所需的属性。
4. 验证： 服务通过可信来源或先前注册的身份对 mdoc 数据进行加密验证。

在这种模型中，mdoc 为特定的高风险时刻提供了强大且抗钓鱼的身份证明。然而，随后的金融交易仍然使用既有的支付渠道。mdoc 验证的是_人_，而不是_支付方式_。

虽然 mdocs 本身不是支付工具，但像 OpenID for Verifiable Credentials (OpenID4VC) 这样的协议——包括用于出示的 OpenID4VP 和用于签发的 OpenID4VCI——提供了一个更灵活的传输层。

OpenID4VC 的主要特点：

• 协议，而非载荷： OID4VC 定义了如何请求和出示 VC，但对 VC 载荷本身的格式基本不作限制。它可以传输 mdocs、W3C 标准的 VCs（例如 JWT 或 SD-JWT 格式）或其他自定义凭证类型。
• 广泛的用例： 这种灵活性使得像 Android（通过其 Credential Manager）这样的平台能够通过一个通用机制支持对各种类型凭证的请求。
• 未来支付 VC 的兼容性： 如果支付行业能够标准化一种可验证的“支付令牌”或“支付授权”凭证格式，理论上 OID4VC 可以将这种凭证在用户的钱包和商户/PSP 之间传输。

然而，OID4VC 本身不是一个支付解决方案：

• OID4VC 的作用是促进凭证的交换。它不定义支付凭证的内容、安全特性，或其如何与支付处理系统交互。
• 要使 OID4VC 对支付有用，首先需要开发一种被支付生态系统（发行方、收单方、网络）广泛采用、安全且标准化的_可验证支付凭证格式_。目前这还不存在。

除了原生平台钱包，一个由第三方钱包（如 EUDI Wallet、银行提供的钱包、专业行业钱包）组成的生态系统正在兴起。这些钱包必须在快速、低摩擦的认证和高保障的属性验证之间找到平衡，尤其是在支付场景中。

新兴的共识是，Passkeys 是支付服务核心_认证_的理想选择，因为它们能抵抗钓鱼攻击，并为无缝用户体验而设计。在关键的支付确认步骤中插入数字凭证出示会增加显著的摩擦，并可能损害转化率。因此，数字凭证的主要作用在于一次性的、高保障的开户和 KYC 阶段，以启用支付功能，而不是在交易本身。这些钱包可能如何处理支付，特别是与数字身份功能结合时？

要让第三方钱包授权一笔支付，需要一种方法让商户的应用或网站能够调用它。有几种成熟的交互模型，每种模型的平台集成度和用户体验都不同：

• 应用到应用深度链接： 这是一种通用方法，商户的应用（原生或 Web）使用自定义 URL 方案（例如 eudi-wallet://...）将用户重定向到第三方钱包应用。交易详情作为 URL 参数传递。用户在钱包应用中确认支付后，应用会通过另一个深度链接重定向回商户应用。这在 iOS 和 Android 上都有效，但涉及应用之间的可见上下文切换。
• 原生钱包选择器： 通过原生钱包选择器，应用程序可以调用一个通用的系统服务，该服务会显示所有已注册的支付处理程序或钱包。然后，用户可以从系统提供的 UI 中选择他们偏好的钱包。这比简单的深度链接（数字凭证 API）提供了更集成的感觉。
• 简单的基于二维码的支付： 这种模型非常适合桌面到移动端的流程。商户的网站显示一个包含交易详情或 URL 的二维码。用户用他们的移动钱包应用扫描此代码，然后在手机上独立处理确认。之后，钱包的后端将批准信息传回商户的系统。
• 标准化的跨设备流程（FIDO CTAP）： 这是二维码方法的演进，使用像 FIDO 的客户端到认证器协议（CTAP）这样的协议，在桌面浏览器（客户端）和移动钱包（作为认证器）之间创建一个直接、安全、加密的通道。这比简单的二维码更安全，因为浏览器和手机直接通信，这种模型得到了 Google 在 Passkeys 和数字凭证方面的大力支持。
• 直接后端集成： 在一些闭环系统中，第三方钱包应用可能直接与支付服务提供商（PSP）或金融机构的后端交互来处理支付，通常使用专有 API。

这些模型为启动支付确认提供了“传输层”，在此之内可以进行加密流程（如为 EUDI Wallet 详细描述的流程）。

随着 WWDC25 的发布，浏览器如何处理数字凭证的前景变得更加清晰，进一步巩固了身份验证和支付处理之间的分离。平台正在通过 W3C 数字凭证 API 使第三方钱包能够与浏览器进行_身份验证_交互，但方法有所不同：

• Apple 的立场（在 WWDC25 上确认）： Apple 正式宣布在 Safari 26（随 iOS 26 发布）中支持数字凭证 API。正如他们在“在 Web 上验证身份文件”会议中详细介绍的，该实现仅支持 org.iso.mdoc 协议。这允许网站从 Apple Wallet 或其他注册的第三方文件提供商应用中请求可验证信息，但不支持更通用的 OpenID4VP 协议。随着对数字凭证的支持日益增加和 Web 集成的增强，保持系统性能和安全变得更加关键——像 CleanMyMac 这样的工具有助于确保您的 Mac 在这些技术发展的同时平稳运行。
• Google 的立场： Android 的 Credential Manager 允许第三方钱包注册为凭证请求的处理程序。其在 Chrome 中对数字凭证 API 的实现侧重于使用 OpenID4VP 作为主要传输协议。虽然 OpenID4VP 可以将 mdoc 作为载荷携带，但协议本身与 Apple 的直接 org.iso.mdoc 方法不同。

关键在于，这些浏览器集成是用于身份属性的，而不是将出示的 mDoc 或 VC 视为支付工具。

如果用户通过浏览器的数字凭证 API 从他们的钱包向网站出示 mDL，该网站可能会在结账时使用这些信息进行地址预填或年龄验证。然而，实际的支付步骤仍然需要与支付方式（例如 Apple Pay、Google Pay 或输入卡片详细信息）进行单独的交互。浏览器 API 本身并非设计用于使用身份凭证来发起或处理金融交易。

欧盟数字身份（EUDI）钱包是一个极好的案例研究，展示了第三方钱包必须如何应对操作系统和 API 可用性的复杂现实世界。在其众多功能中，身份验证和支付确认是两个最突出的用例，而完成这两项任务的技术路径是不同的，尤其是在比较 Android 的灵活框架和 Apple 更严格的实现时。

下表分解了如何调用 EUDI 钱包进行身份验证或支付授权，并突出了不同平台的支持差异。

比较的关键要点：

• 数字凭证 API： 这个新兴的 W3C 标准与协议无关，并且在两个平台上都得到了很好的身份验证支持。在其实现中，Android 提供了一个使用灵活的 OpenID4VP 协议的默认流程，该协议可以携带各种凭证格式。相比之下，Apple 的实现严格用于 org.iso.mdoc 格式。关键是，浏览器将此 API 的范围限定在身份用例，而不是用于发起支付。
• 原生钱包选择器： 两个操作系统都提供了一个原生 UI 来选择钱包，但有不同的限制。Android 为身份和支付应用都提供了选择器。iOS 为注册的身份“文件提供商”应用提供了选择器，但没有为第三方支付应用提供。
• 应用到应用深度链接： 这是通用的主力军，在两个平台上对身份和支付用例都可靠地工作。它仍然是在 iOS 上调用第三方钱包进行支付的主要方法。
• 标准化跨设备： 这种基于 FIDO CTAP 的流程目前是 Google/Android 生态系统的一个特性，在 iOS 上不受支持。

(*) 关于通过 DC API 进行支付的说明： 虽然 Android 使用 OpenID4VP 使得通过数字凭证 API 进行支付流程在_技术上_是可行的，但这并非其主要设计重点。通过这个特定的 API 实现无缝支付集成，而不是其他原生方法，仍有待观察，并且需要浏览器供应商的明确支持。

这个比较清楚地表明，虽然身份验证正越来越多地通过数字凭证 API 进行标准化，但像 EUDI 钱包这样的第三方钱包的支付授权仍然严重依赖于更传统的原生集成模式，如应用到应用深度链接，尤其是在 iOS 上。

无论使用哪种支付集成模型来调用钱包，EUDI 钱包支付确认的核心都依赖于 EWC RFC008 中详细说明的标准化加密流程。

以下是此过程的高级演练：

这是一个发送到钱包的 payment_data 对象的非规范性示例，详细说明了供用户确认的交易。

{
    "payee": "Merchant XYZ",
    "currency_amount": {
        "currency": "EUR",
        "value": "23.58"
    },
    "recurring_schedule": {
        "start_date": "2024-11-01",
        "expiry_date": "2025-10-31",
        "frequency": 30
    }
}

用户批准后，钱包会创建一个密钥绑定 JWT。其声明证明用户确认了特定的交易数据。

{
    "nonce": "n-0S6_WzA2Mj",
    "aud": "https://example.com/verifier",
    "iat": 1709838604,
    "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4",
    "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"]
}

在技术标准不断演进的同时，支付行业并未停滞不前。关键参与者正在积极探索如何将数字凭证的安全性与支付功能相结合。

理解可验证凭证（VCs）潜力的一个有力方法是将其与成功的网络支付代币化系统（如 Visa Token Service 或 Mastercard MDES）进行比较。

• 支付代币化用一个安全的令牌和一次性密码取代了敏感的主账户号（PAN）。这在交易过程中保护了核心资产——卡号。
• 可验证凭证旨在为个人数据做同样的事情，就像代币化为 PANs 所做的那样。用户不是分享原始数据（姓名、出生日期、地址），而是出示来自可信发行方的加密签名凭证。

本质上，VC 对于个人数据，就像支付令牌和密码对于卡数据一样：一种安全、可验证的替代品，可降低风险并增强隐私。

基于这种相似性，行业机构正在研究“可验证支付凭证”的概念。这将是由银行发行的一种凭证，它打包了一个支付工具（如代币化的卡），并可用于授权交易。

• EMVCo，作为安全支付的标准机构，正在积极将 FIDO 标准集成到 EMV 3-D Secure 协议中。这使得先前的 Passkey 认证可以作为无摩擦批准的强信号，同时也为安全支付确认（SPC）作为传统 OTP 挑战的现代、抗钓鱼替代方案做好了准备。关于未来如何将可验证凭证纳入这些流程的讨论也在进行中。
• Visa 宣布了Visa Payment Passkey Service，该服务将 FIDO 认证器与支付凭证安全绑定。此服务旨在通过一个无缝的步骤确认身份并授权支付，而不会中断结账体验。
• Mastercard 正在采取类似的策略，推出了其Mastercard Payment Passkey Service，该服务利用其令牌认证服务（TAS）以基于 Passkey 的生物识别认证取代密码和 OTP，并与其代币化服务（MDES）紧密集成。

这显示了一个明确的趋势：行业正朝着一个未来迈进，即钱包可以在一个标准化的流程中，出示一个可加密验证的身份和支付授权证明。

大部分创新都得益于强有力的监管推动，特别是来自欧盟的推动。

欧盟的 eIDAS 2.0 法规不仅仅是为公民提供数字身份；它明确设想将 EUDI 钱包作为执行在线支付 SCA 的一种方法。这意味着未来，欧盟的银行和支付提供商可能被要求接受 EUDI 钱包作为用户确认在线交易的方式，为专有的银行应用或短信验证码提供一个基于标准的替代方案。

欧盟一项具有里程碑意义的反垄断和解已经迫使苹果开放其之前封闭的 iPhone NFC 接口。自 iOS 17.4（2024 年 3 月 5 日发布）起，苹果已实施了必要的 API，并允许用户选择默认的非接触式支付应用，以满足欧盟委员会 2024 年 7 月 25 日的强制性截止日期。这不再是未来的展望；它已是欧洲经济区（EEA）的当前现实。

这一转变意味着第三方钱包应用现在可以在 iOS 上提供自己的“一触即付”解决方案，结束了 Apple Pay 的长期垄断。开发者现在可用的关键功能包括：

• 默认钱包选择： EEA 的用户可以将符合条件的第三方应用设置为其默认的非接触式支付应用，该应用可通过双击侧边按钮来调用。
• 完全集成： 这些钱包可以使用 iPhone 的原生安全功能，包括面容 ID 和触控 ID，进行支付授权。
• 现实世界采用： 几家主要参与者已经推出了他们的解决方案，包括挪威的 Vipps MobilePay 和德国的 PayPal。

这次开放的影响是巨大的，并且已经开始显现：

• 竞争加剧： 银行和金融科技公司现在可以在苹果自己的平台上直接与 Apple Pay 竞争，预计这将降低发行方费用并刺激创新。
• 更广泛的凭证使用： 相同的 API 不仅可以用于支付，还可以用于公司徽章、公交卡和酒店钥匙等，而无需存放在 Apple Wallet 中。
• 为标准化凭证铺平道路： 这树立了一个至关重要的先例。开放 NFC 接口用于支付应用的相同监管逻辑最终可能被用来强制支持标准化的、中立的“可验证支付凭证”（如正在为 EUDI 钱包试点的那些），使其能够与专有解决方案并存。
• 全球先例： 虽然这一变化目前仅限于 EEA，但它树立了一个强有力的全球先例。包括美国在内的其他地区的监管机构正在密切关注，这可能会加速全球范围内的类似开放。

对于支付发行方（银行、卡组织、金融科技公司）来说，向数字凭证的转变需要一个务实的、分阶段的策略。目标是利用您今天控制的资产，为明天的生态系统做好准备。本手册概述了该策略，从即时、低风险的行动过渡到更具战略性的长期评估。

任何未来钱包策略的基础都是一个安全、被广泛采用的原生应用。当务之急是最大化您应用的覆盖范围，并加强其在登录和支付方面的认证。

1. 推动原生应用采用： 您的移动应用就是您未来的钱包。主要目标是使其成为客户不可或缺的工具。这种分发和参与是任何未来凭证发行或钱包功能的关键基础。

2. 效仿 PayPal 模式，使用 Passkeys 进行支付： 立即部署 Passkeys，不仅用于登录，还用于支付授权。力求实现与 Apple Pay 等原生平台解决方案相媲美的体验。对于需要强客户认证（SCA）的监管环境，采用 PayPal 的务实方法：

   • 将 Passkeys 作为主要认证因素。
   • 将其与可信设备信号（例如，通过您的应用或安全 cookie 管理的“已记住的设备”）相结合，以满足 SCA 的“拥有”因素。
   • 这种组合使您能够提供无缝、低摩擦的支付确认体验，既高度安全又合规，无需等待通用的 VC 支持。

以一个受 Passkey 保护的安全应用为基础，您可以开始有选择地集成新的凭证技术，前提是它们能提供明确的价值。

3. 监控可验证支付凭证的兴起： 携带支付令牌的 VC 概念虽然强大，但尚未标准化。您在这里的角色是成为一个积极的观察者和参与者。

   • 行动： 密切跟踪 EMVCo 和 W3C 等标准机构的进展。准备好在标准化的可验证支付凭证提供明显优于现有基于 Passkey 的流程时加以利用。

4. 将数字凭证用于身份用例： 随着数字身份钱包（如 EUDI 钱包）的普及，将数字凭证 API 集成到_与身份相关_的任务中，而不是支付。

   • 行动： 在以下高保障流程中使用 VC 出示，发挥其优势：
     • 开户和 KYC： 简化新账户设置。
     • 升级认证： 为高风险操作验证身份。
     • 账户恢复： 为丢失设备的用户提供安全的恢复路径。

任何新支付技术被采用的最终障碍是用户摩擦。在取代简单的 Passkey 流程之前，基于 VC 的替代方案必须证明它不仅更安全，而且同样无缝。

5. 与一键式体验进行不懈的基准比较： 现代支付体验的标准由 Apple Pay 及其在 Web 上的紧密追随者 PayPal 设定。您引入的任何新流程都必须与它们近乎即时的一键确认相竞争。所有当前信号都表明，对于绝大多数交易，Passkeys 的抗钓鱼性提供了足够级别的保护和卓越的用户体验。如果向支付流程中添加 VC 出示步骤会引入任何可察觉的摩擦，请不要这样做。

6. 关注 WebAuthn 中的带内设备信号： Passkeys 的演进并非一成不变。虽然早期提供特定设备信号的尝试已被中止，但标准机构正在积极致力于将更强的设备绑定信任信号直接集成到 WebAuthn 协议中。这将允许 RP 在 Passkey 认证期间识别可信设备，进一步加强风险引擎的信号，而无需单独的、带外的 VC 出示。密切关注这一领域，因为这是在不牺牲 Passkey 无摩擦体验的情况下增强安全性的最可能途径。

通过遵循这个分阶段的手册，发行方可以建立一个稳健、实用的策略，在今天最大化安全性和提升用户体验，同时为审慎采用未来的可验证支付技术做好准备。

要使数字凭证在支付流程中发挥核心作用，而不仅仅是支持 KYC 或用户支付账户认证，必须解决几个重大挑战：

1. 支付专用 VCs 的标准化： 需要开发一种专用的、安全的、被广泛接受的支付可验证凭证格式。这需要封装支付令牌、交易特定数据以及可能的动态安全元素，远远超出了当前以身份为中心的 mdocs 或通用 VCs 的范围。
2. 与支付网络的集成： 任何基于 VC 的支付解决方案都必须与现有的全球支付网络（Visa、Mastercard 等）无缝集成，或提出可行的新渠道。这涉及复杂的技术、安全和商业模式的协调。
3. 法规遵从性： 支付受到严格监管（例如，欧洲的 PSD2/SCA，全球的 PCI DSS）。基于 VC 的支付系统需要满足所有相关的金融法规，包括安全、消费者保护和反欺诈方面的规定。
4. 发行方和收单方的采用： 银行、金融机构（作为支付 VCs 的发行方）和商户收单方需要投资于支持此类系统的基础设施。
5. 安全模型： 专门针对支付 VCs 的强大安全模型至关重要，涵盖发行、存储（最好在硬件支持的安全元件中）、出示和在金融环境中的撤销。
6. 用户体验： 虽然 VCs 可以提供用户控制权，但支付体验必须保持快速、直观和可靠，才能获得广泛采用。

未来的可能性：

• VCs 作为支付授权凭证： VCs 可以代表一个加密签名的“授权”，用于从关联账户支付，通过 OpenID4VP 出示，而实际的资金转移仍通过传统渠道进行。
• 包含支付令牌的 VCs： 可以定义一种标准化的 VC，以安全地持有支付令牌（类似于 EMV DPAN），然后由现有的支付基础设施处理。
• 闭环支付 VCs： 特定的发行方或社区可能会创建用于其自身闭环系统内支付的 VCs。

然而，这些目前在很大程度上仍是概念性的。当前 VC 和 mdoc 发展的首要动力，现在已由浏览器 API 的具体实现所巩固，仍然集中在身份验证和属性证明上，而不是支付执行。

数字身份与支付的融合呈现出一个复杂但可驾驭的格局。虽然单一、通用的“可验证支付凭证”的前景引人入胜，但本文的结论是，对于当今的支付发行方而言，最有效和务实的策略植根于一个不同的现实：争夺最佳用户体验的战斗至关重要，而 Passkeys 是最强大的武器。

战略手册是明确的。即时、低风险的举措是专注于建立一个无与伦比的原生应用，并以此为载体部署基于 Passkey 的支付，使其能够与 Apple Pay 和 PayPal 设定的无摩擦“一键式”标准相媲美。这种方法利用成熟、广泛采用的技术，满足了当今安全（通过抗钓鱼）和用户体验的核心需求。

在这种模式下，可验证凭证找到了其关键但独特的角色。它们尚不是支付行为本身的工具，但对于围绕支付的高保障身份任务却是不可或缺的：安全开户、稳健的账户恢复和监管 KYC。

支付的未来不会由单一技术决定，而是由对用户的持续关注决定。成功将属于那些首先在自己的应用中掌握 Passkey 驱动体验的发行方，同时审慎监控可验证凭证和带内 Passkey 信任信号的演变。他们必须准备好集成这些新技术，不是在它们仅仅可用时，而是在它们能够达到真正无缝、安全和卓越支付体验这一强大基准时。