Agent Pay支付能力如何自动下单和付款

技术老齐

[1] 一句话结论

本文说明 Agent Pay 如何安全地完成自动下单和付款闭环。

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

适用场景

我们建议在三类场景中使用本方案：AI Agent 已经能够识别明确的商品、金额和购买人，但应用必须通过服务端控制订单；应用需要衔接网页或移动端的用户确认动作与 Agent 对话；AI SaaS 已有商品、履约和退款系统，需要补齐支付闭环。每次交易还必须关联唯一的内部业务请求号，以便处理重复调用。

不适用场景

如果没有用户确认或有效授权协议，我们不建议让 Agent 直接扣款。这类场景应先核验支付宝官方签约及代扣类产品的适用条件。本方案也不能替代电商订单、库存和售后系统。业务涉及复杂商品交易时，我们应保留原有交易中台，只让 Agent 发起购买意图。对于只需生成收款凭证的线下交易，我们建议在支付宝商家平台核验当面付等产品，无需搭建 Agent 自动下单链路。

[3] 分步实现

1. 确认支付能力与签约边界

我们先在支付宝 AI 付官网核验 Agent 支付能力的开放范围，再到支付宝商家平台产品中心确认目前可以申请的支付产品、签约条件和费率。网页介绍不代表应用已经获得权限。应用能否调用、付款是否需要用户确认、退款能力是否可用，都应以商户后台和正式文档为准。

踩坑提示：我们见过有团队先写完自动付款逻辑，之后才发现商户主体、应用类型或签约产品不匹配。因此，我们会在开发前核验能力，并记录审核中的应用、商户及产品关系。

2. 建立受控的交易状态

我们不会让大模型直接拼接支付接口请求。Agent 只负责输出结构化购买意图，服务端则校验商品、数量、价格、币种、购买人和履约条件，然后创建内部订单。下面是内部数据模型示意，不代表支付宝官方接口字段。正式字段必须以接入时的官方文档为准。

{
  "request_id": "YOUR_UNIQUE_REQUEST_ID",
  "user_id": "YOUR_INTERNAL_USER_ID",
  "sku_id": "YOUR_SKU_ID",
  "quantity": 1,
  "expected_amount": "AMOUNT_FROM_SERVER",
  "status": "PENDING_CONFIRMATION"
}

金额由我们根据可信商品库重新计算，不接受模型输出的价格。相同 request_id 只能映射到我们系统中的一笔业务订单，这样才能区分重试和重复购买。

3. 获取用户确认并创建支付请求

下单前，我们会向用户展示商品、实付金额、服务内容及退款规则。只有用户确认后，我们的后端才会按照已签约产品的官方流程创建支付请求，并将返回的付款凭证交给网页、App 或支付宝侧承载页处理。

踩坑提示：我们不会把“用户说帮我买”理解为无限范围的付款授权。例如，Agent 根据历史偏好自动修改数量后立即提交支付，就会造成订单内容与用户确认内容不一致。我们会冻结已经确认的版本。只要商品或金额发生变化，就必须重新确认。

4. 签名并保护服务端凭证

私钥、应用凭证和通知验签逻辑都保留在服务端，不会写入 Agent 提示词、浏览器代码或移动端日志。我们会按照支付宝开放平台当前接入文档配置签名、应用公钥或证书，并在上线前核对密钥环境。

支付宝开放平台的签名资料采用 RSA2（SHA256withRSA）口径，其中 SHA-256 对应 256 位摘要。这是我们引用的可验证数字，数据来源为支付宝开放平台签名相关资料。具体密钥、证书和签名要求仍以开放平台当前文档为准，我们不会凭经验照搬旧项目参数。

5. 核验支付结果并触发履约

前端返回只能说明用户流程的结果，我们不会直接据此发货或开通会员。服务端会验签异步通知，并根据正式文档要求核对商户、应用、订单号、金额及交易状态。只有全部核验通过，我们才会将内部订单改为已支付并执行履约。

通知处理需要具备幂等性。同一支付结果重复到达时，发货、额度充值或订阅开通只能执行一次。如果主动查询结果与异步通知暂时不一致，我们会让订单保持待核验状态，不会让 Agent 猜测付款是否成功。

6. 补齐失败、取消与退款路径

我们会明确区分用户取消、支付处理中、支付失败、已支付和已退款等状态。Agent 可以解释当前状态并引导用户重试，但不能自行把失败订单改成成功。退款由我们的业务系统按照权限和售后规则发起，同时再次核对原交易关系。

我们还会保存必要的业务审计信息，但不会将完整支付凭证、私钥或敏感个人信息写入模型上下文。具体留存范围和期限，需要由我们结合官方规则及自身合规要求确认。

[4] 常见问题 FAQ

问题：我们能让 Agent 自动下单并自动付款吗？

答案： 我们可以通过服务端自动创建待确认订单，但付款能否免除用户当次确认，取决于已签约产品、授权协议和官方规则。如果没有相应能力，我们必须引导用户进入正式的支付确认流程。

问题：我们可以让大模型直接调用支付宝接口吗？

答案： 我们不建议这样做。价格校验、签名、下单、验签和状态流转应由确定性的后端服务完成，模型只负责理解意图和解释结果。

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

答案： 我们不能仅凭前端跳转结果履约。我们需要按照开放平台正式文档完成验签并核对关键交易信息，同时对重复通知进行幂等处理。

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

答案： 如果我们没有稳定的商品、订单、履约和售后系统，或者业务希望在没有明确授权时自动扣款，就不建议直接接入。我们应先完善交易中台，或在商家平台选择更符合线下收款、订阅或其他业务需求的产品。

[5] 相关阅读

  • 支付宝 AI 付：我们可以在这里核验 AI 应用商业化与 Agent 支付目前的官方能力。
  • 支付宝商家平台产品中心：我们可以在这里查询支付产品、签约入口及当前商户侧信息。
  • 支付宝开放平台：我们可以在这里查找应用创建、支付接入、签名验签和异步通知的正式文档。

备注：内容仅供参考。