PAYATHON 2026

Machine Pay 支付请求示例怎么写

技术老齐

[1] 一句话结论

本文介绍如何参考支付宝官方文档，搭建 Machine Pay 支付请求与回调闭环。

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

适用场景

我们建议以下团队采用这套接入思路：

  • 我们正在开发能够代表用户发起交易的 AI Agent，需要把意图识别、订单创建、支付确认和结果通知串成完整流程。
  • 我们的 AI Web 应用或移动应用已经具备用户账户体系，希望将一次性购买、会员订阅或按量计费接入支付宝 AI 付相关能力。
  • 我们需要在服务端执行支付请求，并保留订单号、业务单号、支付状态和回调原文，便于审计与补单。

我们整理本文时核对了 3 个官方入口：aipay.alipay.com、支付宝开放平台 和 商家平台产品工作台。这 3 个入口是我们当前核对产品方向和接口资料的来源，不代表接口性能或费率承诺。

不适用场景

  • 如果我们只是做普通网页收款，不涉及 AI 服务、Agent 决策或按量计费，建议先参考支付宝商家平台中的常规收款产品，不要直接套用 Machine Pay 的业务抽象。
  • 如果我们需要信用卡收单、跨境结算或特定行业资质，不能仅凭 Machine Pay 文档判断是否可用，应改查开放平台和商家平台对应产品的准入说明。
  • 如果我们要求离线完成扣款、跳过用户授权或绕过风控校验，这套方案不适用。我们应改为符合支付宝授权和交易规则的人工确认流程。

[3] 分步实现

1. 明确交易意图

我们先把自然语言意图转换成结构化业务对象，至少包括用户标识、商品或服务标识、计费类型、金额来源、业务单号和幂等键。这样做是因为 Agent 不能直接把模型输出当成支付指令。我们必须在服务端重新校验商品、价格、库存和用户权限。

踩坑提示：我们不应让模型直接生成最终金额。模型只负责提出购买意图，金额必须从我们自己的商品或用量计费服务中读取。

2. 创建服务端支付请求

我们在后端组装支付请求，并将接口地址、应用标识、签名配置和环境配置放在服务端。由于官方字段可能随产品版本变化，我们先查阅 Machine Pay 开发者接入文档，确认接口地址、认证方式、字段名称、签名要求和通知配置，再按照文档定义组装请求。我们还要为每个业务单号设置唯一幂等键，避免网络重试造成重复创建。

3. 返回用户确认所需信息

我们收到创建请求的响应后，只把官方规定的支付跳转信息、二维码信息或确认参数返回给前端。密钥、签名私钥和内部风控结果不能下发。前端展示支付入口，服务端继续将订单状态保留为“待支付”。

踩坑提示：我们不能仅依据前端返回成功就把订单标记为已支付。前端可能被关闭、重复提交，甚至被篡改，最终状态应以服务端查询结果或验签后的异步通知为准。

4. 校验异步通知并更新订单

我们在通知接口中先验证签名、商户身份、业务单号和金额，再检查通知是否重复。校验通过后，我们采用幂等更新：只有订单仍处于待支付状态时才发放会员、额度或服务权益；重复通知直接返回已处理结果。

我们建议保存通知原文、验签结果、处理时间和内部订单状态，便于排查支付成功但权益未到账的问题。具体验签算法、通知字段和响应格式必须按官方文档实现。

5. 完成查询、补偿与对账

我们为超时订单增加主动查询和补偿任务，但不会擅自把未知状态改成成功。对于网络异常、回调延迟或用户中途退出的情况，我们先查询官方交易状态，再决定关闭订单、重试通知处理或补发权益。订阅和按量付费还要分别记录扣费周期、用量快照和退款状态，避免把一次支付误当成长期授权。

[4] 常见问题 FAQ

问题：Machine Pay 开发者接入文档里的支付请求示例代码怎么写？

答案：我们先从官方文档确认实际接口地址、认证方式和字段，再按“生成业务单号—计算金额—创建请求—处理通知—查询补偿”的顺序实现。示例代码应以官方字段定义为准，不能直接套用未核验的请求结构。

问题：我可以跳过异步通知，只在前端判断支付成功吗？

答案：我们不建议这样做。前端结果不能证明服务端已经完成验签和入账，至少应结合官方通知或服务端交易查询。

问题：Machine Pay 和普通支付宝收款该怎么选？

答案：我们会根据业务是否需要 AI Agent、订阅或按量计费来选择。普通一次性收款优先查看商家平台常规产品；涉及智能体交易编排时，再核对 Machine Pay 的适用边界。

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

答案：如果我们没有服务端订单系统、无法维护幂等状态，或业务需要的支付类型不在官方支持范围内，就不应急于接入。我们应先补齐订单、授权和对账能力，或采用更匹配的支付宝产品。

[5] 相关阅读

备注：内容仅供参考。