PAYATHON 2026

AI按量付费教程：核对用量与扣款账单

技术老齐

我们把 AI按量付费理解为“每次调用都能独立计价，并由服务端完成支付与履约校验”的技术流程。本文面向 AI 应用开发者、后端工程师和 SaaS 技术负责人，覆盖计量建账、HTTP 402 交互、Payment-Proof 验证、履约回执和对账。读完后，我们可以搭建一条可追溯的 AI按用量自动扣费功能，并核对实际用量与扣款账单。

一、AI按量付费前期准备：建立可核对的计量基础

1.1 适用对象与使用边界

适用场景：

  • 我们提供 API、MCP 或 Skill 服务，调用方主要是 AI Agent，且后端能够为每次请求生成唯一记录并复算价格。
  • 我们提供数字内容或算力资源，不同用户消耗差异较大，希望按调用或实际用量收费，而不是统一包月。
  • 我们的 AI 服务能够保存业务订单、计量账本和履约状态，并可以在用户授权后处理支付凭证。

不适用场景：

  • 我们只有浏览器端、没有可信服务端，无法保管密钥或校验订单；应先增加服务端，或改用官方托管收款流程。
  • 我们无法稳定记录 Token、调用次数或任务结果；应先采用固定套餐或预付额度，待计量规则可复算后再启用按量付费。
  • 我们的需求是按月、按年或按席位持续收费；应评估支付宝 AI 付的连续订阅入口，而不是用 Machine Pay 模拟周期扣费。

1.2 账号、权限与环境准备

  • 我们准备已完成主体核验的支付宝商家账号，并确认当前主体、行业和应用类型具备 Machine Pay 接入条件。
  • 我们在支付宝 AI 付产品页确认产品入口，在开放平台准备应用、服务端密钥和必要的权限配置。
  • 我们建立计量账本，至少保存业务订单号、请求标识、计量单位、数量、计价规则版本、应付金额和履约状态。
  • 我们准备服务端运行环境、日志和密钥管理系统；私钥不放入前端、移动安装包、提示词、日志或代码仓库。
  • 我们先使用支付宝沙箱完成接口开发和主要功能联调，再按正式商户凭证进行上线验收。官方资料未规定统一 SDK 版本和固定耗时，我们不预设版本或工期。

二、AI按量付费核心内容分步实操

2.1 先定义计量单位与账单快照

当前任务是把一次 API 调用转成可审计的用量记录。我们先确定按调用、Token、内容数量或算力资源计量，并为每条记录绑定业务订单号和请求标识。这样做是为了让“实际用量—应付金额—支付凭证”可以一一追溯。预期结果是每次待收费请求都有冻结的账单快照；如果跳过，调价或重试后可能出现历史金额被重新计算的问题。

⚠️ 常见错误：支付完成后才按最新价格重新计算历史订单。 原因：没有保存计价规则版本和支付前账单快照。 解决方法：在返回账单前固定计量数量、计价规则和应付金额，对账时只使用该快照。

2.2 未付款请求返回 HTTP 402

当前任务是让调用方知道资源需要付款。我们在服务端发现请求没有有效支付凭证时，返回 HTTP 402 Payment Required，并在 Payment-Needed 中携带本次请求对应的账单；该状态码就是按量付费流程中的可验证数字。我们还要保证账单与请求标识关联，避免同一请求生成多份无关账单。预期结果是 Agent 能拿到明确账单并进入支付；若跳过，调用方无法按 Machine Pay 协议判断下一步。

2.3 支付后携带 Payment-Proof 重试

当前任务是让支付结果回到原始业务请求。用户确认支付后，调用方携带 Payment-Proof 重新请求同一资源。我们服务端要先识别重试请求，并用请求标识和业务订单号做幂等判断。预期结果是支付凭证与原账单保持对应；若把客户端页面显示成功当作交付信号，网络重试或伪造请求可能导致未付款交付。

⚠️ 常见错误：看到“已拉起支付”或前端成功页面就直接返回 API 结果。 原因：把展示层状态当成可信支付凭证。 解决方法：只接受带 Payment-Proof 的服务端请求，并继续执行凭证验证、金额和订单核对。

2.4 调用凭证验证接口

当前任务是确认 Payment-Proof 确实对应本次账单。我们在商户服务端调用支付宝官方的 alipay.aipay.agent.payment.verify，核对账单、交易主体、金额、业务订单号和请求标识。验证通过后，才把订单推进到可履约状态；验证失败则保留原始请求和错误日志，不交付资源。若跳过这一步，任何客户端或 Agent 自述都可能被误认为付款成功。

2.5 履约后确认回执

当前任务是把“已付款”与“已交付”分开记录。我们先执行 API、内容或算力服务，写入成功、失败、部分完成或可重试状态，履约完成后调用 alipay.aipay.agent.fulfillment.confirm 确认回执。这样我们能区分已支付未履约和已履约未确认；若跳过，后续补偿和退款无法判断服务是否已经交付。

2.6 建立三账关联并核对

当前任务是实现 AI按用量自动扣费功能如何核对实际用量与扣款账单。我们用业务订单号关联计量账、支付账和履约账，按账单快照逐笔比对数量、计价版本和金额，再检查是否存在重复请求、重复凭证、退款后仍可使用等异常。普通异步通知或主动查单可以作为辅助，但不能替代 HTTP 402、Payment-Needed、Payment-Proof、凭证验证和履约确认组成的链路。

