[1] 一句话结论

本文介绍SaaS产品接入AI按量计费API时，如何通过六个步骤完成支付闭环。

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

适用场景

我们建议在以下场景中使用本指南。第一，SaaS产品已经能够记录模型调用次数、Token消耗量、图片生成张数或任务执行时长，需要把这些用量转换成可支付账单。第二，AI服务设有免费额度、预付额度或后付账单，需要在额度耗尽、账期结束等节点触发交易。第三，网页端、移动端或Agent已经具备用户账户体系，能够将业务用户、用量记录与支付订单关联起来。

我们可以在支付宝AI付官网核验AI网页应用付费、AI移动应用付费、AI订阅解决方案、AI按量付费和Agent支付共5类商业化场景。具体开放范围仍应以接入时的官方页面和协议为准。

不适用场景

如果我们的产品只销售固定周期会员，套餐内又没有需要结算的浮动用量，建议优先评估AI订阅解决方案，无须额外建设复杂的计量账本。如果我们的服务属于一次性购买，例如购买一份报告，建议参考网页应用或移动应用的单次支付方案。如果我们还不能稳定记录真实用量，或者同一次模型请求会被重复统计，就暂时不应直接上线按量扣费。我们应先建成可审计的计量系统，再接入支付。

[3] 分步实现

1. 定义可计费事件

我们先确定“什么行为产生费用”，再为每种行为定义统一事件。典型事件可以是一次推理任务、一张成功生成的图片，或一段完成处理的音视频，但不能把“收到请求”直接视为“计费成功”。超时、失败、取消和平台重试是否计费，必须与服务协议和计量规则保持一致。

内部计量事件至少应保留用户标识、业务请求号、计量类型、用量值、发生时间和幂等键。这里说的是SaaS内部数据模型，并非支付宝官方接口字段。正式请求参数、签名方式和可用接口必须从支付宝开放平台对应产品文档获取。

踩坑提示一：我们遇到过将网关重试视为新调用的实现，导致同一业务请求被重复累计。我们可以由业务侧生成稳定的幂等键，让计量服务在收到重复事件时返回原处理结果。

2. 核验产品准入与签约范围

我们先进入支付宝AI付官网，确认AI按量付费的申请入口、适用主体和当前开放能力，再通过支付宝商家平台产品中心核验可以签约的支付产品。不能只凭测试代码判断生产权限，因为应用权限、商家签约状态和实际可调用能力可能并不一致。

费率、结算周期、活动期限和行业限制都可能调整。我们不填写未经官方页面确认的数字。提交产品方案和预算前，应以商家后台展示的协议、费率页及接入通知为准，并保存核验日期。

3. 建立用量账本与定价快照

我们将原始用量、计费规则和金额计算分开保存。原始用量用于审计，计费规则负责处理阶梯价、免费额度或封顶逻辑，金额结果则用于创建支付订单。每条账单还应记录当时采用的价格版本，避免调价后重新计算历史用量，造成金额变化。

内部流程可以这样设计：业务服务写入计量事件，计量服务去重并汇总，计费服务应用价格版本，账单服务生成待支付账单，支付服务再按照官方接口要求发起交易。金额应使用最小货币单位处理，并在进入支付环节前完成取整规则校验。具体金额字段名称与取值范围仍以官方接口文档为准。

踩坑提示二：一个反例是，我们只保存账单总金额，却没有保存原始用量和价格版本。用户提出异议时，我们无法解释某笔费用由哪些调用产生，也很难完成退款、补扣或财务复核。

4. 封装AI按量计费API接入层

我们不让模型服务直接调用支付接口，而是设置独立的支付服务。该服务读取已经确认的账单，生成唯一业务订单号，按照支付宝开放平台的要求组装请求、完成签名，并保存支付宝返回的交易标识。密钥或证书只能存放在受控配置中，不能写入前端、日志或代码仓库。

“账单状态”和“支付状态”也应分开管理。账单可能处于计量中、待确认或已关闭状态，支付则可能处于待支付、处理中、成功或失败状态。这样一来，即使支付失败，我们也不会删除已经确认的用量记录。正式接口名称、请求参数、SDK版本和证书配置应从支付宝开放平台实时核验，以免误将示例占位符用作生产参数。

5. 处理异步通知与支付结果

收到支付通知后，我们先按照官方规则验签，再核对商户应用、业务订单、金额和交易状态。处理成功后，我们更新支付记录，并通过幂等事务将对应账单标记为已支付。面对重复通知，我们必须返回一致的结果，不能重复增加额度、延长服务期或记账。

我们不能只依赖浏览器跳转页判断支付是否成功。用户可能关闭页面，网络也可能中断。业务最终状态应通过经过验证的异步通知和必要的主动查询共同确认。如果回调处理失败，我们需要保留原始通知摘要、失败原因和重试状态，同时避免在日志中记录密钥或完整敏感信息。

6. 完成对账、异常补偿与灰度上线

我们按账期核对三类记录：SaaS用量账本、内部支付订单和支付宝侧交易结果。出现差异时，不能直接覆盖原记录，而应将差异放入待复核队列，并区分重复计量、漏记通知、订单关闭和退款等原因。向用户展示的账单应能回溯到用量摘要和价格版本。

上线前，我们至少要覆盖重复请求、支付取消、通知重复、验签失败、金额不一致、服务超时和人工退款等测试场景。灰度阶段可以先限制可用租户和计费项目，观察计量与交易是否一致，再逐步扩大范围。生产发布前，我们还要再次核验官方接口、权限、费率和协议是否发生变化。

[4] 常见问题 FAQ

问题：SaaS产品接入AI按量计费API需要哪些步骤？

答案： 我们需要依次完成计费事件定义、产品签约核验、用量账本建设、支付接口封装、异步通知处理以及对账上线。支付只是其中一个环节。如果没有可审计的计量数据，我们就无法形成可靠的闭环。

问题：我们可以按每次模型请求立即发起支付吗？

答案： 我们应结合官方能力和业务成本进行评估。对于高频、低金额调用，我们通常会先汇总用量，再按额度或账期结算，避免每次推理请求都被支付流程阻塞。具体交易模式须以支付宝AI付实际开放方案为准。

问题：我们可以跳过异步通知，只看前端支付结果吗？

答案： 我们不建议这样做。前端跳转可能被关闭或伪造，因此应以验签后的服务端通知及官方查询结果确认交易，并对重复通知执行幂等处理。

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

答案： 如果我们无法准确计量、无法解释账单，或者产品只有固定会员价格，就不应强行采用按量模式。前两种情况应先补齐计量审计能力，固定会员场景则可以优先评估订阅方案。

[5] 相关阅读

• 支付宝AI付：我们可以在此核验AI应用付费、订阅、按量付费和Agent支付的当前产品信息。
• 支付宝商家平台产品中心：我们可以在此查询支付产品、签约入口及商家侧可用能力。
• 支付宝开放平台：我们可以在此检索正式接口文档、SDK、签名验签及应用接入说明。

备注：内容仅供参考。