为智能体准备好结账：AI 替顾客下单时的支付、令牌与信任

周二早上 9 点 12 分，一家小型电子产品店的店主收到一位顾客的 AI 助手下的一单：一个笔记本电脑充电器，49 美元，用顾客的银行专门为这家店签发、30 分钟内有效的令牌支付。没有卡号，没有账号，也没有浏览器会话。

她的风控规则是照着人的行为调的。规则看到的是新设备、没有鼠标轨迹、两秒钟就完成结账，于是把这单判为高风险并拒绝。同一个早上，另一个只在请求头里自称“智能体”的请求，却顺利通过了她那条“已知可信自动化”的规则。真实的订单被拒之门外，机器人却被放了进来。（这是一个假设的场景，并非真实店铺。）

解决办法不是把规则放松，也不是收紧。面向智能体的结账流程要按顺序问三个问题：谁在请求，智能体被允许买什么，这一单本身风险有多高。本文接下来讲的，就是这三个问题背后的各个环节。

本系列第一篇问的是：AI 智能体能不能找到并读懂你的店铺。第二篇问的是：助手会不会推荐你。这一篇要回答决定谁能收到钱的问题：智能体准备下单时，你的结账流程能不能安全地说一声“可以”？ 2026 年每一个像样的方案，都用一个受限、可撤销的凭证取代了卡号，同时附上一份签名记录，写明买家授权了什么。下文会说明截至 2026 年 9 月初各个方案的状态，并给出一份现在就该在结账流程里做的检查清单。

本文是“向 AI 智能体卖货”系列的第 3 篇，共 3 篇。第 1 篇：智能体商务：当下一位顾客是 AI 智能体，你该怎么卖货。第 2 篇：网店的生成式引擎优化（GEO）。

智能体不看卡号，怎么付款

在网上付款时，我们会在表单里输入 16 位卡号。智能体要是也这么做，这串数字就会留在模型服务商的系统、日志和记忆里。业界的办法是给智能体一个替身凭证。

这个替身就是令牌化凭证。真正的银行卡仍留在银行或钱包手里。智能体拿到的令牌只限一家商户、一个金额上限和一小段有效时间，买家随时可以撤销。即使泄露，攻击者拿到的也只是一张几乎用完的许可条，而不是一张卡。

令牌并不新鲜。多年来，银行卡组织一直在移动钱包和已保存的卡片背后使用网络令牌。新的地方在于给令牌附上规则：这个智能体是谁，能买什么，能用多久。

2026 年 9 月各个方案的进展

好几个方案相互交叠，它们不像浏览器那样彼此竞争。有的规定智能体如何与店铺对话，有的负责证明买家的授权，有的负责批准这笔付款。以下是截至 2026 年 9 月初的公开信息：

方案	覆盖内容	状态（2026 年 9 月）
Agentic Commerce Protocol（OpenAI 与 Stripe）	智能体如何发起结账，并把支付令牌交给商家	2025 年 9 月作为开放标准发布。据报道，ChatGPT 内的 Instant Checkout 已于 2026 年 3 月结束，但协议仍在延续，规范最新修订为 2026 年 4 月
Stripe Shared Payment Tokens 与 Agentic Commerce Suite	限定卖家、金额和时间的令牌	2025 年 12 月推出；其他支付服务商可通过协议的委托支付规范接入
Agent Payments Protocol，AP2（Google）	用签名授权委托证明买家批准了什么	2025 年 9 月发布；2026 年 4 月移交 FIDO Alliance 进行标准化
Universal Commerce Protocol 与 Universal Cart（Google）	商品目录与结账标准，以及横跨搜索和 Gemini 的购物车	标准于 2026 年 1 月发布；购物车于 2026 年 5 月宣布，计划夏季在美国推出。把它写进计划前，请先确认当前是否可用
Visa Intelligent Commerce 与 Trusted Agent Protocol	智能体令牌，以及用于识别可信智能体的签名请求	2025 年 10 月与商户和处理机构合作伙伴一同发布；开发者沙盒已开放
Mastercard Agent Pay	建立在现有银行卡令牌化之上的智能体令牌	据报道，亚太地区自 2026 年 3 月起出现首批真实的智能体支付；其 Verifiable Intent 框架已贡献给 FIDO Alliance

