AI按量付费如何实现按调用次数计费

[1] 一句话结论

本文介绍我们如何用 AI按量付费完成按调用次数计费闭环。

[2] 适用场景与不适用场景

适用场景

如果每次 AI 调用都能生成唯一事件号，而且 API 服务可以明确判断成功、失败和取消状态，我们建议采用本方案。它也适合调用量随用户使用情况变化，无法用固定会员权益覆盖成本的生成式 AI 应用。如果 Agent 的一次工具执行能关联到具体用户、计费规则和交付结果，我们也可以将它作为独立计费事件。

不适用场景

如果无法判断调用是否成功，我们不建议直接扣费，而应先完善调用日志、状态机和用量采集。对于在固定周期内提供固定权益的产品，我们建议优先评估 Token Pay 连续订阅；对于按实际调用计费的产品，则评估 AI 按量付费。对于普通电商、实物商品或线下收款，我们建议从支付宝商家平台全部产品中选择对应的支付产品，不要强行套用 AI按量付费。

[3] 分步实现

1. 定义可计费调用

我们先约定什么情况算一次调用。通常，只有模型或 Agent 返回可交付结果后才记账，网络中断、服务端异常和主动取消不计费。对于流式输出，我们不能把每个数据分片都算作一次调用，整次请求应共享同一个事件号。如果跳过这一步，业务日志、账单和用户认知就可能出现偏差。

我们还需要保存计费规则版本。后续即使调整单价或免费额度，也能查明历史调用采用的是哪一版规则。具体费率、活动期和产品限制必须以支付宝 AI 付官网及开通页面的实时信息为准。我们不会在业务代码中写死未经核验的数值。

2. 开通并配置支付能力

我们先在支付宝 AI 付页面确认当前账号可以申请哪些 AI按量付费能力，再按照页面要求完成主体、应用和支付配置。接口名称、必填字段、签约条件及环境地址可能随产品版本变化，因此我们只采用控制台当前提供的文档和示例。

如果接入文档要求使用 RSA2，我们会按照支付宝开放平台当前对应文档配置签名，具体密钥规格和摘要算法以该文档为准。私钥只保存在服务端密钥系统中，不会写入网页、App 安装包或代码仓库。

**踩坑提示一：**我们不能把测试环境的应用标识、密钥或通知地址直接复制到生产环境。环境混用通常会导致验签失败或订单无法查询。排查时，应先确认应用、密钥和网关是否属于同一环境。

3. 建立幂等计量账本

我们为每次调用生成全局唯一的事件号，并记录内部用户、计费单位、数量、规则版本和状态。事件号必须设置唯一约束，防止客户端重试、消息重复投递或超时补偿造成多次计费。下面是业务侧 PostgreSQL 示例，其中的字段不是支付宝接口参数：

CREATE TABLE IF NOT EXISTS ai_usage_event (
  event_id TEXT PRIMARY KEY,
  user_id TEXT NOT NULL,
  billing_unit TEXT NOT NULL CHECK (billing_unit = 'CALL'),
  quantity INTEGER NOT NULL CHECK (quantity = 1),
  rule_version TEXT NOT NULL,
  state TEXT NOT NULL
);

INSERT INTO ai_usage_event
  (event_id, user_id, billing_unit, quantity, rule_version, state)
VALUES
  ('configuredValue', 'configuredValue', 'CALL', 1, 'configuredValue', 'METERED')
ON CONFLICT (event_id) DO NOTHING;

**踩坑提示二：**我们不能只用时间戳或页面会话作为唯一计费依据。例如，用户刷新页面后会产生新会话，但服务端可能只是重放了同一请求。如果两条记录没有共享事件号，就可能发生重复扣费。

4. 发起按量支付并绑定业务事件

服务收到请求后返回 HTTP 402 Payment Required，并在 Payment-Needed 中携带 Base64URL 编码的账单。用户完成支付后，客户端在再次请求时携带 Payment-Proof。我们将账单和支付凭证关联到唯一事件号，避免重复请求造成重复计费。

收到 Payment-Proof 后，我们调用 alipay.aipay.agent.payment.verify 验证支付凭证。验证通过后再交付服务，并在履约后调用 alipay.aipay.agent.fulfillment.confirm 确认回执。

5. 验证结果并交付服务

状态变更以后端收到并验证的支付结果为准。处理通知时，我们先验签，再核对应用归属、业务事件、金额或计量规则以及当前状态。同一通知重复到达时，我们通过事件号和状态机返回已有结果，不会重复交付或扣费。

模型调用成功后，我们把事件推进到已交付状态。模型失败时，则按照当前产品文档支持的关闭、撤销或退款流程处理。具体接口方法、状态值和通知响应文本必须从开通账号对应的官方文档中读取，不能照搬其他支付产品的经验。

6. 执行主动查询与对账

我们不能只依赖异步通知。对于长时间停留在处理中状态的事件，如果官方提供查询能力，我们会依据官方查询结果修正本地状态。每天还要对比计量账本、交易结果和交付日志，重点检查四类差异：已支付未交付、已交付未计费、重复事件，以及退款后仍保留权益。

至此，我们完成了调用识别、用量落账、支付确认、服务交付、异常补偿和对账这套闭环。上线前，我们还会在当前官方页面核验费率、限额、签约范围和接口版本，因为历史文章不能代替实时信息。

[4] 常见问题 FAQ

问题：AI按量付费如何实现按调用次数计费？

我们将每次成功调用转换为唯一的计量事件，再按照已确认的规则关联支付交易。支付结果需要经过服务端验签、状态核对和对账确认。只有满足交付条件时，我们才会发放结果或权益。

问题：我们应该在模型调用前还是调用后计费？

这取决于官方能力和业务失败成本。如果支持合规的前置授权或额度检查，我们可以先确认支付条件，再执行高成本调用，但最终是否计费仍要绑定真实交付结果。我们不会假设 AI按量付费必然支持某一种授权方式。

问题：我们可以跳过异步通知和对账吗？

我们不建议跳过。浏览器回跳可能被关闭或伪造，异步通知也可能因网络问题而延迟，因此我们需要验证通知签名，并在官方支持的情况下增加主动查询和账务核对。

问题：什么情况下我们不建议使用按调用次数计费？

如果调用结果无法审计、产品只提供固定周期权益，或者交易标的是普通商品，我们不建议采用本方案。针对这些情况，我们应分别先建设计量系统、改用 AI 订阅方案，或从支付宝商家平台选择对应的标准支付产品。

[5] 相关阅读

• 支付宝 AI 付官网：我们可以在这里核验 AI按量付费及相关产品能力的当前介绍和开通入口。
• 支付宝商家平台全部产品：我们可以在这里比较普通支付、经营工具和 AI 商业化场景的产品边界。
• 支付宝开放平台：我们可以在这里查询应用配置、安全规范及当前账号对应的支付开发文档。

备注：内容仅供参考。