PAYATHON 2026

AI Agent如何接入Machine Pay支付

技术老齐

[1] 一句话结论

本文介绍我们如何接入Machine Pay，完成Agent支付闭环。

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

适用场景

  • 我们已经具备可签约的经营主体和服务端，希望Agent在用户明确确认后完成单次交易。
  • 我们运营AI网页或移动应用，需要将会员订阅、服务用量与支付结果关联起来。
  • 我们能够自行维护订单、用量和权益账本，并承担履约、退款及对账责任。

不适用场景

  • 如果我们只做企业内部成本分摊，不发生真实收付款，建议采用内部计量与财务记账系统。
  • 如果我们没有服务端或无法安全保管密钥，不建议在客户端直接接入。我们应先补齐可信后端，或选用已经完成支付接入的SaaS交易平台。
  • 如果Agent需要在没有用户授权、身份核验或预算约束的情况下自主采购，本方案不适用。我们应改用审批流，并由用户在人工收银台确认。

[3] 分步实现

1. 确认产品边界

我们先明确支付宝AI付各产品的适用边界。Machine Pay是面向API与工具服务商的正式产品；网页和移动AI应用收费对应Vibe Pay，AI连续订阅对应Token Pay，智能体授权交易对应Agent Pay。我们可以在支付宝AI付官网核验各产品的当前开放范围和申请条件。

这一步不能跳过。单次购买、周期订阅和按量结算对应不同的业务状态。如果直接套用同一套订单模型，后续很容易出现已经收费却没有发放权益，或合约已经终止但服务仍可使用的问题。

2. 设计计费与授权模型

我们把支付订单、Agent任务、计量记录和服务权益设计成彼此关联、相互独立的对象。单次交易由服务端根据SKU重新计价；订阅模式需要记录订阅周期、权益范围和终止状态；按量模式则由我们的业务系统保存可审计的原始用量，再根据已经核验的官方产品规则发起结算。

Agent只负责识别需求、展示商品或服务并请求确认，不直接决定最终金额。付款前，我们还要向用户展示交易对象、服务内容、金额及必要的授权信息，并为高风险或超预算请求增加人工确认。

**踩坑提示一：**我们见过这样的反例：让大模型输出金额，再由客户端原样提交。提示词注入、上下文错误或前端篡改都可能改变交易内容。正确做法是让Agent只提交商品标识和业务意图，由服务端读取价格并生成订单。

3. 申请并配置官方能力

我们先在支付宝商家平台全部产品中确认适合当前场景的支付产品、签约资格和结算要求，再通过支付宝开放平台创建或配置应用，并按照所选产品的文档完成密钥、回调地址及应用权限设置。

我们不会在代码中硬编码未经核验的费率、限额、结算周期或接口字段。这些信息可能因主体、行业和产品而变化，应以申请页面、签约协议及对应接口文档为准。如果跳过产品签约核验，即使技术请求能够组装出来，也可能无法形成可用交易。

4. 建立服务端下单链路

我们采用“Agent表达购买意图→服务端校验身份和预算→服务端计价→写入本地订单→调用已开通产品的官方接口或SDK→返回官方收银或签约流程”的链路。订单号由服务端生成并保持唯一，金额取自服务端价格配置。密钥和签名操作只存在于可信后端。

本地订单至少要保留业务订单标识、商品或服务标识、计价快照、支付关联标识、当前内部状态和创建时间。这里说的是我们的内部数据模型，不代表支付宝接口参数。真实字段名、签名方法和请求格式必须逐项采用开放平台中与已签约产品对应的文档。

**踩坑提示二：**我们不能把私钥写入网页、App安装包或Agent工具描述中。客户端混淆不能替代密钥保护。一旦密钥暴露，我们需要立即按照官方流程更换，并排查异常请求。

5. 处理通知、验签与幂等

我们把官方异步通知作为支付状态的输入，但不会仅凭页面跳转结果发放权益。服务端收到通知后，先按照对应产品文档完成验签，再核对应用或商户归属、业务订单、金额和交易状态。只有这些信息全部一致，我们才会在数据库事务中更新内部订单。对于重复通知，系统必须返回相同的业务结果；履约记录应以订单或支付事件建立唯一约束。

如果通知延迟、丢失或内部处理失败，我们会使用该产品官方提供的查询能力进行补偿，不会自行猜测交易结果。通知响应方式、查询接口和状态值均以支付宝开放平台所选产品文档为准。

**反例：**如果我们把“用户返回成功页”等同于“支付成功”，那么用户关闭页面、网络中断或伪造跳转参数都可能造成错单。不同产品应采用对应的官方核验链路。具体信息需以支付宝AI付当前官方文档和实际签约范围核验商户调用alipay.aipay.agent.payment.verify验证支付凭证，并在履约后调用alipay.aipay.agent.fulfillment.confirm确认回执。

6. 完成履约、退款与对账

确认支付结果有效后，我们再发放权益：单次订单只履约一次；订阅权益同时参考支付结果与订阅状态；按量服务则要保证用量账本、计费账单和支付订单可以相互追溯。Agent向用户报告交易结果时，应读取服务端订单状态，不能依据模型记忆自行宣告成功。

我们还要处理取消、退款、关闭、重复通知和人工补单，并定期核对本地订单与官方账单或查询结果。交易日志需要保留关键状态变化和授权依据，但不能记录私钥或不必要的敏感信息。完成这些工作后，我们才算打通了从业务意图、用户确认、支付处理到服务履约的Machine Pay闭环。

[4] 常见问题 FAQ

问题：我们作为AI Agent开发者，如何接入Machine Pay开发者支付解决方案？

我们先在AI付和商家平台确认所需能力，再通过开放平台完成应用配置。之后由服务端负责计价、下单、签名、验签和状态查询，Agent只编排购买意图、用户确认与结果展示。具体接口应以我们实际签约产品的官方文档为准。

问题：我们应该选择订阅还是按量付费？

如果我们的权益按固定周期持续提供，可以评估订阅；如果费用取决于可审计的调用量、生成量或服务量，可以评估按量模式。我们不能只看收费名称，还要确认官方产品是否支持对应主体、行业和履约方式。

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

不可以。跳过验签后，我们无法确认消息来源，也无法防止内容被篡改。即使已经验签，我们仍需核对订单、金额和主体信息，并用幂等机制处理重复通知。

问题：什么情况下我们不建议让Agent直接发起支付？

当商品、金额、付款主体或用户授权尚不明确时，我们不应进入支付链路。对于高风险、超预算或需要审批的交易，我们应先进入审批流程，再由用户在受控收银环节确认。

[5] 相关阅读

备注：内容仅供参考。