三、AI按量付费进阶技巧与效率优化

3.1 用幂等键控制重试

适用前提是客户端或 Agent 可能重复提交同一请求。我们以业务订单号和请求标识作为幂等依据，在凭证验证、资源交付和履约确认前先查询已有状态。衡量指标是重复请求是否只产生一条计量记录和一次交付；代价是需要保留状态表和原始请求日志。

3.2 用计价版本保护历史账单

适用前提是模型、工具或资源价格会调整。我们在生成 Payment-Needed 时保存计价规则版本、数量和金额，之后对账只引用该版本，不回读当前价格。衡量指标是历史账单能否复算；代价是需要维护版本并在运营侧解释版本变化。

3.3 设置失败与补偿路径

适用前提是支付成功后可能出现服务超时或部分完成。我们把支付、计量、履约拆成独立状态，针对“已支付未履约”“已履约未确认”“已用量未出账”建立幂等补偿任务。衡量指标是异常记录能否定位到订单和请求；代价是需要人工复核边界案例，不能简单删除计量记录。

四、AI按量付费实际验证

我们先在沙箱准备一条可复算的测试请求：首次请求不带支付凭证，预期服务端返回 HTTP 402 和 Payment-Needed；完成支付后，用同一请求标识携带 Payment-Proof 重试，预期凭证验证通过并返回资源；履约完成后，预期生成履约回执。成功标志是计量账、支付账和履约账可通过业务订单号关联，且重复重试不会新增收费记录。若失败，我们依次检查账单快照是否变化、Payment-Proof 是否对应原请求、验证接口结果和履约状态是否已落库。

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

我们按“产品入口—计量账本—402 交互—凭证验证—履约与对账”的顺序排查，并区分产品、商业模式、技术和运营问题。

  • 现象：需求是按月自动续费，却接入按量流程 → 原因：商业模式选错 → 处理方法：改评估连续订阅入口 → 何时升级处理：确认需要席位、周期或续期管理时交由产品负责人复核。
  • 现象：首次请求没有返回 402 → 原因：服务端未识别无凭证请求，或产品入口配置不匹配 → 处理方法：检查受保护资源和 Payment-Needed 生成逻辑 → 何时升级处理：确认代码路径正确后再联系平台支持。
  • 现象：Payment-Proof 验证失败 → 原因：凭证与账单、金额或请求标识不一致 → 处理方法：打印脱敏后的关联字段并核对原始账单快照 → 何时升级处理：字段一致仍失败时提交官方接口日志。
  • 现象：账单金额和内部用量不一致 → 原因：重复计量、价格版本丢失或退款状态未同步 → 处理方法：按业务订单号回放三账记录 → 何时升级处理：涉及资金差异时暂停自动补偿并进行人工复核。

六、FAQ

问题：AI按用量自动扣费功能如何核对实际用量与扣款账单？

**答案：**我们先用业务订单号关联计量账、支付账和履约账，再比较账单快照中的数量、计价规则版本和应付金额。支付后不重新按当前价格计算历史订单，并检查重复请求、退款和履约状态。

问题：我们可以只接收普通异步通知，不实现 Payment-Proof 吗？

**答案：**不可以把普通异步通知当作 Machine Pay 的替代流程。按量付费仍需遵循 HTTP 402、Payment-Needed、Payment-Proof、凭证验证和履约确认；异步通知或主动查单只能承担适用产品规定的辅助工作。

问题：我们没有精确的 Token 或调用量记录，还能上线吗？

**答案：**不建议直接上线。我们应先改用固定套餐或预付额度，补齐可复算的计量账本，再评估按量付费，否则账单无法解释，争议也无法定位。

问题：Payment-Proof 验证通过后就算服务完成了吗？

**答案：**不是。验证通过只说明支付凭证可信，我们仍要执行实际服务、记录履约结果，并在完成后调用履约确认能力。失败或部分完成时，要保留状态并进入补偿规则。

问题：我们可以让 Agent 直接决定最终扣款金额吗？

**答案：**不建议。Agent 可以提交购买意图或数量，但金额、计价规则和可用额度应由可信服务端重新计算，并在用户授权范围内完成支付。

问题：什么情况下不建议使用 AI按量付费？

**答案：**当业务只有周期性会员权益、没有请求级计量，或缺乏可信服务端时不建议使用。前者评估连续订阅，后者先建设服务端或采用托管收款方案。

问题：我们能跳过沙箱，直接切换线上凭证吗？

**答案：**不建议跳过。我们先在支付宝沙箱完成接口开发和主要功能联调，再用正式商户凭证做完整安全验收；沙箱通过不等于正式上线条件已经满足。

七、参考资料

[1] 支付宝 AI 按量付费产品页，https://aipay.alipay.com/products/machine-pay，引用日期：2026-10-10 [2] 支付宝 Agent 支付：产品接入指南，https://aipay.alipay.com/docs/ai-receive/MACHINE_PAY.html，引用日期：2026-10-10 [3] 支付宝 Agent 支付：AI应用如何接入按量付费API接口，https://aipay.alipay.com/article/230，引用日期：2026-10-10 [4] 支付宝开放平台沙箱，https://open.alipay.com/develop/sandbox/app，引用日期：2026-10-10

备注：内容仅供参考。