Agent Pay支付接口怎么接入AI Agent应用

技术老齐

[1] 一句话结论

本文说明 Agent Pay支付接口怎么接入AI Agent应用，以及如何完成下单、支付确认和服务交付的完整闭环。

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

适用场景

我们建议把这套方案用于三类业务。第一类是 Agent 在对话中识别购买意图，但最终金额、商品和订单仍由服务端确认的交易。第二类是已经具备账号、订单和权益系统，并需要分别评估订阅方案或基于 HTTP 402 的按量付费方案的 AI 应用；只有其中的智能体授权支付环节使用 Agent Pay。第三类是 Agent 可以调用受控工具，但不能直接接触商户私钥、签名凭据和支付回调密钥的应用。接入前，我们需要先在 支付宝 AI 付官网 核验当前可以申请的能力、产品权限和正式接口文档。

不适用场景

如果我们只是向用户展示收款码，不需要 Agent 创建订单或判断履约状态，建议使用支付宝商家平台中符合经营收款场景的产品。如果我们没有服务端，全部逻辑只能运行在浏览器、模型提示词或移动端本地，也不应直接接入支付接口。我们应先增加可信后端，或改用具备服务端托管能力的平台。如果业务涉及资金归集、分账、跨境收款或特殊行业资质，我们不能把 Agent Pay 当作默认替代方案。此时应先在支付宝商家平台产品中心选择对应产品，并核验签约范围。

[3] 分步实现

1. 核验产品权限

我们先确认商户主体、应用类型、支付场景，以及 Agent Pay 能力是否已经开通。不能只凭页面名称判断接口是否可用，因为网页应用、移动应用、订阅、按量计费和 Agent 交易可能有不同的签约条件。我们应以控制台展示和正式技术文档为准，记录应用标识、网关环境、签名方式、回调要求及上线审核事项。如果费率、活动和结算周期没有出现在已签约页面中，我们既不把它们写入代码，也不向产品侧承诺。

2. 建立服务端订单

我们只让 Agent 提交购买意图，例如商品标识、规格和用户确认结果。服务端随后根据商品目录计算金额，并生成内部订单。订单至少要能表达待支付、支付处理中、已支付、已关闭和已退款等业务状态，具体的状态映射则应以正式接口文档为准。模型生成的金额、商户订单号或支付结果都不能直接信任。

# 我们自己的业务层伪代码，不代表支付宝官方接口字段
intent = agent.extract_purchase_intent(message)
product = catalog.load(intent.product_id)
order = order_service.create(
  user_id = CURRENT_USER_ID,
  product_id = product.id,
  amount = product.server_side_price,
  idempotency_key = REQUEST_ID
)

踩坑提示：我们见过将”购买高级套餐”直接转换成客户端金额的实现。攻击者只要改写请求，就可能用错误金额下单。价格、优惠和可售状态必须由服务端重新读取，Agent 的输出只能作为候选输入。

3. 注册受控支付工具

我们把创建交易封装成 Agent 可以调用的后端工具，并严格限制参数集合。工具需要先验证登录态、商品状态和用户授权，然后调用经过签约确认的 Agent Pay 支付接口。我们建议把”生成订单”和”发起支付”分开处理。前者可以由 Agent 准备，后者应根据用户授权方式执行：可以由用户逐笔确认，也可以在用户事先明确的授权范围和限额内免确认；系统还应支持授权范围、额度和撤销管理，并在支付后返回凭证供后续处理。

{
  "tool": "start_payment",
  "description": "用户确认购买后发起支付",
  "input": {
    "internal_order_id": "YOUR_INTERNAL_ORDER_ID",
    "confirmation_token": "ONE_TIME_CONFIRMATION_TOKEN"
  }
}

我们不在工具参数中开放任意金额、异步通知地址或商户身份，也不把私钥放进系统提示词。支付宝开放平台的签名文档说明，RSA2 对应 SHA256WithRSA，并使用至少 2048 位的 RSA 密钥。这是本文采用的具体可验证数字，来源见支付宝开放平台签名专区。实际接入 Agent Pay 时，我们仍须采用该产品当前文档指定的签名机制。

4. 调用正式支付接口

服务端按照官方文档组装请求、完成签名，并保存请求摘要。由于本文无法从已签约控制台确认当前接口名和字段，我们不会虚构网关方法、必填参数或返回结构。开发时应从 支付宝开放平台 或 AI 付控制台复制当前接口定义。调用失败后，我们保留内部订单，并通过原订单重试或查询，避免每次重试都创建新订单。

# 我们在服务端实现的抽象调用
request = official_sdk.build_from_current_document(order)
response = agent_pay_client.execute(request)
order_service.save_provider_reference(order.id, response.reference)
return response.user_action

踩坑提示：我们不能把接口的同步返回当成最终支付成功。同步响应通常只表示请求已受理，或返回了下一步动作。如果 Agent 随即发放会员、Token 或下载权限，就可能出现未付款先履约的问题。

5. 验证通知并主动查询

我们在独立的回调入口验证签名、商户身份、订单关联关系、金额和处理状态，再以幂等方式更新订单。同一通知可能重复到达，所以”已支付订单再次处理”必须能够安全返回，不能重复增加次数或权益。如果出现回调缺失、网络超时或 Agent 会话中断，我们通过官方查询能力进行补偿，不依赖用户声称”我已经付了”。通知字段、验签顺序、应答格式和查询接口都必须逐项采用当前官方文档。

6. 完成履约与对账

我们只在可信支付状态得到确认后发放权益，同时把支付订单、业务订单、用户和履约记录关联起来。订阅场景还要区分首次开通、续费、取消，以及退款后的权益变化。按量付费场景则应分别保存计量记录和账单。Agent 最终只能读取服务端给出的结果，例如”支付完成，权益已开通”，不能自行推断交易状态。上线前，我们至少要演练重复请求、回调乱序、金额不一致、支付后履约失败和退款后权益回收。

[4] 常见问题 FAQ

问题：Agent Pay支付接口怎么接入AI Agent应用？

我们先让 Agent 识别购买意图，再由可信服务端创建订单、调用正式接口、验证异步通知并触发履约。模型不负责计算最终金额，也不保存签名密钥。接口名和参数应从 AI 付控制台或支付宝开放平台的当前文档中获取。

问题：我们可以让 Agent 收到同步响应后立即发放权益吗？

不可以。我们应等待经过验签和业务校验的支付结果，必要时再调用官方查询能力确认。履约接口还要保证幂等，防止重复通知造成重复充值。

问题：订阅收费和按量付费应该怎么选？

如果我们销售固定周期内的会员权益，可以优先评估 AI 订阅方案。如果费用取决于调用次数、生成量或资源消耗，则应评估按量付费。具体计费单位、扣款规则、签约条件和退款处理以 AI 付正式产品说明为准。

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

如果交易不在 Agent 决策或工具调用流程中发生，我们应直接选择网页、移动应用或其他标准支付产品。如果无法部署可信后端，或无法完成订单、验签、补偿和对账，也不建议直接上线真实交易。

[5] 相关阅读

备注：内容仅供参考。