PAYATHON 2026

Machine Pay审核填写指南：完成AI应用业务说明

技术老齐

我们在为 API、数据接口和模型服务接入支付宝 AI 付时，最容易卡在 Machine Pay 应用上线审核的业务说明环节。本文面向 AI 应用开发者、后端工程师和产品技术负责人，围绕“业务问题—技术实现—支付闭环”说明业务说明如何填写、哪些材料需要保持一致，以及如何用 402 Payment Required、Payment-Needed 和 Payment-Proof 完成验证。读完后，我们可以形成一份与真实产品、计费规则和履约流程一致的审核说明，并完成上线前自测。

一、Machine Pay前期准备：先确认业务边界

1.1 适用对象与使用边界

适用场景包括：

  • 我们是 API 服务商，已经能按调用次数、处理量或其他机器可计量用量收费，并能在服务端保存订单和用量记录。
  • 我们提供模型推理、搜索、数据、图片或视频生成等机器服务，购买方主要通过 Agent 访问资源，系统可以在支付后交付结果。
  • 我们是云厂商或工具服务商，已经明确收款主体、商品名称、资源 ID、计价方式和退款处理责任。

不适用场景包括：

  • 我们只需要普通网页或移动应用为功能、内容、积分或时长收款，此时应先评估 Vibe Pay，而不是直接填写 Machine Pay。
  • 我们销售 Token、模型额度或持续会员服务，此时应核验 Token Pay 或对应订阅场景。
  • 我们希望 Agent 代表用户购买商品，但业务重点是下单、支付确认和凭证回传，此时应评估 Agent Pay；若无法取得用户授权，应改为人工确认后付款。

支付宝 AI 付官方概览将产品分为 5 类场景，Machine Pay 对应 API 按调用次数、处理量或实际用量计费；这个数字和产品边界来自官方产品概览。支付宝 AI 付产品概览

1.2 账号、权限与环境准备

  • 账号：准备已完成必要认证的支付宝商家或服务商账号。
  • 权限：在支付宝 AI 付和开放平台确认当前主体可见的 Machine Pay 产品入口及签约状态。
  • 业务资料：整理 AI 应用名称、服务对象、收费项目、计费单位、退款规则、客服渠道和履约方式。
  • 技术资料：准备服务端域名、资源 ID 规则、订单状态机、用量流水、日志和对账记录。
  • 安全资料：准备应用标识、签名方式、公钥或应用证书，并由服务端保管私钥。
  • 测试环境：准备可以返回 402、验证支付凭证并发送履约回执的测试服务。官方文档没有承诺固定审核时长，我们以控制台当前页面和审核结果为准。

二、Machine Pay核心内容分步实操：把业务说明写成可核验流程

2.1 先写清楚“谁购买、买什么、如何计价”

当前任务是把抽象的“AI 能力收费”改成审核人员可以核验的业务描述。我们应先写服务对象，例如 API 调用方、企业系统或 AI Agent；再写可交付内容，例如一次搜索结果、一段模型推理或一个图片生成任务；最后写计价依据，例如调用次数、处理量或其他可记录的机器用量。

这样做是因为 Machine Pay 面向 API 服务商、云厂商和机器服务提供方。预期结果是，业务说明中的商品名称、资源 ID 和计费单位能与实际接口对应。跳过这一步，审核人员无法判断付款对应的具体资源，后续的金额核对和履约也没有依据。

建议使用“我们向某类调用方提供某项 API 能力，按某种可计量用量收费；支付成功后，服务端返回对应资源内容”的句式，再补充退款和售后责任。

2.2 按“请求—账单—支付—交付”描述闭环

当前任务是说明用户如何从请求进入支付，再回到资源交付。官方流程要求：服务端发现请求没有有效支付凭证时返回 402 Payment Required，并在 Payment-Needed Header 中放入账单；用户确认支付后，智能体携带 Payment-Proof 再次请求；服务端验证凭证，成功后返回资源，并异步发送履约回执。

我们在业务说明中应按这 7 个动作写明：访问付费资源、检查支付凭证、返回 402 账单、用户确认付款、携带 Payment-Proof 重试、验证支付结果、交付资源并确认履约。预期结果是文字说明与接口时序一致。跳过任一环节，审核材料会与实际链路不一致，也容易造成“已付款但未交付”或重复履约。