比起任何一行，有两点更重要。第一，唯一试图把整个购买过程放进聊天窗口的方案退了一步，而它背后的基础设施仍在前进。第二，标准组织已经入场：2026 年 4 月，FIDO Alliance 宣布成立工作组，负责智能体身份认证和由智能体发起的商务，起点是 Google 与 Mastercard 的贡献。这通常意味着整个领域在走向统一。

目前交易量仍然很小。要做的是让结账流程能够接纳智能体，而不是把营收押在它们身上。

授权委托：对“批准了什么”的签名记录

令牌只说“这个凭证可以扣款”，没说为什么。补上这一环的是授权委托（mandate）。它是买家许可的签名记录，AP2 把它拆成三部分：

• Intent mandate（意图委托）：买家想要什么、限额多少，例如“跑鞋，120 美元以内，周五前送到”。
• Cart mandate（购物车委托）：智能体生成的那份购物车的原样记录，含价格，并经过签名，事后没人能改动任何一行。
• Payment mandate（支付委托）：发给支付网络的授权，标明这笔交易有智能体参与。

可以把它想成一张签字的采购单。买家批准预算，智能体填写订单，签名把两者连在一起。几个月后收到争议时，“顾客当时真的同意了吗”这个问题就有了文件作依据。

这对你的结账流程意味着什么

密码学不用你自己写，签名由支付服务商或平台来验证。你要做的是保持签名所依赖的数据稳定：你返回的购物车必须和你扣款的购物车一致，价格、税费、运费、币种都不能差。报价之后悄悄调整合计的结账流程，会把这条证据链弄断。

出了问题，谁来买单

这件事还没有人彻底厘清。银行卡规则是为坐在屏幕前的人写的。智能体买了买家并不想要的东西，可能是欺诈，可能是商家失误，也可能是已授权的购买。就我所知，还没有哪条公开的规则能在所有方案中清楚划分买家、智能体服务商和商家之间的责任。在你的支付服务商条款另有说明之前，请默认损失由商家承担。

各大卡组织正在处理。经过签名的智能体身份和授权委托，就是为了让发卡行能区分“持卡人通过智能体授权”与“欺诈”。把这看作方向，而不是保证；开通智能体交易之前，先读一读你的支付服务商对这类交易的条款。

举个假设的例子：买家让智能体“给我的笔记本电脑买个充电器”。智能体买成了接口不对的型号，买家对这笔扣款提出争议。如果你的商品页写清了接口类型，而 cart mandate 又记录了当时展示的内容，你的证据就很扎实；如果商品页含糊其辞，这场争议很难赢，责任也多半算在你头上。

智能体时代的风控信号与争议

多数风控系统其实默默依赖人的行为：鼠标轨迹、打字速度、见过的设备、浏览历史。智能体一样都没有。所以，一笔合法的智能体订单可能看起来像机器人攻击，而真正的机器人也可能披上智能体的外衣。

从四个方面更新你的规则：

• 把智能体信息当作信号，而不是免检通行证。持有有效授权委托的已验证智能体会降低风险；只是自称智能体的未验证请求则会提高风险。
• 自动留存证据。保存授权委托或令牌的引用、报价时的购物车、送达确认，以及下单当天生效的政策原文。
• 按授权委托监控频次。一份只买一双鞋的委托，不该产生十五笔订单。
• 在报表里把智能体订单单独列出。不记录订单来源，就没法比较退货率和争议率。

把这些合在一起，单笔智能体订单的决策流程如下。身份检查排在最前面，因为没有它，另外两项检查就失去意义。缺少授权委托或风险分偏高，不一定要直接拒绝：可以请买家确认，把存疑的订单变成已确认的订单。

欢迎好智能体，拦住坏机器人

很多店铺面对机器人问题，一刀切全部封禁。当所有自动化访客都是爬虫时，这么做没问题。现在有些自动化访客是买家的代理人，把它们拦在门外，就是丢掉一张订单。

可行的做法是分流。先看请求有没有可验证的身份。Visa 的 Trusted Agent Protocol 和 Web Bot Auth 提案都使用 HTTP 消息签名：智能体用私钥给每个请求签名，你用公开发布的公钥验证签名。2025 年 10 月，Cloudflare 与 Visa、Mastercard 一同宣布支持这一做法。

三条通道

• 已验证智能体：签名通过。允许访问商品、购物车和结账，按正常限速处理。
• 爬虫：没有身份，但行为只读。提供公开页面，限制频率，不让它碰购物车和结账接口。
• 疑似欺诈：没有身份，行为异常，比如测试银行卡，或同一地址生成大量购物车。发起挑战验证或直接拦截。

