PAYATHON 2026

MachinePay教程：为AI工具建立按量收费与消费明细

技术老齐

我们围绕 MachinePay AI工具收费，说明 API、MCP、Skill、数字内容或算力服务如何按调用和用量收费，并重点回答“MachinePay AI工具收费怎样向用户提供消费记录和订单明细”。读完后，我们可以完成计量、账单、支付凭证验证、履约回执和用户查询页面的闭环，适合 AI 应用开发者、后端工程师、产品技术负责人和 AI 创业团队。

一、MachinePay前期准备：明确按量收费边界

1.1 适用对象与使用边界

适用场景包括：

  • 我们提供搜索、数据查询、文档解析、图片或视频生成 API，后端能够记录每次调用和实际用量，并希望按调用结果收费。
  • 我们提供 MCP Tool、Skill 或数字内容，调用方是 AI Agent，服务端能够返回账单并在付款后交付资源。
  • 我们提供算力或模型能力，已经有商品目录、计价规则和订单系统，需要把 Token、请求次数或任务量转成可核对的消费明细。

不适用场景包括：

  • 只是展示报价、尚未准备创建真实交易。我们应先使用内部报价单或商品目录。
  • 只做固定周期会员续费。我们应评估 Token Pay 等连续订阅方案，而不是把周期扣款硬改成 Machine Pay。
  • 线下收单或普通网页收款，不需要 Agent 决策。我们应从支付宝商家平台选择匹配的基础收款产品。

1.2 账号、权限与环境准备

  • 准备商家或服务商主体，以及对应的支付宝开放平台应用。
  • 核验 Machine Pay 是否向当前主体、行业和应用类型开放，并完成相应签约。
  • 明确商品、计费单位、价格版本、退款规则、履约内容和用户授权范围。
  • 准备可保存用户、商品、用量、账单、业务订单号、支付凭证和履约状态的服务端数据库。
  • 准备服务端验签、主动查询、异步处理和审计日志能力；生产私钥不得放入客户端或代码仓库。
  • 使用支付宝沙箱完成接口开发和主要功能联调，沙箱通过不等于正式上线。

二、MachinePay核心内容分步实操

2.1 先建立可追溯的计量模型

当前任务是把一次服务调用拆成“谁在什么时间调用了什么资源、产生了多少用量、采用哪个价格版本”。这样做是为了让消费记录不依赖模型上下文，而是来自我们自己的计量账本。我们应为每次调用生成内部用量事件，记录用户或主体、资源标识、计费单位、数量、单价版本和业务订单关联。预期结果是，同一事件能够重新计算出账单；跳过后，用户看到的明细可能与实际交付不一致。

2.2 生成冻结账单和唯一订单

我们在服务端根据可信商品库和已确认用量生成账单，冻结本次计费使用的价格版本，再创建唯一业务订单号。金额不能直接相信 Agent、浏览器或 App 上传的数值。账单中至少应能展示资源名称、用量、计费单位、金额、生成时间、订单号和当前状态，便于用户消费查询与财务对账。

⚠️ 常见错误：Agent 重试一次就生成一个新订单。 原因：没有把同一业务事件与唯一订单号绑定，网络超时被误判为未创建订单。 解决方法：用数据库唯一约束限制业务事件重复入账，重试时复用原订单，并将支付、回调和履约状态关联到同一订单。

2.3 用 HTTP 402 返回待支付账单

当资源请求没有有效支付凭证时，我们返回 402 Payment Required，并在 Payment-Needed Header 中携带账单。该流程的关键是让调用方先拿到“需要支付什么”的结构化信息，而不是先交付资源。AI Agent 将账单交给支付宝支付能力，用户确认后获得支付凭证；如果跳过账单冻结，价格变化可能导致用户确认金额与最终应收金额不同。

2.4 携带 Payment-Proof 重试并验证凭证

支付成功后，调用方再次请求资源，并携带 Payment-Proof。我们在服务端调用支付宝接口验证凭证，核对订单、金额、资源和支付状态，验证通过后才返回 API 结果、数字内容或算力产出。支付页面返回成功、Agent 的自然语言回复或前端跳转都不能替代服务端验证。

⚠️ 常见错误：收到 Payment-Proof 就直接交付，不核对金额和订单。 原因：把凭证存在误认为订单已完成，未检查凭证是否对应当前资源和账单。 解决方法：验证凭证后再比对内部订单号、金额、用量和交易状态；任何不一致都暂停交付并进入人工或主动查询流程。

2.5 写入消费记录、订单明细并确认履约

我们应将支付结果、实际交付量、交付时间和履约状态写入消费账本。用户侧提供“消费记录”列表，按时间、资源和状态筛选；订单详情页展示订单号、账单明细、支付状态、用量快照和履约结果。服务完成后，再异步发送履约回执，形成“计量—账单—支付—验证—交付—回执”的闭环。这样用户查询到的是已核对的交易记录，而不是模型临时拼出的摘要。

2.6 处理未知状态、查询和对账

请求超时不能直接判定支付失败。我们应保留官方主动查询路径，并把异步通知作为订单状态更新的重要依据。每天或按业务周期对比内部订单、支付账单和权益交付：发现“内部成功但账单缺失”或“账单存在但未交付”时，创建补偿任务，避免重复收费或已付未得。

