agentwallets.si
← 返回博客

独立解读

Mastercard Agent Pay:把持卡人的意图带进 Agent 交易

文章图解 · 概念示意
01持卡人意图02Agent 凭证03商户交易

类型:支付网络、授权信任层与机器支付服务|面向:银行、商户、Agent 平台和基础设施提供商|资料核验:2026-10-28|未实测。

你让 Agent 买一双不超过 100 美元的鞋。商家收到付款请求时,如何判断这笔交易确实在你的授权范围内?Mastercard 的回答包括 Agent Pay、Agent 专用凭证,以及用于表达用户授权的 Verifiable Intent。它也在探索另一类场景:Agent 高频购买 API、数据和计算资源。

公司背景与定位

Mastercard 运营全球支付网络并提供相关技术和服务。Agent Pay 是接入网络和信任体系的一组能力,不是一款自动装有资金的独立 Agent 钱包。 用户资金、卡、支付接受和权限实施依赖发卡方、商户与集成伙伴。Agent Pay for Machines(AP4M)则面向程序化、低额或高频的机器交易。Agent Pay · AP4M 发布

一次受限购买的概念路径

flowchart LR U[用户表达购买条件] --> A[Agent 选择商品] A --> I[授权意图记录与验证] I --> T[受限支付凭证] T --> M[商户和支付参与方处理] M --> R[订单与交易结果返回]

2026 年 3 月,Mastercard 与 Google 介绍 Verifiable Intent:以防篡改记录及密码学证明表达用户授权,目标是帮助商户、发卡方等核对 Agent 行为。其说明称方案与 AP2、UCP 对齐、设计为跨协议使用,并在当时将接入 Agent Pay intent API 描述为未来工作。公开规范不等于每个商家已部署,也不保证用户偏好均能完整机器化。Verifiable Intent

能力 想解决的问题 需要进一步确认
已登记 Agent 与网络凭证 区分参与方并减少暴露原始卡数据 如何注册、覆盖哪些平台与发卡机构
Verifiable Intent 留存和验证用户允许 Agent 做什么 消费者怎样确认、更改、撤销,争议时谁负责
Agent Pay 协调受支持的 Agent 发起交易 支持地区、商户、持卡人验证及售后
AP4M 面向机器之间的小额、高频交易 实际开放范围、延迟、费率和结算保证的合同条件

截至 2026 年 10 月 29 日,Mastercard 面向 Cloudflare Connect 的早期访问页面将 AP4M 标为试点,明确表示尚未商业开放;这不应与广泛商用混同。

AP4M 于 2026 年 6 月发布。公司称其设计支持从卡到稳定币等多种支付方式,并公布一批支持方;合作公告证明产品方向和伙伴名单,不证明所有伙伴都已上线所有功能。半美分交易能否经济可行,还取决于真实费用、汇总和结算安排。AP4M 公告

商业模式与竞争

Mastercard 的既有收入涉及网络和相关增值服务;Agent Pay 专项费率、具体收入分成及每种机器交易的收费未在上述资料中披露。分析上,它希望把可验证意图、网络凭证和结算能力带入新渠道,以保留网络价值;不能因此推定已产生多少收入。

与 Visa TAP 比较,双方都在为可信 Agent 的支付建立身份和控制层;Verifiable Intent 更突出可验证的用户意图,具体安全与开放能力须对照实施。与 Nevermined 比较,前者以网络及伙伴为中心,后者提供面向 AI 服务的计量、付款计划和授权工具,它们可能在不同层合作。

读者应关注:用户在每笔交易前是否需批准?意图证明由谁签发并保存?谁处理退款和争议?如果 Agent 替换商品或商户,原授权是否仍有效?AP4M 宣称的各条结算路径是否真的在所需地区开放?

一张卡上的三层问题

用户提出“买一双低于 100 美元的鞋”,最终支付涉及至少三层:一是 Agent 代表谁、用户授权了什么;二是 Token 限定在哪个范围内可用;三是发卡方和网络是否批准交易。Verifiable Intent 关注第一层的可验证记录,Agentic Token 将受限支付凭证用于交易;卡交易批准与商户履约仍由相应参与者处理。这样即使购买要求合法,缺货、认证失败或支付拒绝仍会阻止订单完成。Verifiable Intent · Agent Pay

假设商家把商品税费加上后超过 100 美元,平台如何判断限制适用含税总额还是商品标价?这是授权设计中的必要细节,但官方公开介绍并未证明所有集成遵循同一规则。想要产品落地,用户需要能查看和更改授权;发卡行和商户需要知道在授权不一致、记录缺失或消费争议时采取什么行动。

机器支付为什么是另一道商业题?

Mastercard 描述 AP4M 面向大量、低延迟、低金额的机器交易,举出的示例包括买数据、计算或物流服务。对于一个 $0.001 的接口请求,除了 API 价格,平台和网络费用是否高到吞噬交易价值、是否需要汇总结算、卖方如何确认付款,都决定商业可行性。官方发布材料表达了支持多种支付方式和结算的方向,但没有公开可用于推算该例成本的统一收费和延迟保证,因此不能据此得出“微支付一定更便宜”。AP4M 公告

观察点 消费者购物 机器购买 API
授权 商品、金额、商户、交付条件 服务、预算、频率、期限
支付节奏 通常围绕订单 可能连续或高频
结果 订单、物流和退货 API 结果、额度和失败重试
定价核验 商户与持卡人费用、退货成本 每请求及汇总结算成本

这种比较是场景分析,不是对当前部署能力的保证。Mastercard 的伙伴列表可以说明谁公开支持该方向,不能证明每个伙伴已支持所有资产或服务。

验证与售后

平台接入前应要求一条测试订单的证据:用户授权内容、Agent 身份、凭证约束、商户订单、网络响应及可见状态是否能关联。还应问是否支持权限撤销、卡号更新、退款和购买争议,特别是用户授权记录与实际订单内容不一致时由谁判断。上述问题需要伙伴与合同补足,不能把一份密码学记录当成自动退款承诺。

参考资料