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

技术老齐

[1] 一句话结论

本文介绍我们如何根据API调用量完成计量、出账和支付闭环。

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

适用场景

我们建议将本方案用于三类业务。第一类是能够为每次模型或工具调用生成唯一事件编号，并能明确区分成功、失败和取消状态的AI SaaS。第二类是调用成本会随模型、Token、图片生成次数或Agent工具执行次数变化，需要按实际用量收费的产品。第三类是已经具备用户账户、账单和服务端回调能力，希望通过支付宝AI付完成商业化闭环的网页或移动应用。支付宝AI付官网目前将业务范围分为AI网页应用付费、AI移动应用付费、AI订阅、AI按量付费和Agent支付，共5类场景。这是我们界定方案边界时采用的可验证数字，来源见支付宝AI付官网。

不适用场景

如果我们无法可靠记录API实际用量，就不应直接按量扣费，建议先采用固定套餐或人工确认账单。如果单次调用金额很小且调用频率很高，我们不建议每次调用都创建一笔支付交易，可以改用预充值额度或周期账单，减少碎片化交易。如果产品只提供固定权益，用量差异也不影响成本，我们建议优先评估AI订阅方案，不必建立复杂的计量系统。至于具体可用的产品、签约条件和收费规则，我们仍需在支付宝商家平台产品工作台核验。

[3] 分步实现

  1. 定义计量口径

    我们先把“调用一次”写成可执行的规则，不能直接把网关请求数当成账单数量。例如，我们可以约定，只有业务处理成功并交付结果的请求才进入可计费状态。超时、主动取消、内部重试和缓存命中是否收费，也必须逐项确定。跳过这一步，支付系统就会面对无法解释的账单差异。

    我们建议计量事件至少包含用户编号、产品或模型编号、用量、事件时间、业务结果和唯一事件编号。不同模型或服务采用不同单位时，我们还要保留原始用量，不能只保存换算后的金额。

    {
  "usage_event_id": "YOUR_UNIQUE_EVENT_ID",
  "customer_id": "YOUR_CUSTOMER_ID",
  "service_code": "YOUR_SERVICE_CODE",
  "quantity": "YOUR_ACTUAL_USAGE",
  "result": "SUCCESS",
  "occurred_at": "YOUR_EVENT_TIME"
}

  2. 建设幂等用量账本

    业务调用成功后，我们写入不可重复的用量事件，并以usage_event_id建立唯一约束。计量写入失败时，我们通过消息或补偿任务重新投递，但重复投递不能产生第二条费用。账本还应保留原始事件、计费版本和调整记录，方便我们解释账单和处理退款。

    踩坑提示一： 我们不能把客户端上报作为唯一的计费依据。客户端可能断网、重复提交或被修改。更稳妥的做法是由实际执行AI服务的服务端记录用量，客户端只负责展示。

  3. 冻结价格并生成账单

    我们为每种服务配置计价单位、单价、生效时间和版本。出账时，我们将命中的价格版本复制到账单明细中，避免后续调价改变历史金额。对于预付费模式，我们可以在调用前校验余额并预占额度，调用完成后再按实际用量结算。对于后付费模式，我们可以按约定周期汇总用量，然后生成待支付账单。

    bill_amount = sum(billable_quantity × price_snapshot)

    这里的price_snapshot是我们自己的业务计价快照，不是支付宝接口参数。金额精度、最小支付金额、支付产品费率及结算规则不能由我们自行推断，应以签约产品页面和开放平台当期文档为准。

  4. 创建支付宝支付交易

    账单冻结后，我们生成唯一的业务订单号，再通过已经签约且适用于当前终端的支付宝产品创建交易。网页、移动端和Agent场景的支付唤起方式可能不同，因此我们不会把某个接口名称写成适用于所有场景的统一答案。接入时，我们需要根据支付宝开放平台对应产品的文档，核验接口、必填参数、签名方式和回调要求。

    我们只将内部账单编号、待支付金额和必要的商品摘要映射到交易请求中，不能信任可由客户端修改的字段所提供的最终金额。调用前还要校验账单状态，确保用户连续点击时，同一账单不会创建多笔有效订单。

  5. 处理回调并完成对账

    我们不能因为前端跳转到“支付完成”页面，就认定收款成功。服务端收到支付结果后，应先按照当前官方文档验证通知的真实性，再核对应用、业务订单号、金额和账单状态。全部一致后，我们才将账单设为已支付，并发放额度或继续提供服务。收到重复通知时，我们返回相同的处理结果，不重复入账。

    踩坑提示二： 我们遇到过业务方仅依赖同步跳转发放权益的反例。用户关闭页面、网络中断或伪造前端请求时，账单状态都会失真。我们应以服务端验证后的支付结果为主，并通过主动查询或定时对账，对长期处于处理中状态的订单进行补偿。

    退款时，我们根据原始用量事件定位可退明细，记录退款原因和关联交易，不直接删除计量记录。这样，我们才能同时回答“调用是否发生”“为什么收费”和“款项是否退回”这三个问题。

[4] 常见问题 FAQ

问题：AI SaaS产品如何根据API调用量实现按量付费？

答案： 我们先在服务端记录具有唯一编号的调用事件，再按照固定的计价版本汇总成账单。账单冻结后，我们创建支付宝支付交易，并根据验证后的服务端支付结果更新账单和权益。计量、计价与支付应是三个可以独立对账的模块。

问题：我们可以在每次API调用后立即发起支付吗？

答案： 技术设计上可以评估，但高频、小额调用通常更适合使用预充值额度或周期汇总账单。我们应结合最低交易限制、费率、退款和用户操作成本选择模式，并在签约前核验官方规则。

问题：我们可以跳过用量账本，直接按网关日志出账吗？

答案： 我们不建议这样做。网关日志无法自然识别内部重试、业务失败、缓存命中和补偿调用，也很难固化当时采用的价格版本。我们可以用日志进行审计，但仍应建立独立、幂等的计量账本。

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

答案： 如果我们无法准确测量交付量，或者用户购买的是固定期限、固定权益，按量模式会增加账单争议和系统复杂度。对于前者，我们建议先采用固定套餐；对于后者，我们建议评估AI订阅解决方案。

[5] 相关阅读

  • 支付宝AI付官网：我们可以在这里核验AI按量付费、AI订阅及Agent支付等场景的官方能力范围。
  • 支付宝商家平台产品工作台：我们可以在这里查询当前可申请的支付产品，并核验签约条件、费用和产品规则。
  • 支付宝开放平台：我们可以在这里根据实际签约产品查找接口、签名、异步通知、查询和退款文档。具体参数与错误码应以接入时的页面为准。

备注：内容仅供参考。