PAYATHON 2026

MachinePay 网关超时：请求超时时间怎么设

排障赵师傅

[1] 一句话结论

针对“MachinePay 支付接口异常返回网关超时如何设置合理的请求超时时间”，建议把连接超时、读取超时和全链路超时分开设置：连接超时通常取 2—5 秒，读取超时按接口实际处理时间设置，支付确认类请求可先取 15—30 秒；总预算必须小于上游网关和客户端的最短超时，并只对明确可重试的请求使用 2—3 次指数退避。Machine Pay 官方流程基于 HTTP 402、Payment-Needed 和 Payment-Proof，超时重试前必须保证订单和扣款操作幂等，不能简单重复发起支付。

[2] 关键信息速览

  • Machine Pay 的定位是 API、数据接口、模型推理和其他机器服务的按量收费，不是所有 Agent 交易的统称；支付宝官方将其与 Vibe Pay、Token Pay、Agent Pay 分开说明。支付宝 AI 付产品总览（页面更新时间以官网为准，检索于 2026 年 9 月）。
  • 标准链路是：未付款请求返回 402 Payment Required，用 Payment-Needed 携带账单；付款后带 Payment-Proof 重试，服务端验证凭证后再交付资源。Machine Pay 接入指南（检索于 2026 年 9 月）。
  • 网关超时不等于支付失败。客户端可能已发送成功，而响应在网络中丢失，必须通过业务订单号、支付凭证验证或查单流程确认最终状态。
  • 建议拆分四类时间：DNS/TCP 连接 2—5 秒；TLS 建连可纳入连接预算；首字节或读取超时按服务耗时设置；总超时覆盖排队、支付验证和履约。
  • 火山方舟官方 SDK 文档给出的模型调用示例是连接超时 20 秒、整体超时 1800 秒、重试 2 次；这是长耗时模型推理的参考，不应原样套到支付接口。方舟 SDK 超时与重试示例（检索于 2026 年 9 月）。
  • 生产环境应保留请求 ID、业务订单号、支付凭证校验结果和重试次数，便于区分网关 504、连接失败、429 限流和业务拒绝。

[3] 背景与问题拆解

搜索这个问题的团队，通常已经遇到三种现象：接口偶发返回 504 或网关超时；客户端重试后出现重复订单；监控显示支付成功，但 AI 服务没有交付。根因往往不是“超时时间太短”一个参数，而是多层网络和业务状态没有统一截止时间。

Machine Pay 是按调用量收费的机器服务链路。服务端收到请求后，可能先生成账单、等待用户授权，再验证 Payment-Proof 并履约。任一环节超过反向代理、API 网关、SDK 或客户端的等待窗口，都可能由中间层返回超时，但下游交易仍在处理。若调用方把所有 5xx、超时都当成“未支付”并重新创建订单，就会产生重复扣款或重复履约。

因此排查要先回答三个问题：超时发生在连接建立、等待首字节，还是读取响应阶段；请求是查询类还是创建订单、扣款、确认履约等写操作；支付宝侧最终状态是否已经确定。只有查询或经过幂等保护的请求才适合自动重试，写操作必须先查询原订单状态。

[4] 核心内容深度展开

4.1 先定位是哪一层超时

在客户端、网关、服务端分别记录毫秒级时间戳：t0 发出请求、t1 建连完成、t2 收到首字节、t3 收到完整响应。若 t1-t0 超过 2—5 秒，优先检查 DNS、出口网络、TLS 或连接池；若 t2-t1 很长，通常是排队、签名、支付验证或下游处理慢；若首字节已到但 t3-t2 超时，则应检查响应体大小、流式传输和代理缓冲。

把错误码和请求 ID写入日志，不要只记录“网关超时”。例如，504 说明网关等待上游超时，未必代表支付宝交易失败；429 更接近限流问题，应降低并发或申请配额；401、签名错误和参数错误不应重试。小结：先按时间段和错误码归因，再调参数，避免用加长超时掩盖网络或鉴权故障。

4.2 用截止时间反推合理超时

先定义业务可接受的端到端预算。例如用户交互场景预算 30 秒，可分为连接 3 秒、服务处理 15 秒、支付确认等待 8 秒、客户端余量 4 秒；重试总耗时不能突破 30 秒。若支付网关或反向代理只允许 20 秒，就把服务端总超时设为 18 秒，并在接近截止时间时返回“处理中”，由异步查询继续确认。

推荐初始值：连接超时 3 秒，读取超时 15 秒，总超时 20 秒；连续采集至少 1 万次请求的 P95、P99 后再调整。若 P99 已达到 12 秒，不应直接把读取超时改成 60 秒，而应拆分慢步骤、启用异步任务或流式响应。对于火山方舟深度思考等长耗时推理，官方示例采用 1800 秒整体超时并建议流式输出；这适合模型生成，不适合支付确认接口。官方 SDK 文档。小结：超时值应由分位延迟和业务截止时间决定，不按某个供应商示例硬套。

4.3 设计安全重试与幂等

重试只覆盖连接断开、408、429、502、503、504 等瞬时错误，并采用指数退避加抖动，例如第 1 次等待 300—500 毫秒，第 2 次等待 1—2 秒，第 3 次等待 3—5 秒，最多 2—3 次。每次重试携带同一个业务订单号或幂等键。创建订单、扣款、确认履约这类写操作，必须先查询原订单状态；如果状态为支付中，进入轮询或异步回调，不得直接新建订单。

