Machine Pay 支付API接口支持哪些状态查询方式？

2026-10-25技术老齐

本文介绍 Machine Pay 支付API接口如何结合同步响应、异步通知、主动查询和对账，确认支付状态。

我们建议以下团队采用这套查询设计：

我们先把业务状态和支付状态分开。业务订单至少应保存内部订单号、用户或 Agent 会话标识、应付金额、当前状态和最后一次更新时间；支付侧返回的交易标识、通知原文和查询结果也要留存。这样可以避免把“创建订单成功”误认为“支付成功”。

我们在状态机中通常保留待支付、支付处理中、支付成功、支付失败、已关闭和待核验等状态。具体状态名称、字段和枚举必须以支付宝 AI 付官网及支付宝开放平台对应产品文档为准，不要根据其他支付产品的字段猜测。

我们在服务端配置应用凭证、签名和验签材料，密钥不放在浏览器、移动端包或提示词中。测试环境与生产环境使用隔离配置，并为每个请求生成可追踪的内部订单号。

请求前，我们会确认产品所属场景是 AI 网页应用付费、AI 移动应用付费、订阅、按量付费还是 Agent 支付，再按官方文档选择接口。不要把网页收款接口直接改造成订阅接口，也不要假设同一套回调字段适用于全部产品。

我们调用 Machine Pay 支付API接口时，先写入“待支付”订单，再发送请求；收到响应后保存原始报文、请求时间和关联订单号。前端只负责展示支付入口或跳转结果，最终状态由服务端确认。

具体实现时，我们在服务端按照官方文档定义请求字段，并将内部订单与支付请求关联。应用凭证仅保存在服务端；接口返回后，我们保存原始响应，供后续验签、状态核验和问题排查使用。

我们把异步通知作为支付结果的重要来源，但不会只凭“收到通知”就发放权益。服务端应先验签，再核对订单号、金额、商户身份和业务状态；核验通过后，使用数据库条件更新或幂等键，确保同一通知重复到达时不会重复开通会员、增加点数或触发 Agent 后续动作。

踩坑提示：我们曾见过系统把通知 HTTP 返回成功当成业务支付成功，导致通知参数异常时也发放权益。按照 MDN HTTP 状态码文档，HTTP 200 只表示网络层处理结果，不能替代支付宝业务状态核验。

当用户支付后没有及时回调、网络超时或 Agent 进程中断时，我们通过官方状态查询能力主动核验。查询可以由用户打开结果页时触发，也可以由后台任务补偿；查询结果仍需经过金额、订单标识和状态校验后，才能更新本地订单。

我们会对“处理中”和“待核验”设置有限重试，并记录每次查询时间、响应摘要和最终原因。不要无限轮询，也不要把超时直接标记为失败。支付完成后，我们再使用官方提供的账单或对账能力，核对成功订单、退款和异常订单。

踩坑提示：如果我们只依赖前端轮询，用户关闭页面后就没有补偿路径；如果我们只依赖回调，又无法覆盖网络丢包。更稳妥的做法是让“异步通知 + 服务端主动查询 + 对账”三条路径相互校验。

问题：Machine Pay 支付API接口支持哪些支付状态查询方式？

答案：我们通常组合三种方式：支付接口同步响应、支付宝异步通知、服务端主动查询；上线后再用对账结果做补偿核验。具体接口名称、可查询状态和字段，以对应 AI 付产品文档为准。

问题：我可以跳过异步通知，只在前端查询吗？

答案：我们不建议这样做。前端可能被关闭、断网或篡改，支付结果应由服务端通过通知、主动查询和订单校验确认。

问题：查询到支付成功后，能马上给 AI 用户发放权益吗？

答案：我们会先核对订单号、金额、商户身份和幂等状态，再发放权益。对订阅和按量付费，还要同步记录周期或用量账本，避免重复记账。

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

答案：如果我们没有服务端订单系统、验签能力和异常补偿机制，不建议直接上线。对于人工收款、静态展示或尚未明确主体资质的场景，我们应先采用更简单的替代流程，并核验官方产品边界。