智能体结账：先批准总价，再确认付款结果

买家让助手购买兼容的笔记本充电器，最多花60。商品49、运费6、假设税额11，总计66。店铺先遇到的不是智能体支付问题，而是报价超出预算。金额使用一种未指定货币，只是演算，并非税务建议。

再假设买家通过受支持的路径批准了调整后的66总额，支付请求却超时了。是付款失败，还是支付机构已扣款而响应丢失？如果“重试”意味着新建付款，就很危险。

这两个时刻比一排协议标志更能说明智能体结账。先证明当前购买被允许，再确认实际发生了什么。下文电子产品小店是教学案例，并非真实销售成果。

报价应覆盖整笔购买，不只是商品

原来的60上限不涵盖66总额，超出6。不要默默改成“仅商品预算”，也不要拆分支付来绕过上限。提供获准的替代方案，或取得必要的新批准。配送、数量、接口、货币或卖家改变，也可能改变批准范围。

有用的报价包括准确规格、设备兼容要求、商品金额、优惠、税费、运费、货币、配送预估及其他适用收费，并说明有效期与库存预留条件。相关条款改变，应重新验证和更新权限，而非按过期报价扣款。购物车本身不保证预留库存。

买家可以在商家结账页批准、转移购物车，或使用符合资格的助手内集成。Google原生结账指南描述受支持的生命周期，不代表人人可加入。确认商家实际可用的路径及版本。

四个信任问题要分别回答

识别调用者、证明买家权限、验证支付凭证与评估交易，彼此相关却不能替代。表格将它们分开。真实智能体也可能提出未授权购买；买家批准后，普通控制仍可能要求拒绝。

AP2委托模型区分直接批准购物车与委托以后采取行动的指令。应使用实际支持的委托及限制；聊天记录本身不是经过验证的委托。

FIDO在2026年4月的公告说明基于AP2和Verifiable Intent贡献开展标准制定，并非证明所有商家集成今天已可互操作。

问题	检查的证据	不能取代什么
谁在调用？	受支持的调用者／会话验证	买家权限或所有接口授权
买家允许什么？	当前准确购物车或有限委托	支付处理与风控
凭证可以使用吗？	机构验证范围、金额与有效性	产品适用性或全部客户意图
交易发生了什么？	已验证机构与商家记录	单独证明结算、送达或争议结果

令牌缩小访问范围，却不证明一切

Stripe当前卖家指南说明限定卖家的Shared Payment Tokens及使用、到期限制，也包含定期扣款配置。不能统一假定为银行签发、仅一次且三十分钟的凭证。

询问由谁验证授权、限定哪个卖家与货币、金额及使用条件，以及到期和撤销如何执行。让凭证对应获批购买与当前账户权限。有效凭证并不证明产品兼容，也不证明买家想要的数量。

不要把凭证放进提示词、模型记忆、截图、分析或普通日志。仅按保留政策保存必要的受保护引用和证据。令牌化不免除访问控制、安全处理及所选支付流程的合规责任。采用受支持的机构库，不自行发明密码学。

超时后，在核对前保持未知

重要请求前，创建持久的本地操作引用，绑定获批订单和请求内容。同一操作的重试不能变成新扣款，并发请求也要有本地防重复控制。每点一次换一把新键，就破坏了目的。

超时后先查询既有机构或会话引用，处理经过认证的证据。仍未知就保留状态、告知买家，并安排有退避、随机抖动、次数限制和负责人的核对。不能因请求结束就宣布失败、解除全部保障或重复发货。

Stripe幂等规则随API版本而异：v1可能重放已保存的服务器错误；键被清除后可能创建新请求。不要为避开错误盲目换键。

支付授权、扣款、商家接受订单、结算与履约是不同状态。屏幕成功或助手说“已付款”不能是唯一证据。Stripe webhook指南要求验证签名并处理重复或乱序事件。核实真实机构状态，让本地效果可安全重复处理。

保留风控与客户权限

在受支持的信任方案中，签名请求可以帮助识别调用者，却不代表商品、订单、支付接口全部放行。按要求验证签发者或密钥、受众和时效，并执行接口当前权限与限制。伪造“AI agent”请求头证明不了什么。

使用相关风控信号，不要仅凭没有鼠标移动就决定。经过验证的智能体仍需交易检查；未经验证的自动化也不自动等于欺诈。按情况拒绝、要求受支持的额外验证或引导正常授权路径。人类确认不能消除法律禁止、被盗凭证或未解决的安全失败。

状态与退货操作只限已验证买家或授权代表，以及正确账户和订单。私有库存、地址、发票与支付数据不应进入公开发现响应。设置安全限流，监控重放、频率和用一次批准创建多单的尝试。

从收据、退货到争议，都保留证据

通过买家能使用的路径确认真实订单引用、商品、总额、货币和当前状态，并提供约定的客服联系方式。合法中继邮箱并非天然无效。不要只靠助手转交收据。跟踪链接或“已发货”状态不是送达证明。

退货时，分别检查政策、法定权利、收到的商品和获准救济，再执行支付操作。Stripe退款指南区分原支付方式、退款失败与允许的替代处理。遵循已说明的异常流程，不临时向无关账户转账。

在受限访问下保存获批报价及版本、权限引用、机构引用、适用政策、沟通和履约证据。可直接使用的令牌不应作为审计附件。检查退款与争议重叠，避免双重补偿，并核对退款最终结果。

向收单行或支付机构确认实际项目中各类争议、验证、举证期限和责任条件由谁承担。签名委托可能有证据价值，但不保证赢得争议或转移所有损失。不能从营销公告推导统一责任规则。

扩大前，先试点失败路径

使用符合资格的沙箱和获准测试身份，不使用真实生产卡资料。测试66超出原60上限、批准后改车、凭证过期或撤销、卖家或币种错误、重复提交、机构成功后超时、延迟及重放事件、产品不兼容、私有状态访问，以及部分退款和争议重叠。

让操作员展示端到端记录：一次获批购买、预期支付结果、一次履约决定、可追溯的客户救济。给未知付款指定响应期限、升级与停止条件。沙箱通过不证明真实市场资格或所有发卡行行为；另向机构确认。

用明确分母和观察周期衡量获批尝试、成功扣款、未知结果、重复事件、履约错误、客服工作与退款争议。团队能够对齐订单和资金、从失败恢复后再扩大。值得承诺的是受控购买旅程，而非不惜代价的自主成交。

AI购物系列第3篇。另见购买路径与商家准备和商品发现与GEO。

审核日期：2026年11月5日。Anichur Rahaman是StoreConsole的创建者。情节及金额均为示例；支付项目条款与能力各异。