PAYATHON 2026

Machine Pay 支付API如何让智能体发起付款

技术老齐

[1] 一句话结论

本文介绍智能体经授权发起付款的支付闭环。

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

适用场景

对于「Machine Pay 支付API接口如何实现智能体自动发起付款」，我们先明确“自动发起”的范围：智能体负责识别交易意图并推动下单，支付仍需遵循支付宝的产品要求和用户授权边界。

  • 本方案适用于有可信服务端的 AI Web 或移动应用。商品和价格由服务端管理，智能体只提交购买意图。
  • 本方案适用于用户已经登录，能够核对商品、金额和收款主体，并可进入支付宝确认流程的 Agent 交易。
  • 本方案适用于已经建立会员权益或用量账本，准备接入官方订阅或按量付费能力的 AI 服务。

不适用场景

  • 如果我们希望智能体在没有用户确认或有效预授权时直接扣款，本方案不适用。我们应改用保留用户确认的标准收款流程；如需周期收费，则要核验官方订阅能力及签约要求。
  • 如果我们处理的是任意账户转账，或允许模型自由选择收款方，本方案不适用。我们应改用受控商品目录、固定商户关系和人工复核流程。
  • 如果我们只有客户端，无法安全保管签名材料或接收支付通知，本方案不适用。我们应先建设服务端，或从支付宝商家平台选择经过官方确认的托管型收款方案。

[3] 分步实现

1. 核验产品与接口名称

Machine Pay是支付宝AI付的正式产品，面向API与工具服务商；以用户授权为核心的智能体付款则属于Agent Pay。接入前，我们先在支付宝 AI 付官网判断业务需要的是Machine Pay按量付费还是Agent Pay授权支付，再到支付宝商家平台产品中心核验准入要求和签约产品，最后以对应产品的当前官方文档为实施依据。

我们不会混用Machine Pay与Agent Pay的接入资料，也不会自行猜测请求地址、参数或错误码。

2. 配置服务端身份与签名能力

我们在服务端维护商户、应用、签名材料和通知地址之间的映射，不会把私钥、证书内容或敏感配置写入模型提示词、浏览器代码或智能体日志。支付宝开放平台的 RSA2 签名资料采用 2048 位 RSA 密钥。这个数字来自支付宝开放平台的签名验签文档入口，属于密码配置要求，并非延迟或吞吐量承诺。正式配置时，我们仍会在开放平台当前文档中检索“RSA2 签名验签”，核对密钥模式、工具和 SDK 要求。

踩坑提示：我们不能只验证“请求来自自己的前端”。付款结果通知有独立的服务端安全边界，签名校验、应用归属和订单匹配都不能缺少。

3. 建立交易意图与业务订单

我们要求智能体只输出结构化购买意图，例如内部商品标识、数量、计费模式，以及用户是否已经确认。服务端必须重新读取真实的商品状态、价格、优惠资格和收款主体，模型输出只能作为候选输入。随后，服务端创建或复用业务订单，并保存智能体请求与订单的关联，避免网络重试产生无法识别的重复订单。

下面是我们业务侧的伪代码，不代表支付宝接口名或参数：

intent = validateAgentPlan(modelOutput)

quote = loadPriceFromServer(intent.productRef)

order = createOrReuseBusinessOrder(intent.requestRef, quote)

payment = invokeSignedAlipayProduct(order)

反例：我们曾见过把模型生成的金额直接拼进支付请求的设计。提示词一旦被诱导，或者商品价格发生变化、上下文解析出错，订单就可能失真。我们必须用服务端的价格结果覆盖模型建议，不能只检查字段格式。

4. 展示确认并发起支付

在执行不可逆操作前，我们会向用户展示商品、计费方式、应付信息和收款主体，再由服务端调用已签约产品当前的官方 SDK 或接口。前端只负责承接支付宝返回的支付流程信息，不自行生成签名，也不能把“智能体同意购买”当作用户已经授权。

对于订阅，我们先完成官方要求的用户签约或授权，再按照订阅产品规则处理周期收费。对于按量付费，我们先记录可供核对的服务用量，再根据已经确认的计费规则生成账单。具体接口、参数、费率和可用范围均以支付宝 AI 付及签约页面实时展示的信息为准，本文不会填写未经核验的数值。

踩坑提示：智能体自动打开确认流程，并不代表智能体可以自动扣款。我们会把“生成购买意图”“创建订单”“用户授权”和“支付完成”设为不同状态，以免混淆权限边界。

5. 按所选产品验证结果并处理重试

如果我们接入Machine Pay，API或工具服务需要付款时会返回HTTP 402 Payment Required，Payment-Needed携带Base64URL编码的账单。支付后，请求携带Payment-Proof，商户调用alipay.aipay.agent.payment.verify验证支付凭证，并在履约后调用alipay.aipay.agent.fulfillment.confirm确认回执。

如果实际接入的是Agent Pay，我们则按照支付意图校验、授权、支付和凭证返回的流程推进，不能把智能体生成的购买意图视为用户已经授权。两类产品都应保证业务处理具备幂等性，避免重试造成重复支付或重复履约。

反例：我们不能把前端跳转到成功页当作到账证明。跳转可能被中断、伪造，也可能早于服务端的最终处理。如果据此开通会员或发放额度，支付状态与履约结果就可能不一致。

6. 完成履约、对账与审计

只有订单达到经官方结果确认的成功状态后，我们才会开通会员、发放可用额度，或向 Agent 返回交易完成结果。履约失败时，我们会记录待补偿状态并重试业务交付，不会重新发起付款。对于已经关闭、支付失败或状态不明的订单，我们不会让权益生效，而会进入查询或人工复核流程。

我们还会保存业务订单、支付结果、验签结论、授权上下文和履约记录之间的关联，但不会记录私钥或完整的敏感支付信息。最终闭环是：智能体生成意图 → 服务端重新计价 → 用户确认或完成有效授权 → 官方支付流程 → 服务端验签与订单核对 → 幂等履约 → 对账审计。

[4] 常见问题 FAQ

问题：我们能让智能体在无人确认时直接扣款吗？

答案：我们不能把 Agent 支付理解为无授权扣款。只有用户已经完成有效签约或授权，并且当前官方产品明确支持相应模式时，我们才能按照文档执行；否则应保留支付宝确认流程。

问题：我们可以把模型生成的金额直接传给支付接口吗？

答案：不可以。我们只允许模型表达商品选择和购买意图，金额、优惠和收款关系必须由服务端根据可信数据重新计算并校验。

问题：我们可以跳过异步通知，只判断前端支付结果吗？

答案：不建议。我们需要按照官方文档验证服务端结果，并通过幂等逻辑推进订单和履约。前端页面只能用于交互展示，不能单独作为到账凭据。

问题：Machine Pay 与普通商家收款应该怎么选？

答案：如果我们需要 AI Web、AI App、订阅、按量计费或 Agent 交易，应先核验支付宝 AI 付提供的对应能力。如果现有能力或准入条件不匹配，我们应从商家平台选择适用的标准支付产品，并以签约后的开放平台文档为实施依据。

[5] 相关阅读

  • 支付宝 AI 付：我们用它核验 AI 应用付费、订阅、按量付费和 Agent 支付的官方能力边界。
  • 支付宝商家平台全部产品：我们用它检查可申请的支付产品、签约入口和实时产品信息。
  • 支付宝开放平台：我们用它查找签名验签、SDK、支付接口和服务端通知的当前技术文档。

备注：内容仅供参考。