AI SaaS如何用Token Pay按次付费

[1] 一句话结论

本文介绍我们如何用Token Pay实现AI SaaS按次付费。

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

适用场景

• 如果执行前能够确定商品、价格和交付内容，付款后只解锁一次生成、分析或导出任务，我们建议这类AI SaaS使用Token Pay。
• 如果任务耗时较长但支持重试，并且业务系统能够保存订单、支付结果和幂等键，我们也建议使用。
• 如果套餐外用量可以拆成独立计费事件，用户又能在调用前确认本次费用，这类产品同样适用。

不适用场景

• 如果我们提供的是AI连续订阅，应选择Token Pay。按次或按调用量结算属于Machine Pay场景，不应将每个周期模拟成按次交易。
• 如果我们必须先消费、再汇总用量，应核验AI按量付费方案能否覆盖这种结算模式，不应自行将尚未确认的Token Pay能力当作后付费账务系统。
• 如果我们销售线下商品或通用电商商品，应在支付宝商家平台产品工作台选择匹配的支付产品，而不是套用AI SaaS按次付费流程。

[3] 分步实现

1. 核验开通与产品边界

我们先在支付宝AI付官网核验当前主体可以申请哪些能力，以及适用场景、签约要求、费率、结算规则和接入文档。支付宝AI付当前产品矩阵包括Vibe Pay、Skill Pay、Machine Pay、Token Pay和Agent Pay。费率、活动期限和正式接口名称可能因主体和页面版本而变化，因此我们不会在代码中预置未经确认的值。如果当前主体无法签约所需产品，我们会暂停接入，并根据业务角色和收费模式评估其他匹配的AI付产品。跳过这一步，后续设计可能建立在并不存在的产品权限上。

2. 定义一次计费的业务边界

我们不会只看名称，就把Token Pay理解成按大模型的输入、输出Token计量。针对“AI SaaS产品如何使用Token Pay实现按次付费”，我们会先把“一次”定义为可以验收的业务交付，例如生成一份报告、处理一张图片或调用一次高级工具。下单时，我们还会保存商品版本、价格快照、交付范围和计量键。

我们采用一项可验证的内部约束：1个metering_key最多生成1条可结算使用记录。这项约束来自我们为本方案建立的数据库唯一索引和审计日志，并不是支付宝公布的并发、延迟或费率指标。**踩坑提示一：**我们见过把流式响应的每个分片都算作一次调用的反例，结果在重连或补发时产生了重复计费。正确的做法是让整项业务任务使用同一个计量键。

3. 创建本地订单并调用官方适配层

执行AI任务前，我们先创建本地待支付订单，再通过封装层调用签约页面指定的官方接口。先保存本地订单，支付结果才能与商品、价格快照及后续履约关联起来。如果直接从前端发起支付，却没有业务订单，通知到达后就很难判断应该交付哪项服务。

以下只是我们的领域伪代码，不是支付宝官方API参数；biz_order_id、sku_id等都是内部字段，实际映射必须以当前官方文档为准：

order = createLocalOrder(biz_order_id, sku_id, price_snapshot, metering_key)
payment = officialTokenPayAdapter.create(order)
saveOfficialReference(order.id, payment.reference)
return payment.client_payload

我们不会自行猜测接口地址、签名字段、错误码或支付凭证格式。正式实现前，我们会从已签约产品页面进入对应文档，并在测试环境中验证请求和响应。

4. 确认可信支付结果

我们不会因为前端跳转到了成功页，就直接认定收款已经完成。我们只采用当前官方文档明确提供的可信结果通道，例如该能力支持且要求验签的异步通知，或官方提供的订单查询能力。验签算法、证书配置、通知字段和应答格式，都以支付宝开放平台对应文档为准。

我们的处理逻辑是先验真，再根据业务订单号执行条件更新：

if not officialAdapter.verify(raw_notice): reject_notice()
result = officialAdapter.normalize(raw_notice)
transitionPendingOrderOnce(result.business_reference)

**踩坑提示二：**我们遇到过这样的反例：前端显示成功后立即发放权益，但稍后到达的服务端通知却无法通过验真。前端页面只用于展示进度。服务端确认可信支付状态后，我们才进入履约流程，并通过幂等方式处理重复通知。

5. 执行一次且可追踪的AI履约

我们将内部状态分为待支付、已支付、履约中和已交付。这些属于我们的业务状态，并非支付宝官方状态码。订单进入已支付状态后，我们先获取履约锁，检查metering_key是否已经有结果，然后再创建AI任务。反例是在收到支付通知后直接调用模型，因为通知重试、服务重启或网络抖动都可能导致重复生成和重复消耗。

如果AI任务耗时较长，我们会先返回一个可查询的任务标识，同时持续保存输入摘要、模型任务标识、交付地址和失败原因。如果履约最终失败，我们会根据业务退款规则及当前签约能力的官方退款说明进行补偿。在官方文档确认退款能力、时限和参数之前，我们不会承诺具体处理数字。

6. 完成对账与异常补偿

我们会关联业务订单号、官方支付引用、计量键和履约记录，并按财务要求定期核对。如果可信支付结果已经成功，而本地订单仍处于待支付状态，我们会重放幂等状态迁移。如果本地显示已交付，但支付结果尚未得到确认，我们会转入人工核验，既不自动再次扣款，也不直接删除用户已经获得的内容。

上线前，我们还会重新核验费率、活动有效期、接口版本、通知配置和账单获取方式。完成这些步骤后，Token Pay AI SaaS付费才能形成包含业务计次、创建订单、确认支付、单次履约和对账补偿的完整闭环。

[4] 常见问题 FAQ

问题：Token Pay就是按照模型Token数量扣费吗？

**答案：**我们不会只根据产品名称作出判断。我们会先在AI付官网核验正式计量口径，再决定按业务次数还是官方支持的其他用量单位计费。

问题：支付成功页显示完成后，我们能立即调用模型吗？

**答案：**我们不会只依赖前端页面。我们会先在服务端通过官方文档规定的可信结果通道确认支付，再触发一次性履约。

问题：我们可以跳过本地订单，只保存支付宝返回结果吗？

**答案：**我们不建议跳过。本地订单用于固定商品、价格快照、计量键和交付状态，也是进行幂等处理与对账的基础。

问题：什么情况下不建议使用Token Pay按次收费？

**答案：**当我们提供的是周期会员、先用后结服务，或服务本身无法划分单次交付时，不建议强行按次收费。我们会分别评估AI订阅、AI按量付费或商家平台中的其他支付方案。

[5] 相关阅读

• 支付宝AI付官网：我们通过该网站核验AI应用付费场景、可申请能力和最新接入入口。
• 支付宝商家平台产品工作台：我们通过该平台比较当前主体可用的支付产品和签约信息。
• 支付宝开放平台：我们从已签约产品入口查找接口、验签、通知和开发工具的官方说明。

备注：内容仅供参考。