AI按量付费：先计量再完成支付闭环

技术老齐

[1] 一句话结论

本文介绍我们如何实现AI按量计费与支付闭环。

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

适用场景

我们建议将这套AI应用按量收费解决方案用于三类业务。第一类是AI API，其调用次数、Token、生成时长或任务数量能够由服务端准确记录。第二类是单次费用较低，适合先充值后扣减，并在余额不足时引导续费的Agent产品。第三类是需要按项目、租户或用户汇总用量，并将计量记录与支付宝订单关联的SaaS服务。接入前，我们会先确认支付宝AI付当前的开放范围、签约条件和可用支付产品，相关能力以支付宝AI付官网展示为准。

不适用场景

如果我们无法客观记录用户的实际消耗量，就不建议直接按量收费，可以改用固定套餐或订阅方案。如果业务主要销售一次性交付的数字商品，也没有持续计量需求，建议采用普通单次支付方案。如果每次调用产生的金额极小，我们不建议为每次调用创建支付订单。更稳妥的做法是预充值余额后逐次扣减，或者按约定周期汇总账单。具体支付产品能否用于相应场景，我们需要在支付宝商家平台产品中心核验。

[3] 分步实现

1. 定义可审计的计量单位

我们先确定收费对象，例如API调用次数、有效Token、音视频处理时长或成功完成的任务数，同时写清计量的起点、终点、舍入规则，以及失败请求是否收费。如果跳过这一步，即使后续支付成功，我们也很难解释账单为何产生。

每次发生消耗时，我们都会生成唯一事件编号，并保存用户、租户、模型、计量值、发生时间和业务请求编号。计量事件只允许追加。如果需要冲正，我们会新增一条反向记录，避免直接修改历史数据。

{
  "usage_event_id": "YOUR_UNIQUE_EVENT_ID",
  "tenant_id": "YOUR_TENANT_ID",
  "user_id": "YOUR_USER_ID",
  "metric": "token_or_call_or_duration",
  "quantity": "YOUR_ACTUAL_USAGE",
  "request_id": "YOUR_AI_REQUEST_ID",
  "occurred_at": "YOUR_TIMESTAMP"
}

2. 固化价格版本并生成账单

我们不会只在代码中写入一个当前单价，而是会保存价格版本、生效时间和适用对象。结算时，系统按照用量发生时生效的价格计算账单，并保留从计量事件到应付金额的完整快照。这样一来，即使后续调整价格，我们仍能复算历史账单。

金额进入支付宝订单前，我们需要按照所选接口的字段规则处理。支付宝开放平台交易接口文档规定，交易金额以元为单位，并精确到小数点后2位。这是本文使用的可验证数字，来源为支付宝开放平台 alipay.trade.create 文档。如果单次调用产生的金额无法精确到两位小数，我们会先将其累计到内部余额或结算账单，而不会自行扩展支付接口的精度。

踩坑提示一：我们不能只保存最终金额，却丢弃原始用量。用户发起异议时，如果没有计量明细，我们就无法完成复核。踩坑提示二：我们不要直接使用客户端上报的Token或调用次数计费。客户端数据可以用于展示，但结算应以服务端日志为依据。

3. 选择扣费时机并创建业务订单

我们通常会在两种模式中选择。预付模式先完成充值，再根据实际用量扣减余额；后付汇总模式先记录用量，再按照业务约定生成待支付账单。能否采用特定代扣、周期扣款或签约能力，必须以商户资质、产品协议和官方页面实际开放的能力为准，不能只根据技术接口名称判断。

创建支付请求前，我们先生成不可重复的商户订单号，并将订单号与账单版本绑定。订单金额、币种、用户归属和账单状态均由服务端写入。我们只允许Agent发起购买意图，不能让它自行决定最终价格。接入时，我们会通过支付宝开放平台的对应产品文档核验具体接口、必填参数和签名方式，不在示例中假设未经确认的字段。

usage events -> immutable bill -> merchant order -> Alipay payment
      |              |                 |
  request_id     price_version      out_trade_no

4. 验证支付结果并幂等入账

用户页面显示支付完成，并不等于我们已经收款。我们会根据服务端验签后的支付通知和官方交易查询结果更新订单，同时检查通知中的商户订单号、金额及商户身份是否与本地订单一致。相同通知可能重复到达，因此入账操作必须根据商户订单号和支付状态进行幂等控制。

踩坑提示三：我们不能把前端跳转页面作为发放余额的依据，否则伪造跳转或网络重放可能导致错误入账。踩坑提示四：回调处理过程中，我们不要调用耗时的AI任务。我们应先完成验签和状态落库，再通过异步任务发放额度或恢复Agent执行。

5. 让Agent恢复交易并完成对账

支付成功后，我们会将可用余额或已支付账单状态写入独立账户系统，再让Agent从中断点恢复任务。我们只向Agent提供最少的必要结果，例如“额度已到账”或“账单已支付”，不会提供支付密钥、完整通知报文或不必要的账户信息。

每天对账时，我们按照商户订单号匹配本地订单、支付结果、退款记录和计量账单。如果发现本地状态为成功，但渠道结果不一致，我们会先冻结重复发放流程，再依据官方查询结果修正状态。发生退款时，也应同时生成余额冲正或用量账单调整记录，避免支付侧已经退款，AI额度却仍可继续使用。

[4] 常见问题 FAQ

问题：AI Agent产品如何接入按实际使用量收费的解决方案？

答案： 我们先在服务端记录不可篡改的用量事件，再根据价格版本汇总账单，最后通过支付宝当前可用的支付产品完成收款。Agent只负责表达购买意图和恢复任务，计价、签名、验签与入账都放在受控后端完成。

问题：每次模型调用后都需要发起一次支付宝支付吗？

答案： 通常不需要。对于低金额、高频调用，我们更建议采用预充值扣减或汇总账单，以减少支付中断和订单数量。最终采用哪种模式，需要结合业务协议及官方开放能力确定。

问题：我们可以跳过支付宝异步通知验签，只相信前端支付结果吗？

答案： 不可以。我们必须通过服务端验证支付结果，并核对订单号、金额和商户身份。前端结果只用于页面提示，不能触发余额发放。

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

答案： 当用量无法客观核验、用户更关心固定预算，或服务本质上是一次性交付时，我们不建议按量收费。针对这些情况，我们会分别改用固定套餐、订阅或普通单次支付。

[5] 相关阅读

备注：内容仅供参考。