代理商务的身份层：Visa TAP、Google AP2与万事达Agent Pay解析

主要收获

• Visa 可信代理协议 (TAP)、Google 代理支付协议 (AP2) 和万事达 Agent Pay 都让代理主导的购买更安全，但它们解决了信任问题的不同部分。
• TAP 帮助商家识别经批准的代理并验证已签署的商业意图。AP2 创建用户授权内容的证据。Agent Pay 结合了注册代理、代币化支付凭证、同意和网络可见性。
• 这些机制都不能消除证明人类或企业身份、筛选风险、执行特定司法管辖区控制以及保留审计追踪的必要性。
• Didit 是身份和欺诈领域的中立基础设施，而非银行卡网络或支付公司。其托管的模型上下文协议 (MCP) 服务器公开了 11 个类别共 115 种工具，而表征性状态传输 (REST) 应用程序编程接口 (API) 支持嵌入式生产流程。
• 一套完整的“了解您的客户”(KYC) 捆绑服务费用为 0.33 美元，每个账户每月包含 500 次免费验证，MCP 服务器本身是免费的。

代理商务始于人工智能 (AI) 代理不仅仅推荐产品。它会比较报价、组装购物车、选择支付方式，并可能在个人或企业设定的限制内完成购买。这种转变同时带来了几个信任问题：哪个代理发出了请求？谁授权了它？它背后的人类或法律实体是谁？交易是否被允许？如果购买发生争议，将存在哪些证据？

新兴的支付标准回答了该序列中的重要部分。它们并非都回答相同的部分，也不应被视为可互换。对于开发者来说，有用的问题不是哪个品牌会“胜出”，而是无论采用何种可信架构，哪些控制仍然是必要的。

三种标准，三个信任边界

Visa TAP：商家能否识别并信任此代理？

Visa 可信代理协议面向商家。其核心工作是帮助商家区分经批准的商业代理与普通爬虫、恶意机器人或未知自动化程序。代理使用有时限、特定用途的凭证签署请求。商家或其保护提供商验证签名，并可决定是否允许浏览、结账或更窄的动作。

TAP 描述了三个相关信号：代理识别签名、链接并签署的消费者或设备身份，以及链接并签署的支付容器。这是有用的分离。代理识别确定了哪些经批准的代理存在；签署的意图确定了请求的交互类型；消费者信号可以帮助商家识别现有客户。

该消费者信号不自动等同于最新的身份验证。Visa 的模型包括上游的身份提供商角色，但商家仍需要针对新客户或高风险客户制定政策：检查了哪些证据、保证强度如何、是否需要 KYC 以及何时需要重新验证。TAP 可以承载可信身份信息，而无需规定每个司法管辖区的入职决策。

Google AP2：用户授权代理购买了什么？

Google 代理支付协议侧重于授权和证据。它使用已签署的授权书来连接用户意图、结账内容和支付。开放式授权书可以赋予代理有限的自由裁量权，例如商家限制或支出限额。封闭式授权书将批准绑定到特定的购物车和金额。收据完善了证据链。

AP2 区分了有人在场和无人在场的流程。当有人在场时，他们可以直接批准封闭式结账和支付授权。当不在场时，代理在先前批准的限制内操作并签署最终的封闭式授权。当无法解决限制时，商家或凭证提供商仍可以将人员带回流程。

此设计比“此人最初是如何验证的？”更直接地回答了“此人是否在这些条件下授权了此操作？”。AP2 授权框架假设相关的注册和用户凭证存在。因此，开发者仍然需要一个身份验证和凭证生命周期流程，然后这些授权才能提供有意义的保证。

万事达 Agent Pay：网络能否识别和管理代理支付？

万事达 Agent Pay 基于支付代币化。万事达的受理框架注册和验证代理，分配唯一的代理身份，并使用代理代币，以便交易可追溯且支付凭证受到保护。面向商家的识别可以与现有结账基础设施配合使用，而更深层次的集成支持更丰富的数据交换。

该模型还强调了消费者同意、身份验证以及发卡机构、收单机构和商家识别代理参与的能力。这使得代理活动在熟悉的银行卡网络风险模型中可见，而不是让自动化与普通无卡交易请求无法区分。

Agent Pay 在支付凭证安全、代理可见性和网络控制方面最强。它并未消除商家决定何时应用身份验证、了解您的业务 (KYB)、反洗钱 (AML) 筛选、年龄检查或强化审查的义务。这些决策取决于产品、客户、交易和司法管辖区——而不仅仅是支付渠道。

标准重叠之处——以及身份仍然适用之处

所有这三种方法都试图使委托商业变得清晰。商家应该能够判断自动化是否参与，验证代理是否受信任，将操作与用户意图联系起来，限制购买，并保留证据。它们的侧重点不同：

