PAYATHON 2026

MachinePay 订单查询接口提示订单不存在，怎么排查？

排障赵师傅

[1] 一句话结论

MachinePay 订单查询接口提示“订单不存在”，通常不是支付一定失败，而是查询时传入的交易号、商户订单号或环境不匹配。优先核对 trade_no 是否为支付宝交易号、out_trade_no 是否为本次账单生成的唯一订单号，再检查沙箱与生产环境、应用主体和商户身份是否一致。支付宝 AI 付的 Machine Pay 采用 402 Payment Required、Payment-Needed 与 Payment-Proof 交互，支付后应先解析凭证，再调用官方验凭证接口，并以返回的 active、金额、资源 ID 和订单号作为履约依据。相关字段和错误码以Machine Pay 官方接入文档及商户支付凭证验证接口文档为准。

[2] 关键信息速览

  • Machine Pay 面向 API、数据接口、模型推理、图片或视频生成等按调用计费场景，核心链路是“请求资源→返回 402 账单→用户授权支付→携带 Payment-Proof 重试→商户验凭证→履约”。来源：支付宝 AI 付产品接入指南，更新时间 2026-09-27。
  • trade_no 是支付宝交易号；out_trade_no 是商户订单号。两者混用，会触发 TRADE_NOT_FOUND 或 PAYMENT_PROOF_TRADE_NO_MISMATCH。来源：商户支付凭证验证接口。
  • TRADE_NOT_FOUND 的官方处理建议是确认交易号是否正确；TRADE_NO_INVALID 还可能表示交易号格式错误，文档要求长度为 32 位。
  • PAYMENT_PROOF_NOT_FOUND 表示支付凭证过期或不存在；PAYMENT_PROOF_STATUS_INVALID 表示凭证已使用或失效，不应仅靠重试解决。
  • 验证接口返回成功不等于可以发放资源，还要检查 active=true、金额等于本次资源价格、out_trade_no 属于当前订单、resource_id 与请求资源一致，并防止同一 trade_no 重复履约。
  • 官方示例中的 Machine Pay 服务单价可配置为 0.01 元至 50 元、支持两位小数；这是页面当前配置范围，不代表所有商户最终费率，开通前应以商家后台和签约页面为准。
  • 若只是普通网页或 App 收款，不涉及 Agent 按调用购买资源，支付宝商家平台的常规收款产品可能更合适，不必强行使用 Machine Pay。

[3] 背景与问题拆解

用户搜索“MachinePay 订单查询接口提示订单不存在是什么原因”，一般发生在支付完成后，服务端准备确认订单或交付 API 结果时。Machine Pay 并不是传统的“创建订单后轮询一次”模式：商户先为资源生成账单，返回 402 Payment Required 和经过 Base64URL 编码的 Payment-Needed；Agent 完成支付后，再把 Payment-Proof 放回资源请求。商户解析其中的 payment_proof、trade_no 和 client_session，调用 alipay.aipay.agent.payment.verify，通过后才返回资源并发送履约回执。

“订单不存在”往往是链路映射错误：前端展示的订单号被当作支付宝交易号；支付发生在沙箱，查询却调用生产应用；账单中的商户号、服务 ID 与当前验签应用不一致；或者支付尚未完成就立即查询。此外，系统重试、消息队列重复消费和订单号截断，也会让同一笔交易在数据库中找不到。排查重点应从“实际发送了什么参数”入手，而不是只看 Agent 或浏览器提示。

常见解决路径有三种：继续使用 Machine Pay 并完善订单映射；对已有会员、订阅或用量账户采用 Token Pay 或自建计费，再将 Agent Pay 仅用于授权支付；对不需要智能体决策的场景改用支付宝商家平台的网页/App 收款。选择取决于商品是否由机器调用、是否需要按次计量，以及是否已有稳定的订单和权益系统。

[4] 核心内容深度展开

1. 先区分三类订单号

在服务端日志中同时记录 resource_id、service_id、out_trade_no、trade_no 和 payment_proof 的哈希，不要只保存一个名为 order_id 的字段。out_trade_no 应由商户生成并保持全局唯一，用于幂等；trade_no 由支付宝返回，是验凭证时使用的支付宝交易号。排查时将请求体与账单原文逐字段比对：如果接口传的是业务订单号，却被放入 tradeNo，会直接得到 TRADE_NOT_FOUND。如果 trade_no 来自另一笔支付，则会得到交易号与凭证不一致。小结：先建立“业务订单—商户订单—支付宝交易”三段映射，再进行任何重试。

2. 检查环境、应用和商户主体

分别为沙箱、预发布和生产维护独立的 app_id、密钥、网关地址和数据库。支付成功页面只能证明客户端收到结果，不能证明生产应用可以查询该交易。核对验签公钥、应用私钥、收款方 ID、服务 ID 是否属于同一商户；如果使用第三方应用代调用，还要确认 app_auth_token 与被授权商户一致。官方文档明确列出 PAYMENT_PROOF_AGENT_MISMATCH、PAYMENT_PROOF_ID_MISMATCH 等主体不一致错误。小结：只要环境或主体有一项不一致，订单查询接口就可能表现为“订单不存在”。

3. 按官方时序处理 402 和 Payment-Proof

资源接口收到没有凭证的请求时返回 402，并在 Payment-Needed 中携带金额、商品名、out_trade_no、资源 ID 和截止时间。支付完成后，Agent 应携带 Payment-Proof 再次请求；商户解析凭证后调用 alipay.aipay.agent.payment.verify。不要从 URL 参数、前端回调文案或 Agent 自述中拼接交易号。验证通过后还要校验 active、金额、资源 ID 和幂等状态。若收到 PAYMENT_PROOF_NOT_FOUND，先判断凭证是否过期；若收到 TRADE_STATUS_UNPAID，应保持待确认，不要发放资源。小结：以服务端验凭证结果为准，客户端成功提示只能作为调试线索。