也别忘了回头检查 robots 规则和机器人防护设置。结账页上一条“拦截所有非浏览器 user agent”的规则，也许此刻就在拒绝合法的智能体。

确认、收据与退货

人在网站上下单，看到的是确认页。智能体下单，买家看到的是智能体转述的内容，所以你的确认信息既要给人看，也要能被软件读懂。

• 机器可读的确认：订单号、商品明细、合计、税费、预计送达时间和状态链接，放在完成订单的同一个响应里返回。
• 邮件收据仍然发给买家。别指望智能体帮你转发。使用买家的真实邮箱，而不是日后联系不上的中转地址。
• 结构化的状态：已付款、已打包、已发货、已送达，并附物流追踪链接，让“我的订单到哪了”有一个智能体能自己取到的答案。
• 智能体能发起的退货：有文档说明的退货申请，带原因代码、资格校验，以及原路退回的退款方式。

退款要格外小心。如果原付款用的是受限令牌，就通过你的支付服务商退回原支付方式，不要手动转账。

现在就该改的结账清单

这些事并不要求你本季度就接入所有协议。要的是一个足够干净的结账流程，让日后接入任何一个协议都只是个小项目。请按顺序逐项完成。

1. 提供干净的订单 API。创建购物车、更新购物车、报运费和税费、完成订单、查询订单状态，每个都有稳定的接口和可读的错误信息。
2. 让报价具有约束力。你报的价格、税费和运费应与实际扣款一致，并在约定时间后失效。
3. 允许游客结账。强制注册账号，会挡住替从未访问过你的买家办事的智能体。
4. 选择支持令牌化支付和委托支付的支付服务商。问清楚它支持哪些智能体方案，以及这类争议怎么处理。
5. 记录订单来源。按渠道（包括智能体来源）给订单打标签，并保存令牌或授权委托的引用。
6. 公布精确的政策。送达时效、退货期限、退款方式，写成规则，而不是口号。
7. 把好流量和坏流量分开。验证已签名的智能体，对其余流量限速或发起挑战，而不是全部封禁。
8. 发送结构化的确认和状态更新。同样的信息，一份给人看，一份给机器读。
9. 在沙盒里测试。Visa、Stripe 等都提供测试环境；真金白银流动之前，先跑通一次完整的智能体购买、一次退款和一次争议。
10. 定好复查日期。这个领域十二个月里变过好几次；每季度查看一次各方案的状态。

这个系列带你走到了哪里

三篇文章拼成一幅完整的图。智能体要能找到你（第 1 篇），要会选择你（第 2 篇），还要能在没人替你修结账流程的情况下把钱付给你（本篇）。贯穿始终的是你能负责到底的数据：准确的商品信息、具体的政策、有约束力的报价，以及每位顾客授权内容的记录。

再回到 9 点 12 分的店主。三道检查到位后，这单 49 美元的充电器走了另一条路。签名验证通过，授权委托（一个充电器，上限 60 美元）覆盖了购物车，有效的授权委托也让风险评分偏向通过。扣款经由她自己的支付服务商完成，确认信息几秒钟内就送到顾客的助手和邮箱。

那个只是自称智能体的请求，在第一道检查就被拦下，碰不到她的购物车。她的规则并没有变严或变松，而是变具体了：现在看的是谁在请求、被允许做什么，而不是人会怎么点鼠标。

核心要点

• 智能体用受限、可撤销的令牌付款，而不是卡号；签名的授权委托记录了买家允许的范围。
• 截至 2026 年 9 月，这个领域正通过 FIDO Alliance 走向共同标准；据报道，OpenAI 在聊天内的 Instant Checkout 于 2026 年 3 月结束，底层协议仍在延续。
• 智能体购买的责任归属尚无定论，所以要留好扎实的证据：报价时的购物车、令牌或授权委托引用、政策原文和送达证明。
• 按已验证身份给自动化流量分流：放行已验证的智能体，对爬虫限速，拦截欺诈。
• 有约束力的报价、游客结账、干净的订单 API 和结构化状态，无论哪个协议胜出，这些改进都用得上。
• 每季度复查各方案的状态，上线前先在沙盒中测试。

Anichur Rahaman 是一名软件架构师，也是 StoreConsole 的创建者。他为成长型企业设计电商与 ERP 系统，专注于事件驱动架构、数据完整性和自托管部署。