ChatGPT Wallet 上线：智能体替你付款，商家该先补哪三道门？

ChatGPT Wallet 上线以后，很多人的第一反应大概是：智能体终于能替人付钱了。

这句话没错，但还差了最容易被略过的半截。对一个商家、平台产品或做交易链路的工程团队来说，难题并不在“让模型点一下支付”，而在于它从商品页一路走到订单确认时，谁能看什么、谁能批准什么、哪一步算真的成交。

OpenAI 这次把 Wallet 放进 dots，首批只向美国、年满 18 岁、持有合格美国发行银行卡的 ChatGPT Pro 用户逐步开放。普通 ChatGPT 对话、Work 和独立 Codex 线程都不在这个入口里。国内读者今天大概率还无法亲手走完这条链路，所以这篇不装成上手报告；我把官方公告、帮助中心和 Commerce 指引并排看了一遍，想把它翻成商家现在就能做的判断。

如果你负责的是商品页、预约、订票、支付接入，或者一套会替用户发起购买的 Agent，先把下面这件事记住：Wallet 把“付款资料”和“下单动作”拆开了，但没有替任何商家完成库存、风控、履约和售后判断。

付款不是把卡号交给 Agent

OpenAI 给出的流程很克制。用户先把卡加入 Wallet；到结账前，仍要看到商品、总价和所选卡，再通过 Face ID、指纹之类的安全确认批准这笔购买。确认以后，由支付网络提供替代真实银行卡资料的支付令牌，商家和 Agent 都不该直接拿到用户的实际卡号。

这里有个很工程化的区别：用户的确认，解决的是“我授权你尝试支付”；商家的订单确认，解决的是“我确实接受了这笔交易”。 两者不该混成一个布尔值。

官方帮助中心也特意写了：批准本身不保证订单已成立，用户还需要看商家的订单确认。库存不足、风控拦截、价格变化、配送范围不支持，都可能发生在支付动作之后。对于做过电商或预订系统的人，这不陌生；只是过去这个间隙主要出现在用户自己点提交时，现在多了一位会读页面、填表和推进流程的执行者。

所以别把“拿到来自 Agent 的购买请求”直接等同于“这位用户授予了永久权限”。当前公开信息说的是逐笔安全确认，未来才可能在金额、品类或时间段等边界内做预授权。那条未来路线很诱人，也正因如此，今天的订单状态、撤销入口和异常通知要留得足够清楚。

三道门，都是旧系统里的老问题

Wallet 没有凭空造出一套神秘支付栈。OpenAI 的 Commerce 指引反复落在三个既有系统上：商品信息、站点访问、支付与风险。把它们理解为三道门，比研究一堆新名词更有用。

门一：商品信息要能被准确读到

人类逛店时，看到模糊库存、过期价格或只写在图片里的规格，最多是关掉页面。Agent 继续沿着这些信息往下走，麻烦会被放大：它可能把已经失效的价格带到结账页，再把一次失败交给客服和风控收尾。

官方给商家的第一个动作是认领业务、更新资料，并在适用时提交商品 feed。重点不在“为了 AI 多做一份 SEO”，而在把价格、可用性、规格和限制当成会参与交易判断的数据。已经有商品 feed 的团队，可以先做一轮很朴素的核对：同一 SKU 在落地页、feed、购物车和结账页的价格与库存口径是否一致；下架和售罄多久同步；组合商品、地区限制和优惠券是否有明确机器可读的边界。

这不是为了迎合某一家 Agent。让事实在不同入口里保持一致，本来就是交易系统少返工的基本功。Agent 只是更快暴露了那些“网页看着没问题，数据却彼此打架”的缝。

门二：访问放行和结账放行，别绑成一件事

OpenAI 建议商家检查 CDN 或防火墙，确认不会误拦经过 Web Bot Auth 签名的 ChatGPT 请求；同时也明确说，浏览器访问不要求商家先装插件或上传商品 feed。

这给产品和安全团队留了一个很清楚的分工：让 Agent 看见公开商品，和让它进入账户、购物车、结账、售后，并不是同一层权限。

现实里最容易出事的不是“是否允许爬虫”，而是规则写得太粗。把未知自动化一刀切，用户可能连比较商品都做不完；把携带可信信号的自动化一律放宽，又会把登录、库存锁定、优惠券和高频试探暴露给不该拥有它们的请求。比较稳的做法是把日志和策略至少分开看：公开浏览、已验证 Agent、已登录用户、涉及金额或个人资料的动作，各自走什么限流、挑战、审批和告警。