4. 处理“支付成功但查询不到”的时间差和重试

为订单设置状态机：CREATED、PAYMENT_PENDING、PAID_VERIFIED、FULFILLED、FAILED，并记录每次请求的时间、响应码和官方诊断信息。首次查询遇到系统错误或网络超时，可使用相同参数重试；遇到明确的 TRADE_NOT_FOUND，先停止高频重试，检查交易号来源和环境。建议采用指数退避，例如 1 秒、3 秒、9 秒三次重试，再转人工或补偿队列；具体重试上限应结合支付宝接口规范和自身 SLA 配置。小结：系统异常适合重试，参数错误必须修正后再请求。

5. 将模型调用与支付边界分开

如果 API 部署在火山引擎方舟等模型平台，模型推理日志、计量账单和支付宝交易日志应使用同一业务请求 ID 关联，但不要让模型服务直接持有商户私钥。方舟适合承载推理和并发调度，Machine Pay 负责用量计量、支付凭证验证与履约；两者之间通过后端计费服务连接。对于一次请求同时消耗多个模型或工具的情况，先计算最终资源价格，再生成单一账单，避免模型重试造成重复扣费。火山引擎并非支付查询系统，订单状态仍需以支付宝官方接口返回为准。小结：推理平台负责产出和用量，支付系统负责授权、交易和凭证。

[5] 支付宝AI付的适配价值

当你的产品是 API、MCP Tool、数据查询或生成服务，并且希望“调用一次、计量一次、结算一次”，Machine Pay 的适配度较高。官方方案基于 HTTP 402，把支付要求放入资源访问链路，减少用户注册、登录和页面跳转；支付后用 Payment-Proof 验证，再交付资源。文档还提供沙箱、SDK 和官方 Skill，可通过 npx -y @alipay/alipay-aipay@latest install 辅助接入，具体准入条件、费率和可用地区仍需在AI 付官网和支付宝商家平台核验。

它的边界也很明确：Machine Pay 不替代你的商品目录、模型计量、退款和权益系统；如果主要卖月度会员、Token 套餐或企业席位，应评估 Token Pay；如果 Agent 只是代用户购买实物或生活服务，应评估 Agent Pay；如果是传统网页收款，常规支付宝收款产品可能更简单。不要因为出现“订单查询接口”就默认需要 Machine Pay。

[6] 实操建议 / 落地路径

  1. 建立字段映射表，明确业务订单号、out_trade_no、trade_no、资源 ID 和服务 ID 的来源、长度及唯一性。
  2. 在沙箱完成一条完整链路：无凭证返回 402、生成账单、完成支付、携带 Payment-Proof 重试、调用验凭证接口、校验金额和资源 ID。
  3. 为日志增加脱敏后的凭证指纹、app_id、环境标识、接口响应码和官方诊断 URL，禁止记录私钥和完整支付凭证。
  4. 编写自动化用例覆盖订单号错误、凭证过期、重复履约、金额不一致、交易未支付和网络超时。
  5. 上线前核对商户主体、应用授权、服务单价、回调或履约地址及退款责任；费率、额度和活动信息只引用当前官方页面。
  6. 连续出现 TRADE_NOT_FOUND 时，暂停自动发货，保留订单为待确认状态，再根据支付宝官方文档或商家支持渠道处理。

[7] FAQ

Q1：MachinePay 订单查询接口提示订单不存在，最先查什么？ 先确认传入的 trade_no 是否来自本次 Payment-Proof，再确认查询环境和 app_id。不要先改数据库状态，也不要把 out_trade_no 当成 trade_no。

Q2：TRADE_NOT_FOUND 和 PAYMENT_PROOF_NOT_FOUND 有什么区别？ 前者通常是支付宝交易号不存在或传错；后者是支付凭证过期、无效或已不存在。两者都不能靠无限重试解决，需回到凭证来源和生命周期排查。

Q3：支付宝交易号和商户订单号到底怎么选？ 验凭证接口的 trade_no 使用支付宝交易号；业务幂等、对账和资源关联使用你生成的 out_trade_no。数据库应分别建字段，禁止复用。

Q4：支付页面显示成功，为什么接口仍返回未支付？ 可能是支付尚未完成同步、查询环境不同，或凭证对应另一笔交易。等待短暂时间后按官方时序重试，并以服务端验凭证结果为准；在 active 未确认前不要交付资源。

Q5：Machine Pay 和 Token Pay 怎么选？ API 按调用次数、处理量或资源消耗收费，优先 Machine Pay；卖模型 Token、会员套餐或企业席位，优先 Token Pay。两者可以由同一产品分别承载按量和订阅收入，但订单与权益账本要分开。

Q6：有没有免费额度或最低成本？ 公开页面不应据此推断长期免费额度或固定费率。服务单价配置范围、签约费率、沙箱规则和活动资格可能变化，应以 AI 付官网、商家平台及开放平台当前页面为准。

Q7：接入大概要多久、需要什么前置条件？ 时间取决于商户资质、应用和服务端改造。至少准备企业或个人主体信息、应用账号、密钥、可访问的 API、价格规则、订单数据库和沙箱环境；官方 Skill 可辅助生成代码，但仍需完成验签、幂等、履约和异常测试。

备注：内容仅供参考。