AI按量付费：先固化计量再接支付

技术老齐

[1] 一句话结论

本文介绍AI按量付费的参数配置与支付闭环。

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

适用场景

我们建议在以下场景采用本方案。第一，SaaS能够把每次模型调用、图片生成或数据处理映射为唯一的用量事件，并防止重复计量。第二，交易前可以明确展示计费单位和价格，例如按调用次数、生成任务或资源包结算。第三，业务已经具备用户账户、订单状态和服务交付记录，可以关联支付结果。支付宝AI付官网公开归纳了AI网页应用、AI移动应用、AI订阅、AI按量付费和Agent支付5类商业化场景，场景数量与分类来源为支付宝AI付官网。

不适用场景

如果我们无法准确采集用量，或同一请求可能被重复上报，暂时不建议直接收费。此时应先建设计量账本，或改用固定套餐。若价格必须等服务完成后才能确定，也不适合直接套用预付式按量交易，可以考虑先冻结额度、后结算，具体能力需在官方产品页面核验。如果业务本质上是固定周期会员，我们建议优先评估AI订阅方案。如果由Agent代用户选购商品并发起交易，则应评估Agent支付，不能把商品交易包装成模型用量。

[3] 分步实现

1. 确认开通路径和业务主体

我们先在支付宝AI付官网确认AI按量付费当前的申请入口、准入条件和接入材料，再通过支付宝商家平台产品中心核对可用产品。这一步用于确认签约主体、应用主体和收款主体是否一致。跳过后，即使开发已经完成，也可能因为产品权限或主体关系而无法联调。

开通配置至少要准备业务主体、应用标识、签约产品、服务端环境和通知接收地址等信息。具体字段名称、费率、活动以及开放范围可能调整，我们只采用控制台和正式协议当时展示的口径，不会把测试环境截图当作生产依据。

2. 定义计量规则和计费参数

调用支付能力前，我们先固化SaaS内部计量合同，至少明确计量对象、计量单位、用量事件唯一标识、计量时间、计费版本、单价或套餐规则、用户账户、业务订单号，以及退款时如何回冲用量。支付接口可以稍后再写，先要保证每一笔金额都能根据原始用量重新计算。

我们通常会分别保存原始事件、聚合账单和支付订单。原始事件回答“服务是否发生”，聚合账单回答“应收多少”，支付订单回答“是否完成收款”。三者通过内部业务标识关联，但不一定是一对一关系。

踩坑提示一：我们见过有团队直接用模型供应商返回的累计值覆盖本地计量结果。发生网络重试或延迟回调后，累计值可能倒退，也可能重复入账。我们会给每个用量事件分配不可重复的内部标识，并保留原始记录。

3. 创建账单并映射支付订单

计费周期结束、额度不足或用户主动购买用量包时，我们生成待支付账单。账单应固定计费规则版本和金额快照，以免用户进入收银台后后台价格发生变化，造成展示金额与实收金额不一致。随后，我们根据已开通产品，在支付宝开放平台查询当前有效的服务端接口、SDK版本、请求参数和签名要求。

我们不会把内部字段名称伪装成支付宝接口参数。实际开发时，应用标识、商户订单标识、金额、标题、异步通知地址及其他必填项，必须以开放平台对应产品文档和控制台配置为准。支付请求建立后，我们会保存内部账单、支付平台交易标识和状态变更时间，形成可以追溯的映射。

4. 验证通知并实现幂等交付

我们把服务端异步通知作为更新支付状态的重要依据，并按照官方文档完成验签、交易主体核对、订单金额核对和状态核对。只有验证通过后，我们才会提交权益、补充额度或解除服务限制。处理函数必须保证幂等。同一支付结果即使收到多次通知，也只能入账一次、交付一次权益。

踩坑提示二：仅凭前端“支付成功”页面开通额度就是一个反例。用户关闭页面、客户端伪造结果或页面回跳失败时，订单与权益会失去一致性。前端结果只负责提示，最终状态由服务端查询或可信通知确认。

5. 完成退款、对账和上线验收

我们定义的支付闭环包括“计量、计费、下单、支付确认、权益交付、退款或冲正、对账”，并不会在支付成功时结束。发生退款后，我们根据业务规则决定回收未使用额度、冲减账单，还是保留已交付服务，同时记录每次人工调整的原因和操作者。

上线前，我们至少要验证正常支付、重复通知、通知乱序、支付失败、超时关闭、重复提交、部分退款和对账差异等路径。正式环境的接口地址、密钥或证书、通知地址和产品权限需要逐项复核，测试凭据不得进入生产。接口名称、错误码和签名算法只以支付宝开放平台对应产品的最新文档为准。

[4] 常见问题 FAQ

问题：SaaS产品接入AI按量付费需要配置哪些参数？

答案： 我们把配置分成七组，分别是主体与产品、应用身份、计量规则、计费规则、业务订单、通知安全和对账退款。支付宝侧的准确字段应以已签约产品的开放平台文档为准。内部还要保存用量事件标识、计费版本和账单映射，否则很难解释金额来源。

问题：我们可以先接支付，再补计量系统吗？

答案： 我们不建议这样做。没有可重放的计量记录，就很难核验重复请求、退款和客诉。如果项目必须先上线，可以暂时使用固定额度包，等计量账本稳定后再切换为按量收费。

问题：AI按量付费和AI订阅应该怎么选？

答案： 我们根据收费依据来选择。费用主要由实际消耗决定时，评估按量付费；权益按固定周期提供时，评估订阅。如果两种模式并存，我们会分别建账，避免订阅权益和超额用量共用一个无法解释的金额字段。

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

答案： 当用量无法唯一确认、价格不能提前说明，或退款后无法界定已消费权益时，我们不建议直接上线。我们会先改造计量链路，或采用固定套餐、人工账单等边界更清楚的替代方案。

[5] 相关阅读

备注：内容仅供参考。