支付宝 Machine Pay：给按量服务加一道明确的付款边界

一个小型数据商按次销售企业信息查询，希望 Agent 能知道价格、取得必要授权并拿到结果，而不必先谈一份长期订阅。支付宝 Machine Pay 面向这种按量资源场景，但返回付款要求，并不等于整份服务约定已经完整。

证据边界： 2026 年 11 月 1 日核对官方公开页面。该次查阅未能取得链接中的 Machine Pay 详细接入文档，因此不推断未确认的 API 字段、退款保证或账户资格；也未执行付费调用。

标价应对应实际交付的资源

产品页把 Machine Pay 定位于 API、MCP 工具、Skill 等数字资源，介绍了基于 HTTP 402 的 A2M/A402 路径：服务方返回价格，完成并校验付款，再返回结果。

对于企业查询，报价应说明付费对象到底是什么：查到一条记录、返回“未匹配”，还是完成一次查询尝试。这是不同的商品。如果有效的无结果响应也收费，就应在付款前讲清，否则调用方可能把空结果当成未交付，不断重复购买。

依据公开产品材料绘制的按量资源流程，非实际响应。授权交互取决于具体接入方式。

自动化不能省略必要授权

官方体验示例中存在付款确认步骤，更广的 Agent Pay 说明也强调用户授权。因此，商家不能承诺接入 Machine Pay 后，所有买方第一次调用都无需参与。

需要用户操作时，应有明确等待状态，并保留原查询和报价，不能每次查状态都重新建任务。如果批准期间报价过期，要说明新价格及是否需要重新决定。这些是我们的接入建议，不是对官方参数的未经核实承诺。

HTTP 402 不是通用适配器

状态码可以告诉客户端需要付款，却不能独自定义凭证格式、验证规则、结算网络和授权交互。与 x402或 MPP比较时，应保留 Machine Pay 的 A402 具体定位。

要声称互通，需要依据当前文档核对一组明确的客户端与服务端：挑战字段、凭证如何取得、服务端如何校验、回执如何关联。返回一个 402，不足以证明支付协议已经接通。

计量和交付仍由服务方负责

需要预先处理的问题	服务方应给出的答案
付款完成，响应丢失	能否不重复付费而取回已购买结果
相同请求再次到达	哪个标识代表一次可计费查询
付款后数据源故障	按什么条款重试、补偿或退款
并发调用消耗预算	累计支出在何处执行限制

对于这项服务，建议关联输入指纹、报价版本、付款引用和结果状态，不要把不必要的敏感查询内容塞进支付元数据。客服应能核账，而不必看到超出处理问题需要的研究内容。

接入辅助不等于生产权限

开发者入口提供集成工具，产品页引导商家入驻。代码生成或沙箱演示，并不能证明商家已经完成签约和生产开通，仍要按适用的官方流程确认。

Machine Pay 在本站属于 API 按量收费，与普通购物结账及 APASS身份基础设施分开。资料页可作为核实接入条件的起点。我们的判断是，其实用价值不仅取决于首次付款是否方便，也取决于计费单位是否清楚、失败后能否正确恢复。