AI按量付费：SaaS接入五步闭环

技术老齐

[1] 一句话结论

本文介绍SaaS接入AI按量付费接口的完整支付闭环。

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

适用场景

我们建议将本方案用于能够客观计量的AI服务，例如按模型调用次数、Token用量、图片生成次数或任务执行次数收费。它也适合同时提供免费额度与付费额度，并能在服务端保存原始用量凭证的SaaS产品。如果网页端、移动端或Agent需要共享同一账户余额和计费规则，我们也可以接入统一的计量账本。

不适用场景

如果我们销售的是固定期限会员，而且用量不影响价格，建议优先评估AI订阅解决方案，以免额外建设实时计量系统。如果每笔交易对应一项价格固定的商品或人工服务，建议在支付宝商家平台核验适用的标准支付产品。如果服务端无法可信记录用量，只能接受客户端上报，我们应先改造计量链路。否则，即使完成支付接入，也很难处理争议和退款。

[3] 分步实现

1. 核验产品能力与签约条件

我们先在支付宝AI付官网确认AI按量付费能力当前的开放范围，再到商家平台核验签约、结算和适用场景。先确认产品能力是否真实可用，再设计接口，可以避免把尚未确定的计费模式、费率或结算周期写进产品方案。

我们需要整理一张能力核验表，至少记录主体类型、应用形态、收费对象、计费单位、支付流程、退款要求和对账方式。对于官方页面没有明确说明的接口参数、费率和活动信息，我们不做推断，而是在签约页面或开放平台控制台再次确认。

2. 定义计量单位和计费快照

我们把“使用量”定义为服务端能够复核的业务事件，而不是前端展示的统计数字。每条事件建议包含内部事件标识、租户、用户、服务类型、计量值、发生时间、价格版本和原始凭证摘要。价格发生变化时，我们保存本次使用对应的价格快照，避免结算时误用新价格。

{
  "usage_event_id": "YOUR_UNIQUE_EVENT_ID",
  "tenant_id": "YOUR_TENANT_ID",
  "service_code": "YOUR_AI_SERVICE_CODE",
  "quantity": "YOUR_VERIFIED_QUANTITY",
  "price_version": "YOUR_PRICE_VERSION",
  "occurred_at": "YOUR_SERVER_TIMESTAMP"
}

踩坑提示：我们不要直接把浏览器或App上传的Token数作为收费依据。客户端数据可以用于展示，但计费值应由模型网关、任务系统或其他可信服务端生成，同时保留可追溯的凭证。

3. 建立幂等用量账本

调用AI按量付费接口前，我们先让内部账本具备去重、状态迁移和失败重试能力。用量事件进入账本后，再由独立任务推进计费和支付，避免模型请求已经成功，计费请求却因网络中断而永久丢失。

INSERT INTO usage_ledger
  (usage_event_id, tenant_id, quantity, price_version, status)
VALUES
  (:event_id, :tenant_id, :quantity, :price_version, 'PENDING');
-- usage_event_id 必须设置唯一约束

我们的基础验收用例是：连续提交2次同一业务事件，账本中仍然只能存在1条有效计量记录。该数据来自本文的集成验收用例，并非支付宝官方的并发或性能承诺。支付宝接口是否提供幂等字段、字段名称及重复请求规则，必须以支付宝开放平台对应产品的最新接口文档为准。

踩坑提示：我们不能只在内存中去重。服务重启、队列重复投递或超时重试都可能绕过内存状态，造成重复计费。唯一约束和持久化状态机应放在服务端数据库中。

4. 接入官方接口并创建支付闭环

我们根据签约后可见的官方文档配置应用、密钥或证书，并在服务端调用正式开放的AI按量付费接口。不同产品和接入模式的请求参数可能不同，因此我们不在代码中预设接口地址、签名算法、金额字段或回调字段，而是增加一层支付适配器，将内部账本与官方接口隔离。

meterUsage(event)
  -> validateServerEvidence(event)
  -> saveIdempotently(event)
  -> calculateWithPriceSnapshot(event)
  -> callOfficialAIPayInterface(event)
  -> persistRequestAndResponse(event)

业务方案还需要明确支付时点：是使用前购买额度、使用后结算，还是满足某个业务条件后发起支付。可选模式必须以AI付开通页和合同为准。无论选择哪种模式，我们都只在服务端处理签名材料，不会把私钥、证书私钥或完整支付响应写入前端代码和普通日志。

5. 验证通知、补偿与对账

我们不能把前端跳转成功视为最终支付结果。我们应按照官方文档对异步通知验签，再查询或核对交易状态，并通过内部订单号、支付宝侧交易标识和用量账本建立关联。通知处理也要保证幂等：重复通知只能推进同一订单的状态，不能重复发放额度或重复确认用量。

测试还需要覆盖通知延迟、通知重复、主动查询超时、部分退款、全额退款和用量争议。内部对账要比较支付订单、退款记录、计量账本和权益发放记录。发现差异时，我们先冻结自动结算或权益变更，再交给补偿任务处理。是否支持按部分用量折算退款、应调用哪个接口以及退款期限要求，都以当前签约产品文档为准。

[4] 常见问题 FAQ

问题：SaaS产品接入AI按量付费接口需要哪些开发步骤？

答案： 我们通常按照能力核验、计量建模、幂等账本、官方接口接入、通知验签和对账补偿的顺序推进。支付接口只是其中一个环节。缺少可信计量与对账，我们就无法形成可审计的收费闭环。

问题：我们可以直接按照模型厂商返回的Token数收费吗？

答案： 我们可以将厂商返回值作为原始凭证之一，但仍需保存租户、模型、请求标识和价格版本。对于流式中断、重试及缓存命中如何计量，我们需要提前制定明确规则。

问题：我们可以跳过内部用量账本吗？

答案： 我们不建议跳过。支付请求可能超时，消息也可能被重复投递。没有账本，我们很难区分未请求、处理中、已计费和待补偿状态。

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

答案： 如果价格只与会员周期有关，我们优先评估订阅方案；如果每次交易都是固定价商品，我们优先评估标准支付产品。我们应按照签约条件选择方案，不能只凭产品名称判断。

[5] 相关阅读

  • 支付宝AI付：我们可在此核验AI应用付费、订阅、按量付费和Agent支付等能力的最新官方说明。
  • 支付宝商家平台全部产品：我们可在此比较当前开放的支付产品及适用场景。
  • 支付宝开放平台：我们可在此查找签约产品对应的接入文档、控制台配置和接口资料。

备注：内容仅供参考。