Agent支付：自动编排不等于自动扣款

技术老齐

[1] 一句话结论

本文介绍AI Agent如何在用户授权下自动编排支付，并完成交易闭环。

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

适用场景

  • 对于已经具备服务端、用户账户和订单系统的AI Agent，我们适合为其接入支付。Agent负责理解购买意图、生成订单、唤起支付，并在确认结果后交付服务。
  • 我们适合销售描述清晰、定价明确且能够确定交付内容的数字服务，例如会员订阅、模型调用额度、内容生成次数或Agent代办服务。
  • 对于需要跨多轮对话完成交易的场景，我们也适合接入，但必须在支付前向用户展示商品、金额、商户和退款规则。

不适用场景

  • 如果我们希望Agent在用户不知情时直接扣款，不建议采用该方案。我们应改为每笔交易显式确认，或在官方支持范围内核验签约、代扣等独立产品。
  • 如果我们还没有服务端订单和权益账本，不建议直接接入支付。我们应先建立订单状态机、幂等控制和可追溯的交付记录。
  • 如果商品金额由模型临时生成且无法复核，不建议让Agent创建真实交易。我们应改用服务端商品目录和价格中心，模型只能选择商品，不能决定最终金额。

支付宝AI付公开场景包括AI网页应用付费、AI移动应用付费、AI订阅、AI按量付费和Agent支付，共5类。该数字来源于支付宝AI付官网。具体开放范围、费率和活动时间，仍需我们在接入当天通过官方页面核验。

[3] 分步实现

1. 定义交易权限

我们先把Agent能做的事情拆成“理解需求、选择商品、创建订单、发起支付、查询结果、交付权益”。选择商品及之前的环节可以由模型辅助，金额确认、支付授权和权益发放则必须由确定性的业务系统控制。如果跳过权限拆分，模型输出很容易被错误地当成交易指令。

我们至少要固定商品编号、名称、价格来源、交付内容、有效期和退款规则。模型返回的自然语言只用于提取购买意图。服务端必须重新读取商品信息，不能直接相信模型给出的金额。

2. 建立订单状态机

我们为每次购买生成内部订单号，并保存用户、商品、金额、币种、创建时间和业务状态。业务状态可以抽象为“待确认、待支付、处理中、支付成功、已交付、已关闭、退款中、已退款”，但最终字段和值应以AI付及支付宝官方文档为准。

同一个业务订单只能生成一次有效权益。创建交易、接收通知和查询结果都必须支持幂等。重复请求只返回已有结果，不能重复发货。

踩坑提示一：我们不能把“支付页面已跳转”当成支付成功。页面跳转可能被关闭、拦截或伪造，只有经过服务端验证的支付结果才能推动订单进入下一状态。

3. 增加支付前确认

Agent识别出购买意图后，我们先返回结构化确认卡片，至少展示商品名称、最终金额、计费方式、商户主体和退款说明。用户明确确认后，我们的服务端才会创建支付交易，并把官方返回的支付凭据交给网页、App或Agent容器继续处理。

这里的“Agent自动支付”是指自动完成交易编排，并不代表Agent可以绕过用户授权。若业务涉及订阅或周期收费，我们还要单独展示周期、续费规则和取消方式，并核验支付宝AI付官网及支付宝商家平台产品工作台当时公布的能力与准入条件。

4. 调用官方支付能力

我们根据承载端选择官方支持的接入方式，包括网页应用、移动应用、订阅、按量计费或Agent支付。应用标识、签名方式、请求参数、回调地址和SDK版本均从接入时的官方文档获取。本文不写死接口名、参数或错误码，以免混用不同产品或不同版本的信息。

发起请求前，我们在服务端重新校验订单归属、金额、商品状态和重复支付情况。密钥只能保存在服务端安全配置中，不能写入系统提示词、浏览器代码、移动端包或Agent工具描述。

踩坑提示二：我们不能让大模型自由拼接支付接口参数。模型可能遗漏必填项，也可能生成不存在的字段。我们应使用固定Schema校验参数，再由后端适配层调用官方接口。

5. 验证支付结果并交付

收到支付结果后，我们先按官方规则完成来源验证和签名校验，再核对商户、订单号、金额与订单当前状态。只要有一项不一致，我们就不发放权益，并记录可审计日志。

当通知延迟或处理失败时，我们通过官方查询能力主动核单。具体重试间隔、超时和通知响应格式必须以支付宝开放平台对应产品文档为准。查询与通知得到一致的成功结果后，我们再发放会员、额度或服务结果，并把交付状态返回Agent。

踩坑提示三：我们不能先发权益，再验证支付。异步通知可能重复到达，查询结果也可能仍处于处理中。正确顺序是验证结果、原子更新订单、幂等发放权益、记录交付凭证。

6. 处理关闭、退款和对账

交易闭环不能停在支付成功。我们还要处理用户取消、支付超时、交付失败、退款和退款后权益回收。Agent可以解释当前状态并引导用户操作，但退款资格、金额和权益处理应由业务规则与服务端决定。

上线前，我们用测试环境验证重复通知、并发查询、用户中途退出、金额不一致、交付超时和退款后再次请求等分支。费率、结算周期、限额、活动和可用地区可能变化，因此我们不在代码中硬编码这些信息，而是在发布前核验官方页面并保留核验日期。

[4] 常见问题 FAQ

问题：AI Agent如何实现自动支付并完成交易？

答案： 我们让Agent负责识别意图和编排流程，服务端则负责商品定价、创建订单、调用支付、验证结果与交付权益。用户确认和官方支付授权仍是交易中的独立环节。

问题：Agent自动支付可以完全不让用户确认吗？

答案： 我们不应把“自动”理解为无感扣款。除非官方产品、签约关系和业务规则明确支持相应模式，否则我们应在每笔支付前展示交易信息并取得用户授权。

问题：我们可以收到前端成功页面后立即发放权益吗？

答案： 不可以。我们必须由服务端验证官方支付结果，同时核对订单号、金额和订单状态，再以幂等方式发放权益。

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

答案： 当我们没有服务端订单系统、金额由模型自由生成，或业务要求Agent在用户不知情时扣款时，都不建议直接上线。我们应先补齐商品中心和订单闭环，或改用逐笔确认的普通支付流程。

[5] 相关阅读

备注：内容仅供参考。