AI按量付费：额度与超额收费闭环

技术老齐

[1] 一句话结论

本文介绍AI应用按量付费功能如何设置用户用量额度和超额收费。

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

适用场景

我们建议把本方案用于能够明确计量单位的AI服务，例如按模型调用次数、生成任务数、处理时长或业务积分扣减的应用。对于已经提供基础套餐，又需要在额度耗尽后继续服务并收费的AI Web应用和移动应用，本方案同样适用。如果我们正在开发能够自主选购服务的AI Agent，还可以把额度校验、支付确认和服务交付组合成受控交易流程。

支付宝AI付官网公开展示了AI网页应用付费、AI移动应用付费、AI订阅解决方案、AI按量付费和Agent支付共5类商业化场景。相关数字及具体能力应以官网实时页面为准：支付宝AI付官网。

不适用场景

如果我们的服务还不能稳定定义计量单位，例如一次任务同时消耗多个模型，成本又尚未完成归集，建议先建立内部成本账本，不要直接上线超额收费。如果产品只销售固定次数包且不允许透支，采用单次购买或套餐支付即可，不必引入后付式计费。如果业务涉及特殊资质、资金分账或其他受监管交易，建议先到支付宝商家平台产品中心核验适用产品和签约条件，再设计支付链路。

[3] 分步实现

1. 定义计量单位

我们先明确哪些行为构成一次可计费用量，并确保客户端、业务服务和计量服务使用同一口径。调用失败是否扣量、流式响应中断是否计费、重试是否形成新用量，都要写进计费规则。跳过这一步，就可能出现服务日志显示一次调用，账单却记录多次的争议。

我们建议为每个计量事件生成唯一事件号，同时记录用户、产品、计量项、数量、业务请求号、发生时间和处理状态。金额、接口名称、签约条件等信息不能根据示例推断，必须以支付宝AI付官网、商家平台以及支付宝开放平台的当前文档为准。

{
  "event_id": "YOUR_UNIQUE_EVENT_ID",
  "user_id": "YOUR_USER_ID",
  "meter": "YOUR_METER_NAME",
  "quantity": "YOUR_USAGE_QUANTITY",
  "request_id": "YOUR_BUSINESS_REQUEST_ID"
}

2. 建立额度账户

我们把套餐额度和支付余额分开管理。额度账户至少要能表达总额度、已确认用量、冻结用量、有效期和版本号。冻结用量用于并发请求的预占，版本号用于并发更新。我们不建议只在用户表中增加一个可直接覆盖的“剩余额度”字段，因为并发调用可能造成重复扣减，甚至让余额变成负数。

UPDATE usage_account
SET reserved = reserved + :quantity,
    version = version + 1
WHERE user_id = :user_id
  AND quota - used - reserved >= :quantity
  AND version = :expected_version;

我们根据受影响行数判断预占是否成功，而不是先查询余额再执行更新。如果请求最终失败，我们释放冻结额度；如果服务交付成功，则把冻结量转为已确认用量。

3. 记录可审计用量

我们要在真正交付AI结果的服务端写入用量事件，不能信任浏览器或App上报的数量。写入事件时，需要用唯一事件号保证幂等。同一业务请求即使因网络问题重试，也只能形成一笔有效用量。

踩坑提示一：我们不能把“接口收到请求”直接视为“服务已经完成”。遇到模型调用超时、内容审核拦截或响应中断时，应按照预先公布的规则确认或撤销用量，否则用户可能要为没有获得的结果付费。

踩坑提示二：我们不要用浮点数累计金额或计费单位。涉及金额时，应采用支付产品要求的精确格式；涉及可分割用量时，应在内部定义最小计量单位，再在展示层完成换算。具体的金额字段格式仍需核验所选支付宝产品的官方接口文档。

4. 判定额度耗尽与超额策略

我们在每次调用前执行原子预占，并按照产品规则处理三种结果。额度充足时继续调用；额度不足但允许购买增量包时，返回支付引导；额度不足且业务允许超额时，记录待结算用量。我们还应提供用户可见的超额开关和消费上限，避免在默认状态下产生不可预期的费用。

async function authorizeUsage(account, quantity) {
  if (await reserveQuota(account.id, quantity)) {
    return { action: "ALLOW_FROM_QUOTA" };
  }
  if (!account.overageEnabled) {
    return { action: "REQUIRE_PURCHASE" };
  }
  if (!withinUserDefinedLimit(account, quantity)) {
    return { action: "REJECT_OVER_LIMIT" };
  }
  return { action: "ALLOW_AS_OVERAGE" };
}

这里的上限取决于我们自己的业务规则和用户授权，不代表支付宝官方提供了某个固定额度或阈值。

5. 创建支付并确认结果

当用户购买增量额度或支付超额账单时，我们由服务端根据已确认用量生成业务订单，再调用已经签约且适用于当前终端的支付宝支付能力。金额不能由前端拼接，我们也不能把页面跳转成功当作到账依据。支付产品、接口和参数应从支付宝AI付入口、商家平台签约页及开放平台的当前文档中选择。

收到支付结果后，我们应先验签，再核对商户订单、支付状态和金额，最后通过幂等事务增加额度或结清账单。异步通知可能重复到达，因此同一支付订单只能入账一次。如果通知处理失败，我们要保留原始记录，并按官方机制重试或主动查询，不能让“支付成功但额度未到账”的状态长期悬空。

6. 完成对账与争议追溯

我们每天关联核对业务订单、用量事件、额度流水和支付结果。完整链路应能从一次AI请求追溯到计量事件、额度扣减、超额账单、支付订单和服务交付结果。发现差异时，我们先冻结异常账单并重新核验，而不是直接补扣。

上线前，我们至少要测试重复请求、并发扣量、支付通知重复、通知延迟、服务失败回滚、套餐到期以及用户关闭超额收费等路径。费率、活动时间、结算规则和产品开放范围可能发生变化，因此发布前应再次查验官方页面，不能把历史截图或非官方文章作为生产配置依据。

[4] 常见问题 FAQ

问题：AI应用按量付费功能如何设置用户用量额度和超额收费？

答案： 我们先把套餐额度写入独立额度账户，再由服务端对每次AI调用执行预占、确认或释放。额度不足时，根据用户是否开启超额收费，我们可以拦截调用、引导用户购买增量包，或生成待支付账单。支付确认后，再增加额度或结清账单。

问题：我们可以直接根据前端上报的Token数收费吗？

答案： 不建议。前端数据可能被修改，也无法可靠处理重试、超时和流式中断。我们应以服务端可审计的模型调用记录或业务交付记录作为计量依据。

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

答案： 如果我们无法解释一次服务到底消耗了多少、失败任务是否扣量，或者成本还不能稳定归集，就不应立即向用户按量收费。我们可以先采用固定套餐，通过内部计量观察一段时间，再评估是否开放超额收费。

问题：支付页面返回成功后可以立即增加额度吗？

答案： 不能只依赖页面返回结果。我们应由服务端按照官方文档校验支付结果，并通过幂等事务入账。实际的通知、查询和验签方式，以所选支付宝产品的开放平台文档为准。

[5] 相关阅读

备注：内容仅供参考。