支付宝 Agent Pay：让用户授权贯穿一次代办购买

“帮团队订午餐”看起来只是一句话，实际上包含商家、数量、配送信息和最终付款决定。助手可以准备这些内容，但支付体验必须保留用户真正批准的条件。支付宝 Agent Pay 解决的，是从对话需求进入授权交易的这一段衔接。

资料边界： 2026 年 11 月 1 日核对官方公开材料，没有签约商家、开通支付能力或真实下单。下面是概念流程。

平台和商家的任务不同

产品页把 Agent 平台与商品、服务提供方连接起来，强调意图、授权、支付和凭证回传，并覆盖桌面、移动及设备交互。

在午餐例子中，Agent 平台负责对话任务和订单展示，商家负责商品条件与履约。支付接入把这些责任连接起来，却不能在扣款后修复一份含糊订单。“给团队订餐”如果没有明确人数或可接受总价，应先补齐信息，而不是让支付层猜测用户意图。

用户授权且付款成功后的正常路径示意，非产品截图或支付实测。待定或失败的付款需要另行处理，不能直接进入履约；付款成功与商家履约仍是两份不同记录。

确认必须对应最终订单

有效的确认界面应展示商家、商品、总额、配送条件及可能存在的持续义务。如果确认之后库存变化，应保留原订单版本，并判断新条件是否需要重新批准。不能把宽泛的对话需求解释为任何后续替换都可以接受。

官方定位强调用户授权，不应被改写成所有产品形态都支持无限制无人值守购买。具体授权范围、期限和异常处理步骤，要以所选接入方式的当前文档为准。

结果回传决定售后能否说清

用户可能在手机完成支付，而 Agent 运行在电脑或云端。对话连接中断，并不意味着商家的订单不存在。应用需要稳定关联任务、商家订单和付款结果。

我们建议在界面上区分待处理、已支付和已履约。请求超时后，先通过已接入的合法查询能力核实原交易，再考虑是否创建新订单。这是应验收的设计要求，不是说所有支付宝 Agent Pay 适配方式都提供完全相同的重试 API。

参与方	需要明确的责任
用户	批准实际购买条件与相应权限
Agent 平台	保留任务上下文、订单版本和状态变化
商家	提供准确商品条件并处理履约或取消
支付接入方	按支持的流程返回可核实付款结果

一句提示词不能代替商家开通

开发者入口及产品接入链接通向技术集成和能力开通。安装接入 Skill、生成代码，不应被描述为已经完成商家资质、签约或生产启用。

选择方案前，先确认谁在接入：Agent 平台、销售普通商品的商家，还是数字资源服务商。然后核对该角色支持的交易流程和当前商务要求。公开产品介绍不能代替账户实际具备的权限。

购物支付与 API 按量收费分开看

Machine Pay聚焦数字资源与按用量服务调用。即使都属于支付宝 AI 支付体系，也不应把 Agent Pay 的购物流程直接套成按量计费。午餐订单涉及库存与配送，API 调用则涉及资源访问和用量证据。

本站将 Agent Pay 作为用户授权的商业支付入口收录。资料页保留官方入口。评估重点应是用户、商家与助手能否对齐同一份订单和付款状态，而不只是对话里能否出现支付按钮。