• TAP：在商家边界进行代理识别和签署的意图，并可选择链接消费者和支付信号。
• AP2：将用户意图绑定到结账和支付结果的加密授权工件。
• Agent Pay：注册代理、代币化支付凭证、同意、身份验证以及跨银行卡网络的可见性。

身份验证位于这些控制之前和旁边。签署的授权只有在凭证属于正确的人时才具有价值。经批准的代理仍然可以由合成的、被盗的、受制裁的、未成年或以其他方式不符合条件的账户指示。代币可以保护支付凭证，而无需确认市场卖家或企业受益人已通过所需的尽职调查。

代理身份回答“哪个软件执行了操作？”授权回答“它被允许做什么？”身份验证回答“它背后是谁？”欺诈和合规控制回答“此操作是否应继续进行？”

无论哪种方法获胜，开发者都必须构建什么

• 注册和验证。在授予可重用凭证或委托支出权限之前，验证个人或企业。根据风险应用 KYC、KYB、活体检测、文件、数据库或生物识别检查。
• 凭证绑定。将已验证的主体绑定到可以参与代理流程的账户、设备、通行密钥、钱包或其他凭证。
• 范围授权。捕获限制，例如商家、类别、金额、频率、有效期，以及是否必须由人工返回批准。
• 运行时风险决策。在操作发生时筛选个人、企业、钱包和交易。“了解您的交易”(KYT) 控制和 AML 检查即使在意图已签署时也仍然相关。
• 撤销和恢复。当凭证被泄露、用户撤回同意或风险发生变化时，停止委托权限。
• 可审计性。将验证结果、授权工件、代理身份、交易决策、时间戳和后续审查操作作为单独的证据保留。

这种分层设计是刻意与标准无关的。一个团队可以在商家边缘采用 TAP，在代理工作流中采用 AP2 授权，在银行卡结算中采用 Agent Pay，或采用组合。身份和欺诈决策仍然是可移植的，因为它没有嵌入到单个支付网络中。

Didit 如何在今天涵盖身份验证部分

Didit 为身份和欺诈提供了基础设施，被 2,000 多家生产公司使用。同样的功能可以通过用于代理驱动操作的托管 MCP 服务器和用于应用程序控制流程的 REST API 获得。有关更广泛的架构概述，请参阅MCP 服务器如何处理身份验证以及MCP 如何为 AI 代理连接身份和欺诈检查。

托管的 MCP 端点是 https://mcp.didit.me/mcp。它使用可流式超文本传输协议 (HTTP)，支持 OAuth 2.1、PKCE 和动态客户端注册。用户通过 Didit 业务控制台登录并授予范围访问权限；托管的 MCP 端点不使用 API 密钥身份验证。

授权后，代理可以调用 11 个类别共 115 种工具。实际的验证序列可以使用：

didit_context_get
didit_session_create
didit_verify_id
didit_verify_passive_liveness
didit_verify_face_match
didit_session_get_decision

这些工具可以创建验证会话，运行选定的检查，并检索结构化的决策。其他实际工具包括 didit_verify_aml、didit_verify_kyb_search、didit_verify_kyb_select 和 didit_transaction_screen_wallet。高风险写入仍然受连接用户的权限和确认行为的约束。

REST API 涵盖了应用程序路径：从您的后端创建会话，通过托管或嵌入式验证发送用户，使用 Webhook，并将决策存储在您自己的系统中。REST 服务器到服务器请求使用 x-api-key 标头；这与 OAuth 身份验证的托管 MCP 连接是分开的。请阅读MCP 概述、身份验证指南和工具参考以获取实施详情。

定价与代理支付标准无关。MCP 服务器是免费的。一套完整的 KYC 捆绑服务——身份验证、被动活体检测、人脸匹配和 IP 分析——费用为 0.33 美元，每个账户每月包含 500 次免费验证。

与标准无关的实施路径

首先定义每个操作所需的保证，而不是选择网络标志。低风险浏览可能只需要代理识别。账户创建可能需要验证身份。受监管的购买可能需要 KYC 或 KYB 以及 AML 筛选。加密货币转账可能需要添加钱包筛选。较高的金额或变化的风险可以将人类带回流程。

然后使用稳定的内部标识符将支付工件连接到身份决策。保持代理签名、用户授权、验证证据和支付结果的独立性，以便每个都可以独立撤销、审查和升级，随着标准的演变。

探索Didit MCP 开发者页面或检查公共、许可许可的 GitHub 存储库。Claude 用户可以添加 Didit 连接器并完成 OAuth 登录。

持久的架构是分层的：支付标准证明代理参与和授权；身份和欺诈基础设施证明参与者是谁以及操作是否可接受。这种划分使开发者能够支持今天的标准，而无需将信任硬编码到单一标准中。