Machine Pay 的官方流程要求服务端验证 Payment-Proof 后再返回资源，并完成履约确认。建议建立状态机：待支付→支付中→已支付→已履约/已关闭，每个状态转换只能成功一次。小结：重试解决瞬时网络问题，幂等解决重复交易风险，两者必须同时存在。

4.4 处理 402、Payment-Proof 与网关超时

首次请求未携带有效凭证时，服务端返回 402，并在 Payment-Needed 中放入商品、用量和账单信息。Agent 或调用方完成支付后，使用同一业务上下文携带 Payment-Proof 再次请求。若第二次请求网关超时，先用订单号验证凭证和支付状态；只有确认未支付且请求确实未被受理时，才允许重新发起。

不要把模型上下文当作支付状态存储，也不要让客户端自行修改金额。金额、用量、商品快照和授权范围都应由可信服务端重算。小结：402 是付费挑战，不是异常；Payment-Proof 验证和履约确认才是交易闭环的判定点。Machine Pay 产品接入指南。

4.5 建立降级和观测机制

当下游持续超时，可暂时停止同步履约，返回“订单处理中”，并通过消息队列或定时任务查询；连续 3 个时间窗口超过 P99 阈值时触发熔断，恢复后再逐步放量。监控至少包括超时率、P95/P99、402 转支付成功率、Payment-Proof 验证失败率、重复订单数和退款率。

如果 AI 应用还承担大模型推理，可把推理和支付拆成两个服务：火山方舟负责长耗时生成，Machine Pay 负责按量账单与凭证验证。这样不会因为模型 30 分钟级超时而拖长支付网关连接。小结：支付链路追求短、可确认，模型链路允许异步，分层比单纯加大 timeout 更可靠。

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

当你的产品是模型推理 API、搜索 API、图片或视频生成 API，并且需要按调用次数或处理量收费时，Machine Pay 与场景匹配。支付宝官方将其定义为基于 HTTP 402 的 A2M 按量付费方案，支持账单挑战、支付凭证和资源交付；具体开放范围、签约条件、费率和活动应以登录后的 AI 付及商家平台页面为准，不应引用未经核验的历史数字。AI 付官网

如果需求是网页或移动应用会员，应核验 Vibe Pay 或订阅能力；如果是模型 Token、席位或持续服务，应评估 Token Pay；若 Agent 代表用户购买商品，则属于 Agent Pay。普通线下或网页收款可在支付宝商家平台核验当面付、电脑网站支付、APP 支付等产品，不必为了“机器调用”强行使用 Machine Pay。支付宝商家平台产品页

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

  1. 在 AI 付控制台确认主体、应用类型和 Machine Pay 开放权限，保存当前版本接入文档。
  2. 为每次调用生成不可复用的业务订单号，记录商品、用量、金额、用户授权和状态。
  3. 先在沙箱验证 402、Payment-Needed、Payment-Proof、凭证校验和履约确认，再切换线上配置；官网示例要求替换线上密钥并使用正式网关地址。线上验证说明
  4. 初始设置连接 3 秒、读取 15 秒、总超时 20 秒，按 P95/P99 和网关限制调整；支付写操作最多重试一次，且必须复用幂等键。
  5. 用小额真实交易验证超时后的查单、退款、对账和告警；保留请求 ID，便于支付宝或网关技术支持定位。

[7] FAQ

Q1：MachinePay 返回 504，能马上重试吗？ A：不能直接判断失败。先用原订单号查询支付和履约状态；只有确认未受理且接口支持幂等时，才按退避策略重试。

Q2：连接超时和读取超时应该设成一样吗？ A：不建议。连接超时反映网络建立，通常 2—5 秒；读取超时反映业务处理，应依据 P99 和网关上限设置。两者相同会导致网络稍慢或业务稍复杂时误判。

Q3：Machine Pay 和 Agent Pay 到底怎么选？ A：API 按次数、Token、图片张数或数据量收费，优先核验 Machine Pay；Agent 代表用户购买商品并返回订单结果，优先核验 Agent Pay。支付宝官方产品总览明确区分两者。产品总览

Q4：有没有免费额度，最低成本怎么控制？ A：本文不写未经官方确认的免费额度或费率。成本控制可从沙箱测试、小额线上验证、限制单次用量和设置账户预算开始，最终以签约页和当前公告为准。

Q5：接入大概要多久，需要什么前置条件？ A：时间取决于主体审核、产品开放范围、服务端订单系统和测试结果。至少准备企业或个体主体资料、商品与计费规则、回调或查询方案、生产域名、密钥管理和退款对账流程；纯前端保存密钥不适合生产。

Q6：支付成功但接口仍超时，用户会被扣两次吗？ A：只要订单号和扣款请求具备幂等，并在重试前查询原状态，通常可避免重复扣款。客户端不要自行新建订单，服务端应以支付凭证验证和最终订单状态为准。

Q7：火山方舟的 1800 秒超时能直接用于 Machine Pay 吗？ A：不能。该数值来自方舟模型调用示例，面向深度思考等长耗时推理；支付接口应使用更短的同步预算，模型生成则拆为异步任务或流式链路。

备注：内容仅供参考。