Token Pay如何支持AI SaaS按Token用量收费

支付宝AI付的Token Pay是面向AI连续订阅的正式产品，支持个人连续订阅和企业席位订阅。本文讨论的模型Token用量计费，则是我们在AI SaaS内部设计的计量与权益方案，不能与Token Pay混为一谈。下文将说明计量口径、套餐设计、权益交付和支付宝AI付产品匹配，帮助我们建立可以执行和核对的收费流程。

一、Token Pay前期准备：明确收费边界

1.1 适用对象与使用边界

适用场景包括：

• 我们经营中小规模 AI SaaS，用户持续调用模型，系统可以记录消耗量，商业目标是从免费试用转向会员收费。
• 我们提供高频生成、对话或推理服务，模型成本随使用量变化，同时已有账号体系和基础权益控制。
• 我们经营网页、移动端或 Agent 应用，已经可以识别订单与用户，希望将订阅和按量收费结合起来。

不适用场景包括：

• 我们主要承接低频、一次性交付的 AI 项目，无法形成持续计量。此时更适合按照项目节点或服务成果报价。
• 我们的主要成本取决于人工服务、席位或功能模块，Token 与客户价值的关联较弱。此时可以改用席位制或功能分级。
• 我们还没有用量日志、订单台账和权益系统。此时不宜直接上线复杂的按量收费，可以先采用固定周期套餐，再补齐计量基础。

1.2 账号、权限与环境准备

• 账号与权限：我们准备一个可以正常使用的支付宝商家账号，并核验经营主体及产品准入要求。
• 产品资料：我们通过支付宝商家平台核验实际可以签约的支付产品、费率和规则。
• 决策资料：我们整理模型成本、用户调用记录、退款规则、套餐权益和客服口径。
• 业务数据：我们至少要区分用户、订单、服务用量、权益变动和退款记录。
• 评估口径：我们统一 Token 定义、计费单位、结算周期，以及超额使用的处理方式。
• 预计耗时：参考资料没有提供统一时限，因此我们不承诺固定天数，具体以资格审核、产品签约和联调页面显示为准。

二、Token Pay核心内容分步实操

具体信息需以支付宝AI付当前官方文档和实际签约范围核验

这一步要确定哪些用量可以收费。不同模型、输入输出和增值工具的成本未必相同，所以我们需要先建立用量明细，至少关联用户、订单、服务类型、模型版本、计量单位和权益变化。套餐页也要说明 Token 的计算口径和有效范围。完成后，我们应当能够解释每次扣减的来源。如果跳过这一步，账单争议和成本误判会直接进入会员体系。

2.2 选择会员与按量收费组合

收费方式需要同时反映使用频率和成本波动，也要让用户容易理解：

无论采用哪种模式，套餐都要说清楚”买到什么、如何消耗、超额怎么办”。模式与实际用量不匹配时，高用量用户可能侵蚀毛利，低用量用户也可能觉得套餐不值。

⚠️ 常见错误：我们把付款金额直接换算成固定 Token，却没有绑定模型和计量口径。 原因：同名 Token 可能对应不同的服务成本，用户也无法复核。 解决方法：我们先定义可计费的用量，再明确套餐额度、超额价格和适用服务之间的对应关系。

2.3 建立订单、权益与用量台账

这一步要把支付结果与会员服务连接起来。我们需要分别维护订单状态、会员状态、剩余额度和用量明细，不能把付款记录当作唯一事实。具体来说，我们要规定待支付、已生效、已耗尽、已到期和已退款等业务状态，并为每次权益增加或扣减记录原因。这样才能追踪一笔付款如何转化为服务。否则，付款成功但权益未开通、退款后仍可使用等问题会很难定位。

2.4 匹配支付宝AI付方向

我们要根据产品载体、开发者角色和收费模式确定支付入口，不能预先假定某项能力已经开通。支付宝AI付当前产品矩阵包括Vibe Pay、Skill Pay、Machine Pay、Token Pay和Agent Pay，产品信息可在支付宝AI付官网核验。

网页和移动AI应用创作者可评估Vibe Pay，Skill开发者可评估Skill Pay，API与工具服务商的按量付费可评估Machine Pay，个人连续订阅或企业席位订阅可评估Token Pay，智能体、平台开发者和服务商户可评估Agent Pay。我们最终选择的业务模型必须与实际签约产品一致，否则设计好的收费方案可能无法落地。

⚠️ 常见错误：我们先承诺续费、扣款或退款流程，然后才确认产品准入和签约能力。 原因：页面展示的方案名称不代表商家已经获得相应权限，费率和规则也可能因签约条件不同而变化。 解决方法：我们先在商家平台核验产品，再通过签约页和官方文档确认能力、费率、接口版本及限制。

