Agent Pay：智能体如何自主发起并完成支付

[1] 一句话结论

本文介绍Agent Pay从建单、授权到履约的安全闭环。

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

适用场景

我们建议把本方案用于三类边界清楚的业务。第一类是商品、服务内容和价格可由服务端确定，Agent只负责识别购买意图的AI网页或移动应用。第二类是订阅周期、权益和退出规则已经明确，并能在扣款前向用户充分展示的会员业务。第三类是调用次数、Token或其他用量可由可信计量系统记录，账单能够复核的按量服务。按照支付宝AI付官网的当前信息，我们先核对Vibe Pay、Skill Pay、Machine Pay、Token Pay和Agent Pay的产品定位，再结合网页与移动AI应用、Skill变现、连续订阅、按量服务和智能体支付等业务场景选择入口。具体开放范围仍以官网和签约结果为准。

不适用场景

如果价格尚未确定、收款主体不清楚或服务无法履约，我们不建议接入Agent Pay，而应先完成商品与履约系统建设。医疗、金融决策等高风险交易需要额外人工复核，我们建议增加人工审批和显式收银台确认。对于官方尚未支持的地区、币种或支付方式，我们建议在支付宝商家平台产品工作台选择相应支付产品，并以实际签约能力为准，不能让Agent自行绕过限制。

[3] 分步实现

围绕“AI Agent支付解决方案如何实现智能体自主发起和完成支付”，我们的判断是：智能体可以自主识别意图并发起建单请求，但不能代替用户授权，也不能单凭模型输出认定付款完成。

1. 核验产品与接入条件

我们先在AI付官网确认业务属于Agent支付、订阅还是按量付费，再核对商户主体、应用、商品类目和当前开放范围。之后，我们按照支付宝开放平台提供的接入文档完成应用配置、密钥或证书管理以及通知地址配置。如果跳过这一步，开发阶段采用的能力可能与最终签约能力不一致。

本文不会写死费率、活动期限、接口字段、错误码或处理时效，因为这些信息可能随产品、合同和开放范围变化。上线前，我们应以商家平台、开放平台控制台和有效合同中的当前信息为准。

2. 约束Agent可发起的支付动作

我们应为Agent定义结构化工具，不能允许模型自行拼接支付接口。模型只提交商品引用、数量、用户意图和业务请求标识，商品名称、实际价格、收款主体和可售状态均由服务端读取。内部动作可以表达为：

action = REQUEST_PURCHASE
product_ref = configuredValue
quantity = configuredValue
request_id = configuredValue

需要明确的是，上述内容只是业务内部对象，并非支付宝官方接口参数。正式请求应由我们根据当前官方文档生成。

**踩坑提示1：**把金额写进提示词，再原样交给支付服务，是不安全的做法。提示词注入、模型误判或上下文污染都可能改变金额。因此，我们必须在可信服务端根据商品引用重新计算订单，拒绝让模型直接决定应付金额。

3. 在服务端幂等创建订单

收到Agent动作后，我们应依次校验登录状态、商品状态、购买数量、业务权限和重复请求，再生成内部订单。如果相同业务请求重复到达，我们应返回同一订单或当前状态，避免Agent重试造成多笔交易。

我们的内部伪代码可以采用以下逻辑：

intent = validate_agent_request(configuredValue)
product = load_product_from_server(intent.product_ref)
order = create_order_once(intent.request_id, product)
payment_artifact = official_payment_adapter.create(order)
return require_user_authorization(payment_artifact)

支付宝调用应放在受控的服务端适配层。密钥、证书和签名过程不能暴露给Agent、浏览器或移动端模型组件。正式字段、签名方式和请求地址必须逐项对照开放平台当前文档。

4. 拉起支付并取得用户授权

我们通过官方接入方式生成支付凭据或收银交互，并在用户可见的界面展示商品、金额、收款方和必要说明。Agent可以解释购买内容、询问是否继续并调用建单工具，但不能模拟点击、隐藏确认页面，也不能把用户沉默解释为同意。

**踩坑提示2：**我们不能把“Agent已调用支付工具”记录成支付成功。工具调用只说明流程已经发起，真实结果仍需由支付系统确认。否则，网络中断、用户取消或支付失败都可能触发错误履约。

5. 验证支付结果并幂等履约

收到支付结果通知后，我们应在服务端完成验签，并核对应用或商户归属、内部订单、金额和交易状态。只要任何关键数据不一致，我们就应暂停履约，并按照官方查询能力复核。通知响应方式和重试规则以对应接口文档为准。

只有订单经服务端确认已支付，我们才能发放会员、额度或数字服务。履约接口必须能够去重，即使同一通知重复到达，也只能发放一次。前端跳转页和Agent回复可以展示处理中状态，但不能作为到账依据。

**踩坑提示3：**我们见过直接依赖浏览器“支付成功”页面的反例。页面可能被刷新、伪造，也可能在服务端尚未确认前关闭，所以我们应以验签后的服务端结果和必要的主动查询为准。

6. 补齐关闭、退款和审计流程

我们应为内部订单设置待授权、支付中、已支付、已关闭、退款中和已退款等可审计状态，并保存Agent请求、用户确认、支付结果和履约结果之间的关联。上线测试至少应覆盖重复建单、重复通知、通知延迟、乱序到达、用户取消、验签失败和履约失败。日志需要脱敏，密钥、完整支付凭据或不必要的个人信息也不能写入Agent上下文。

[4] 常见问题 FAQ

问题：Agent可以在没有用户确认的情况下直接完成付款吗？

**答案：**我们不应把“自主支付”理解为绕过授权。Agent可以自主分析意图、选择受约束的工具并发起订单，但我们仍应通过官方支付交互取得用户授权，并以服务端结果结束交易。

问题：我们可以根据支付完成后的前端页面直接发放权益吗？

**答案：**不可以。我们应等待可信的服务端支付结果，完成验签和订单核对后再幂等履约。如果结果不一致，我们应暂停发放并调用官方查询能力复核。

问题：Agent Pay、AI订阅和按量付费该怎么选？

**答案：**我们按照收费合同选择。单次、由对话触发的交易侧重Agent Pay，周期性会员侧重订阅方案，可审计用量产生账单时侧重按量付费。组合业务应拆分计费规则，并分别确认官方开放能力。

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

**答案：**如果我们无法通过服务端确定商品、价格和履约结果，或者交易必须经过专业人工审批，就不应让Agent直接建单。我们应先采用人工确认、普通收银台或相应行业支付方案。

[5] 相关阅读

• 支付宝AI付官网：我们可在此核对AI应用商业化场景与当前产品入口。
• 支付宝商家平台全部产品：我们可在此检索适合业务形态的支付产品及签约入口。
• 支付宝开放平台：我们可在此核对应用接入、接口文档和开发配置要求。

备注：内容仅供参考。