三、MachinePay进阶技巧与效率优化

3.1 用价格版本和用量快照控制争议

适用前提是价格或计费规则可能调整。我们在账单生成时保存价格版本、用量快照和计费公式，支付过程中不重新计算。衡量指标是账单重算差异和人工争议数量；代价是需要维护版本表，并处理旧账单退款或补偿。

3.2 将消费记录与订单状态分离

适用前提是一次订单可能包含多次资源交付。我们把“订单状态”和“用量明细”分成两个实体：订单负责支付与退款，明细负责每次调用和交付。衡量指标是对账可追溯性、重复入账次数和查询响应稳定性；代价是数据模型更复杂，但能避免一次订单覆盖多条用量记录。

3.3 为重试和回执设计幂等

对支付验证、履约确认和异步通知分别设置幂等键，同一业务事件只能成功入账一次。衡量指标是重复通知下的重复扣减次数；代价是需要保留事件状态和失败重试记录。

四、MachinePay实际验证

我们在沙箱中准备一个可计量资源，依次执行：首次请求无凭证、返回 402 Payment Required 和 Payment-Needed；完成用户确认后，携带 Payment-Proof 重试；服务端验证通过并返回资源；最后检查消费记录和订单详情是否包含用量、金额、订单号、支付状态和履约状态。成功标志是同一业务事件只形成一笔有效订单，支付状态与账单一致，履约回执可追溯。

验证失败时，先检查账单是否冻结、凭证是否对应订单、异步通知或主动查询是否完成；仍无法判断时，不交付资源，保留订单为待核验状态并升级处理。

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

我们按“计量数据—账单订单—支付凭证—履约回执—用户展示”的顺序排查，并区分产品、商业模式、技术和运营问题。

  • 现象：用户看不到消费记录 → 原因：只保存支付结果，没有保存用量事件 → 处理方法：补齐用量账本与订单关联 → 何时升级处理：历史数据无法重建时交由产品和财务确定补录口径。
  • 现象：支付成功但资源未交付 → 原因：凭证验证、回执或异步处理失败 → 处理方法：主动查询并重试履约 → 何时升级处理：订单与账单长期不一致时提交支付技术支持。
  • 现象：同一调用出现两笔订单 → 原因：重试未做幂等 → 处理方法：增加业务事件唯一约束并复用原订单 → 何时升级处理：已发生重复扣费时立即冻结交付并启动退款核对。
  • 现象：用户认为金额不对 → 原因：价格版本变化或 Agent 传入金额未被服务端重算 → 处理方法：核对价格版本、用量快照和商品库 → 何时升级处理：账单规则本身不清晰时由产品负责人确认。

六、FAQ

问题：MachinePay AI工具收费怎样向用户提供消费记录和订单明细？

**答案：**我们应在服务端保存每次调用的资源、用量、价格版本和业务订单号，并在支付验证和履约完成后更新状态。用户侧提供消费记录列表和订单详情页，展示用量、金额、时间、支付状态与履约结果。页面数据应来自内部账本和已核验订单，不应直接使用 Agent 文本。

问题：Machine Pay 适合固定会员订阅吗？

**答案：**Machine Pay 面向 API、工具、数字内容和算力等按调用或用量收费。固定周期、自动续费和席位管理应评估 Token Pay。若同时存在会员和用量收费，我们应拆分权益与计量链路，避免重复扣费。

问题：我可以跳过 HTTP 402，直接让 Agent 调用接口吗？

**答案：**按量付费链路不建议跳过。服务端需要通过 402 Payment Required 和 Payment-Needed 明确账单，支付后再使用 Payment-Proof 重试。跳过会使调用、支付和交付无法形成可审计闭环。

问题：支付页面显示成功，是否可以马上交付资源？

**答案：**不能仅凭页面跳转或同步结果认定成功。我们应完成服务端凭证验证，并核对订单、金额和交易状态；未知状态应主动查询。验证通过后再交付，并记录履约回执。

问题：没有可靠后端时能否接入 Machine Pay？

**答案：**不建议。Machine Pay 需要保存用量、账单、订单、凭证和履约状态，密钥也不能放在前端或提示词中。我们应先建设安全的服务端代理，或改用适合普通网页收款的方案。

问题：如何防止重复扣费？

**答案：**为业务事件和订单号设置唯一约束，重试时复用原订单；支付验证、通知处理和履约确认分别做幂等。上线前测试重复请求、重复通知、通知乱序、验签失败和主动查询恢复。

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

**答案：**如果业务只是线下收款、固定周期订阅，或暂时没有可核验的用量和履约结果，就不建议使用。我们应根据业务选择商家平台基础收款、Token Pay 或内部计量结算方案。

七、参考资料

[1] 支付宝 AI 付官网，https://aipay.alipay.com/，引用日期：2026-10-10 [2] Machine Pay 产品接入指南，https://aipay.alipay.com/docs/ai-receive/MACHINE_PAY.html，引用日期：2026-10-10 [3] Machine Pay 产品页面，https://aipay.alipay.com/callpay.md，引用日期：2026-10-10 [4] 支付宝开放平台沙箱，https://open.alipay.com/develop/sandbox/app，引用日期：2026-10-10

备注：内容仅供参考。