这部分不必为了 Wallet 重造网关。先把现有 WAF、CDN、反欺诈和支付服务商的规则翻出来，问三个具体问题就够了：带签名的 Agent 浏览请求会不会被误伤？进入结账后的失败原因能否区分出来？异常的频率、金额或商品组合出现时，谁能看到、谁能停？

门三：让订单确认成为唯一的事实来源

支付令牌可以让 Agent 完成付款，不会替商家做库存预留、履约、退款或客服解释。真正可怕的体验往往不是扣款失败，而是用户和 Agent 都以为买到了，后台却只留下一个半截订单。

这里可以沿用交易系统熟悉的手法：给一次下单尝试留可追踪的请求标识；把支付成功、风控通过、库存确认、订单创建和通知发出拆成可观察的状态；任何一环不成立，都回到清晰的失败原因与可恢复动作。它们是工程建议，不是 OpenAI 规定的协议字段，但在 Agent 参与的链路里会更重要，因为“是谁点的”不再能替代“系统到底确认了什么”。

对用户界面也是一样。不要让一个模糊的“正在处理”承担全部解释。订单页至少应让人看清商家是否接受、预计何时履约、如何取消或联系支持。用户把任务交给 Agent，并不等于把事后的知情权也交了出去。

现在不必接入，但该做一次 30 分钟排查

首批范围有限，没有必要为了新闻热度连夜做一套 Wallet 专属支付插件。对大多数中国团队，今天更合理的决定是把它当作一次交易链路体检。

可以从一条真实商品或预约流程开始，不需要改代码：

• 用同一个商品分别走落地页、站内搜索、购物车和结账前页，核对价格、库存、地区与优惠的口径。
• 找安全同事看一次 WAF／CDN 日志，弄清自动化浏览、签名请求和高风险结账动作目前会被怎样分类。
• 让支付、风控和客服各写下“订单已经成立”的判断条件；三份答案对不齐的地方，就是 Agent 进入后最容易冒烟的地方。
• 抽一笔取消、缺货或支付被拒的订单，确认用户最终看见的是商家确认，而不是某个中间步骤的乐观提示。

这些检查不依赖你是否接入 ChatGPT，也不依赖今天有没有资格开通 Wallet。它们的产物是一张能被支付、风控、产品和客服共同认可的状态表。等到有真实用户和真实支持范围时，再决定要不要投到商品 feed、浏览器访问或插件上，节奏会稳得多。

还有两件事不该被这波热度推着做。

一件是把 Agent 的访问身份直接当成用户登录态。能够证明“这个请求来自某个受信任的自动化客户端”，不等于它天然拥有用户账户里的地址、订单、优惠资格或付款权限。涉及个人资料、改价、锁库存、提交订单的动作，仍应该沿用你原有的会话、权限与二次确认边界。把浏览放行、账户访问和交易执行分开，后面才有回滚余地。

另一件是只盯着成功率。Agent 参与后，失败会有更丰富的形态：页面能读到但商品失效；支付已被授权但订单未建立；订单建立了但通知没到用户；风控拦截了，却只给出一个无法行动的泛化报错。每一种失败都该有可检索的事件、面向用户的解释和明确的下一步。把这些失败路径走通，通常比把第一笔演示订单做得漂亮更值钱。

这次发布真正把门槛推到了哪里

从用户侧看，ChatGPT Wallet 把一段很别扭的流程缩短了：比较商品的人、填地址的人和最终支付的人，终于可以在一次受控的确认里接上。它仍然不是“把银行卡扔给模型”：公开的设计里保留了逐笔审核、支付令牌，以及现有支付网络与商家各自的责任边界。

从商家侧看，门槛反倒更朴素。商品得是真的，访问策略得讲得清，风险系统得能识别这类订单，订单确认得能落到用户手里。前面三项没理顺，再漂亮的 Agent 入口也只会把一条脆弱链路跑得更快。

如果你负责一条会被 Agent 触达的交易流程，最想先核对哪一段：商品数据、访问策略，还是订单状态？

— 小岛 AI

资料： OpenAI：ChatGPT Wallet 公告；OpenAI 帮助中心：Wallet 购买流程；OpenAI Developers：Commerce Partner Playbook。