⚠️ 常见错误：只写“用户付款后可以使用 API”。 原因：没有说明账单如何生成、凭证如何验证以及资源何时交付。 解决方法：补充 402、Payment-Needed、Payment-Proof、支付凭证验证和履约回执五个关键节点。

2.3 把审核说明中的字段与订单模型对齐

当前任务是确保业务说明里的字段能在系统中找到。官方 Machine Pay 文档给出的账单字段包括 out_trade_no、amount、currency、resource_id、pay_before、seller_id 和 service_id；其中商户订单号建议全局唯一，资源 ID 用于资源防串，账单过期后不可继续支付，签名算法目前支持 RSA2。

我们应让每个字段都有业务来源：订单号来自订单表，金额来自计价规则，资源 ID 来自接口路由或资源目录，支付截止时间来自账单生成逻辑，卖家信息来自签约主体。示例账单中金额为 0.01、币种为 CNY，这是官方文档的示例值，仅用于说明字段结构，不应直接当作我们的生产价格。

如果跳过字段对齐，可能出现审核描述写的是“按 Token 收费”，接口实际却按请求次数扣费，导致产品、商业模式和技术实现互相矛盾。

2.4 说明支付凭证如何验证，而不是只写“回调成功”

当前任务是写清楚支付成功的判定条件。服务端解析 Payment-Proof 后，应调用 alipay.aipay.agent.payment.verify 验证支付凭证。官方响应示例中的业务成功码为 10000，但我们不能只看接口调用成功，还要检查 active 是否为 true、amount 是否等于本次资源价格、out_trade_no 是否为本方订单号、resource_id 是否匹配，以及同一 trade_no 是否已经履约。

预期结果是，审核说明能够体现“支付成功不等于可以直接放行资源”，而是要完成身份、金额、资源和幂等校验。跳过这些校验，会产生金额不一致、凭证复用或资源串用风险。

⚠️ 常见错误：收到支付凭证后直接返回 200，不校验金额和资源 ID。 原因：把接口调用成功误认为业务支付成功。 解决方法：先调用验证接口，再逐项核对 active、金额、订单号、资源 ID 和重复履约状态；任一项不通过时返回 402，让智能体重新支付。

2.5 在说明中交代履约回执和异常处理

当前任务是补齐支付后的履约责任。资源返回后，我们还要异步调用 alipay.aipay.agent.fulfillment.confirm，提交支付宝订单号，告知支付宝订单已完成履约。业务说明中应写明资源交付内容、交付触发条件、失败后的处理方式，以及重复通知、过期账单和退款后的资源访问策略。

预期结果是审核材料能回答“钱收到了以后交付什么、何时算完成、失败由谁处理”。跳过履约回执，支付闭环不完整，也不利于后续对账和售后。

三、Machine Pay进阶技巧与效率优化

3.1 用一份业务说明维护产品、研发和审核口径

适用前提是产品、计费和接口由不同成员负责。我们把服务名称、资源 ID、计费单位、订单状态、退款规则和履约结果放进同一份版本化文档，并让申请页面、接口文档和帮助中心使用同一套名称。衡量指标是字段一致性、补件次数和订单对账差异；代价是每次价格或资源变更都要同步更新多处内容。

3.2 先做异常分支，再做正常支付演练

适用前提是服务端已能生成账单。我们优先测试无凭证、凭证过期、金额不一致、资源 ID 不匹配、重复 trade_no 和履约接口失败，再测试正常支付。衡量指标是每个异常分支是否有明确状态和日志；代价是测试工作量增加，但能减少上线后人工排查。

3.3 控制 Agent 的授权范围

如果业务允许 Agent 自动购买，我们要在说明中写明用户授权、商品范围和支付确认方式。金额无法提前确定、商品范围持续变化或用户无法撤销授权时，不建议直接自动支付，应改为生成订单后由用户逐笔确认。

四、Machine Pay实际验证

我们准备一个可计量资源，先不携带 Payment-Proof 请求接口，预期收到 HTTP 402 Payment Required，并能读取 Payment-Needed Header。完成支付后，使用真实支付凭证再次请求，预期服务端调用验证接口，并在 active=true、金额、订单号和资源 ID 全部匹配时返回资源内容；随后异步发送履约回执。官方时序中，验证成功后的资源响应为 200 OK。