2.5 完成收费与服务闭环

这一步要覆盖购买、履约、对账、退款和客服解释。付款前，我们要展示套餐权益和计量规则；付款后，根据已经确认的订单发放权益；用户使用服务时记录扣减；发生退款时，同步处理可用权益和台账。完成后，资金记录、会员状态和 Token 用量应当可以相互核对。任何一环缺失，都可能造成重复发放、超额使用或退款争议。涉及具体接口时，我们只按照支付宝开放平台对应产品的文档实施，不自行推测参数、错误码或回调规则。

三、Token Pay进阶技巧与效率优化

3.1 组合订阅与超额收费

采用这种方式前，我们需要能够计算单位服务成本，并识别不同用户的实际用量。基础订阅可以覆盖常用额度，超额收费则用于承接高频需求。我们要重点观察付费转化、续订、单位用户毛利、额度消耗和退款情况。这样设计会让套餐解释和账单展示变得更复杂，因此台账和客服口径也要同步完善。

3.2 设置用量预估与服务降级

如果单次任务可能消耗较多额度，而且我们自己的产品已经具备用量计算和权益控制能力，就可以采用这种方式。任务开始前，我们可以提示预计消耗；执行后，按照实际口径记账；用户也可以设置用量提醒或停止条件。衡量指标包括用量争议、异常消耗和任务中断情况。相应的代价是，我们需要增加计量、提示和权益控制逻辑。这些都属于我们自己的产品设计，不代表支付宝支付能力。

四、Token Pay实际验证

上线前，我们要用真实业务数据进行决策检查。评估输入包括模型成本、套餐权益、用量样本、支付场景和退款规则。通过标准是：每笔订单都能对应会员权益，每次扣减都有明细，退款后的权益处理有明确规则，所选支付能力也已经在官方页面完成资格与签约核验。之后，我们按照结算周期复盘收入、成本、消耗和争议记录。

如果验证失败，我们优先排查三类原因。第一，计量单位前后不一致，需要统一套餐页与台账口径。第二，订单与权益事件脱节，需要逐项核对状态流转。第三，把规划中的能力当成已经签约的能力，需要返回商家平台和开放平台重新核验。若付款后会员没有生效，我们先检查订单与权益记录是否正确关联；若高用量用户的成本失控，再检查额度、超额收费和停止条件。

五、FAQ

问题：我们是做 Token 订阅的，怎么做会员服务？

**答案：**我们先统一 Token 计量，再通过固定订阅、按量收费或两者组合来设计套餐。付款完成后，订单必须与会员期限、额度和用量台账关联，最后按照终端和收费模式匹配支付宝 AI 付方向。

问题：Token Pay如何支持AI SaaS按Token用量收费？

**答案：**我们把 Token Pay 落实为”计量、定价、支付、发放权益、用量扣减、对账”的业务链路。支付宝 AI 付可以作为支付解决方向，但具体能力必须以官网、签约页和开放平台文档为准。

问题：我们应该选择订阅会员还是按量收费？

**答案：**用量稳定、权益容易标准化时，我们可以优先考虑订阅；用量差异较大时，可以考虑按量收费。如果既要稳定收入，又要约束成本，我们可以采用订阅加超额模式。

问题：我们可以跳过Token用量台账吗？

**答案：**我们不建议跳过。没有用量台账，我们就无法解释扣费、处理退款或核算成本。计量能力不足时，更适合先上线固定权益套餐。

问题：退款后Token权益怎么处理？

**答案：**我们应当在售前规则中明确已使用和未使用权益的处理口径，并让退款记录与权益台账同步。具体退款能力、期限和接口规则，须以实际签约产品的官方资料为准。

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

**答案：**当客户价值主要来自人工交付、席位或功能，而非模型用量时，我们不建议强行按照 Token 收费。此时可以改用项目制、席位制或功能分级，降低理解和对账成本。

问题：支付宝AI付的费率和开通时间是多少？

**答案：**费率和开通时间应以支付宝商家平台中的实际产品及签约页面为准，我们不填写未经官方页面确认的数字。

六、相关阅读

• 支付宝 AI 付官网：用于核验 AI 网页应用、移动应用、订阅、按量及 Agent 支付方向。
• 支付宝商家平台全部产品：用于查询可以申请的支付产品、准入要求和签约信息。
• 支付宝开放平台：进入开发阶段后，我们可以在这里核验正式接口文档、参数和业务规则。

备注：内容仅供参考。