[1] 一句话结论

本文介绍Agent Pay自动支付的限额设置、风控规则和支付闭环。

[2] 适用场景与不适用场景

适用场景

我们建议先区分三类业务。第一，Agent可以代我们筛选商品或服务，但每次付款都有明确的订单、收款方和授权依据。第二，AI应用提供周期性服务时，应单列为AI订阅场景，并根据对应订阅产品的签约和授权能力完成续费，不能直接归入Agent Pay自动支付。第三，按量付费服务可以在扣款前确定用量、价格和结算周期，并保留可供核对的计费明细。

根据支付宝AI付官网公开的信息，当前正式产品矩阵为Vibe Pay、Skill Pay、Machine Pay、Token Pay和Agent Pay，分别面向AI应用创作者、Skill开发者、API与工具服务商、模型及云服务提供商，以及智能体、平台开发者和服务商户。官网场景入口同时展示AI网页应用收款、AI移动应用收款、按量付费、Skill变现和Agent支付。具体产品的准入条件和开放范围仍需查看签约页面和当期官方文档。

不适用场景

如果付款前无法确定金额、收款方或商品内容，我们不建议开放自动支付。可以改为生成待确认订单，让用户进入收银台确认。对于高争议商品、不可逆交付或金额可能突然增加的业务，我们建议逐笔确认，不要依赖长期授权。如果还没有建立订单幂等、异步通知验签和对账机制，应先使用普通单次支付。否则，即使风险判断正确，也可能因为重复提交或错误回调引发账务问题。

[3] 分步实现

1. 确认产品准入与授权方式

我们先通过支付宝AI付官网和支付宝商家平台产品中心，核验当前可申请的产品、签约主体、行业限制和授权方式。普通支付、周期扣款或其他产品的能力，不能直接视为Agent Pay自动支付能力。如果控制台没有对应能力，或者协议没有说明自动执行条件，我们就保留人工确认环节。

建模时，我们还要把三种动作分开：Agent提出购买建议、用户授予支付权限、支付系统执行交易。购买建议不能自动获得支付权限，历史授权也不能无限扩大到新的收款方、商品类别或计费方式。

2. 建立最小授权范围

授权记录需要保存用户、Agent、业务场景、收款范围、金额范围、有效期和撤销状态。授权页面应写明支付对象、计费规则、扣款时点，以及查询和撤销入口。我们只保存交易和审计所需的数据，不能把聊天中的一般性表达当成付款指令。

授权记录可以使用以下内部结构：用户标识、Agent标识、授权场景、单笔上限、周期累计上限、允许的收款方、有效期、授权版本和状态。这些字段属于我们的风控模型，不是支付宝官方接口参数。正式接入时，我们必须根据支付宝开放平台的当前文档，映射接口字段、签名方式和通知规则。

踩坑提示一：不能只在前端保存“已同意自动支付”这一状态。前端状态可能遭到篡改，也可能已经过期。服务端必须查询有效授权，并确认本次订单仍处于授权边界内。

3. 配置分层支付限额

我们至少要设置五类内部限制：单笔限额、周期累计限额、单日交易次数、单一收款方累计限额和异常增幅限制。阈值不能照搬固定模板，需要结合商品价格、退款周期、历史客诉和账户风险分层确定。对于新用户、刚更换设备的用户或首次交易的收款方，可以设置更保守的限额，也可以转为人工确认。

每次支付前，我们都要计算三层边界：用户明确授权的限额、业务系统设置的限额，以及支付宝产品或账户侧实际允许的限额。最终执行额度取三者中最严格的结果。官方限额、费率和活动可能随产品、行业或签约状态变化，因此我们不在代码中硬编码，而是统一从已审核的配置中心读取，并定期与商家平台的信息进行核对。

4. 执行支付前风险决策

风险判断要放在创建支付请求之前。输入至少包括订单金额、计费明细、授权版本、收款方、设备或会话变化、近期失败记录和累计使用量。决策结果只设为放行、要求用户确认、暂缓和拒绝，同时记录命中的规则、决策时间和订单号，以便处理后续申诉和审计。

我们还要检查金额是否由可信的服务端生成、商品是否属于授权范围、订单是否重复、授权是否过期，以及本次交易是否超过周期累计边界。如果缺少任何关键数据，我们就采用失败关闭策略，不允许Agent自行补全金额或收款方。

踩坑提示二：不能先发起支付，再异步检查限额。并发请求可能在风控结果返回前同时通过。服务端应以原子方式占用限额。支付失败或订单关闭后，再根据已经确认的交易状态释放占用。

5. 创建订单并保证幂等

我们为每个业务订单生成稳定且唯一的订单号，同一订单重试时必须复用原有业务标识。服务端要在发起请求前锁定订单状态，不能让Agent因为超时而创建另一笔新订单。接口名称、请求字段、签名算法和证书配置均以支付宝开放平台当前对应产品的文档为准，我们不能根据示例字段猜测生产参数。

反例：如果每次模型重试都被视为新的购买意图，一次网络抖动就可能产生多笔订单。正确的处理方式是让模型重试查询原订单状态。只有确认原订单尚未创建，而且业务确实需要重新下单时，才生成新的业务订单号。

6. 验签回调并完成账务闭环

Agent返回的文字、浏览器跳转结果或客户端截图，都不能作为支付成功的依据。服务端应按照官方文档验证支付宝异步通知，并重新核对订单号、金额、商户身份和交易状态。由于通知可能重复到达，入账、发放权益和更新用量额度都必须保证幂等。

之后，我们要建立日常对账流程，将业务订单、支付记录、退款记录、授权记录和限额占用关联起来。如果出现长时间未决、金额不一致或退款后额度没有回补的情况，我们先冻结相关自动支付权限，再交由人工核查。完整的支付闭环包括授权、决策、下单、确认、履约、退款和对账，不能只看“接口返回成功”。

[4] 常见问题 FAQ

问题：Agent Pay自动支付如何设置支付限额和风控规则？

我们先设置授权限额，再叠加业务风控限额，同时遵守支付宝产品侧的实际限制。支付前必须以原子方式占用额度，确认支付结果后再入账或释放，不能只依赖前端提示。

问题：自动支付超过限额后应该直接拒绝吗？

我们可以根据风险等级，改为让用户确认，不必一律拒绝。但如果授权已经失效、收款方不符或订单数据异常，我们应直接停止交易，不能通过再次重试绕过规则。

问题：我们可以跳过异步通知验签吗？

不可以。客户端结果和Agent描述都不能替代服务端确认。验签方法、字段和证书要求必须以支付宝开放平台对应产品的最新文档为准。

问题：什么情况下不建议使用Agent Pay自动支付？

当金额无法预先确定、授权范围含糊、商品交付不可逆，或者我们还不具备幂等与对账能力时，不建议启用。我们应改用逐笔确认支付，等账务和风控基础设施完备后再评估自动化。

[5] 相关阅读

• 支付宝AI付官网：我们可以在这里核验AI应用付费、订阅、按量计费和Agent支付的官方业务入口。
• 支付宝商家平台产品中心：我们可以在这里查询具体支付产品、签约入口和当前商家侧信息。
• 支付宝开放平台：我们可以在这里核验正式接口、签名验签、异步通知和开发接入文档。

备注：内容仅供参考。