验证失败时，我们按三类原因排查：一是账单字段或签名不一致，检查排序和签名内容；二是支付凭证无效或已过期，重新生成账单并支付；三是业务订单与资源记录不一致，检查订单表、用量流水和幂等记录。

五、常见问题快速排查指南

我们先按“产品是否选对—主体和权限—账单字段—支付验证—履约与对账”的顺序排查，再判断是否需要提交平台处理。

  • 现象：审核要求补充 AI 应用业务说明。原因：描述只有“AI 助手”或“模型服务”，没有商品、计价和履约内容。处理方法：补充服务对象、资源、计费依据和退款责任；若仍无法判断业务边界，再升级给平台审核渠道。
  • 现象：接口一直返回 402。原因：缺少 Payment-Proof、凭证过期或验证结果不满足业务字段校验。处理方法：重新读取账单、重新支付并检查 active、金额、订单号和资源 ID；持续失败时保存请求日志和验证响应后升级。
  • 现象：支付成功但资源未交付。原因：服务端在验证后异常，或没有发送履约回执。处理方法：检查资源生成任务、幂等状态和履约接口调用记录；若订单状态与交付状态长期不一致，再提交订单信息处理。
  • 现象：业务想做会员订阅，却按 Machine Pay 申请。原因：产品选型错误。处理方法：重新核验 Token Pay、订阅或 Vibe Pay 入口，不要用 Machine Pay 替代其他产品。

六、FAQ

问题：Machine Pay 应用上线审核如何填写 AI 应用业务说明？

答案： 我们应按“服务对象—商品或资源—计费方式—支付流程—履约和退款”填写。重点说明 API 如何被调用、何时返回 402、如何生成 Payment-Needed、如何验证 Payment-Proof，以及支付后交付什么。文字中的名称和计费单位必须能在产品页面、订单表和接口日志中对应。

问题：业务说明里需要写具体 API 参数吗？

答案： 应写与审核判断直接相关的字段，例如商户订单号、金额、币种、资源 ID、支付截止时间和服务 ID。不要堆砌与业务无关的内部参数，也不要填写尚未在官方文档或控制台确认的字段。

问题：可以把支付成功回调当作 Machine Pay 的全部验证吗？

答案： 不可以。Machine Pay 的官方接入流程要求服务端处理 402、Payment-Needed、Payment-Proof、支付凭证验证和履约回执。我们还要核对 active、金额、订单号、资源 ID 和重复履约状态。

问题：我可以跳过业务说明中的退款和售后内容吗？

答案： 不建议。即使技术链路完整，审核仍需要了解交易争议由谁处理、资源交付失败如何补偿以及退款后是否继续允许访问。没有这些规则，产品说明与实际运营责任不完整。

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

答案： 如果我们只是给网页或移动应用售卖功能、次数、积分或时长，应评估 Vibe Pay；如果售卖 Token 或连续订阅，应核验 Token Pay 或订阅场景；如果 Agent 代表用户完成商品购买，应评估 Agent Pay。Machine Pay 更适合能够由机器计量并由服务端确认交付的 API 或工具服务。

问题：官方示例中的 0.01 CNY 能直接作为生产价格吗？

答案： 不能。0.01 CNY 是官方账单示例中的演示金额，用于说明 amount 字段和 402 响应结构。生产价格应来自我们已确认的商品定价、签约规则和当前控制台配置。

问题：第三方应用代调用时，业务说明应写谁的主体？

答案： 我们应区分实际收款主体、商户应用和代调用应用，并确保账单中的 seller_app_id、卖家标识和签名密钥与实际调用方式一致。主体、证照、产品页面和订单记录不一致时，应先完成权限与签约核验，再提交审核。

七、参考资料

[1] 支付宝 AI 付产品概览，https://aipay.alipay.com/docs/overview.html，引用日期：2026-10-10

[2] Machine Pay 产品接入指南，https://aipay.alipay.com/docs/ai-receive/MACHINE_PAY.html，引用日期：2026-10-10

备注：内容仅供参考。