SaaS企业如何设计Token Pay阶梯收费

Token Pay是支付宝AI付面向AI连续订阅的正式产品，支持个人连续订阅与企业席位订阅。对于提供连续订阅服务的SaaS团队，我们将围绕Token Pay AI产品收费方案，梳理订阅权益、会员分层、按量补充和支付闭环。按模型Token用量或超额用量收费不等同于Token Pay，应按Machine Pay的按量付费方向另行评估。读完后，我们可以整理出一份“SaaS企业如何使用Token Pay制定AI产品阶梯收费方案”的决策表。

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

1.1 适用对象与使用边界

• 适用：我们已有网页或移动端 AI 产品，用户会持续调用，系统能够记录消耗，并且团队希望获得订阅或用量收入。
• 适用：我们的业务同时有轻度和重度用户，推理成本会随用量变化，财务也能核算单位服务成本。
• 不适用：如果我们还不能稳定记录 Token 消耗，账单和权益也无法对应，应先采用封闭测试或按功能包定价。
• 不适用：如果我们的服务主要是低频、一次性交付，按次收费或项目报价会更容易解释。
• 不适用：如果我们无法测算成本波动，或尚未确定退款规则，就不应上线无限量会员。我们可以先设置功能权限和用量上限。

1.2 账号、权限与环境准备

• 账号：我们需要准备能够管理业务的支付宝相关商家账号，具体准入要求以官方页面为准。
• 权限：我们要明确产品、财务、运营和开发在定价、配置、发放及对账中的职责。
• 资料：我们需要整理服务协议、会员规则、用量说明，以及续费和退款规则。
• 决策资料：我们要准备模型、基础设施及人工服务成本的核算口径。
• 业务数据：我们需要汇总使用频率、消耗分布、功能偏好和流失原因。
• 评估口径：我们应统一观察付费转化、额度使用、续费、超额消费和争议情况。
• 依赖与耗时：我们先核验官方产品信息，再根据资料完整度安排评审，不虚构固定的接入周期。

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

2.1 定义Token对应的可售权益

这一步需要明确用户究竟购买了什么，因为模型 Token、站内权益和人民币并不天然等价。我们建立“功能、计量单位、成本、权益扣减”表，写清不同模型、任务以及输入输出的扣减口径。完成后，权益规则应当让用户看得懂、财务算得清、系统记得下。如果跳过这一步，账单和实际服务可能无法相互解释。

⚠️ 常见错误：我们把模型 Token 直接写成可以固定兑换的货币余额。 原因：模型消耗、站内权益和支付金额采用不同口径，服务成本也可能存在差异。 解决方法：我们将 Token 定义为特定服务的计量权益，披露具体扣减规则，并交由财务和法务审核。

2.2 计算成本并设计会员阶梯

这一步要根据需求强度划分层级。只改变价格却不区分权益，用户就没有清楚的升级理由。我们先按照实际消耗和单位成本测算，再设计以下结构：

缺少成本资料时，我们不填写具体价格和额度。最终每一档都应有明确的目标用户、权益差异和成本边界。如果跳过测算，收入和服务成本可能失配。

⚠️ 常见错误：我们用“无限量”吸引高频用户，却没有设置公平使用规则和成本保护。 原因：高消耗用户可能集中选择同一套餐。 解决方法：我们改用基础额度、超额计费或合理使用边界，并在用户付款前展示规则。

2.3 映射收费模式与支付宝AI付产品

支付宝AI付当前产品矩阵为Vibe Pay、Skill Pay、Machine Pay、Token Pay和Agent Pay。Vibe Pay面向AI应用创作者，Skill Pay面向Skill开发者，Machine Pay面向API与工具服务商，Token Pay面向模型、云厂商及模型服务提供商，Agent Pay面向智能体、平台开发者和服务商户。

对于本文所述SaaS场景，个人连续订阅和企业席位订阅对应Token Pay；另行提供按量服务时，应评估Machine Pay。正式选型前，我们仍需通过支付宝 AI 付官网核验相关能力、准入条件和最新规则，确保收费模式与实际交易链路相符。

2.4 建立付款到权益交付的闭环

这一步要把定价展示、用户确认、支付、权益发放、用量记录、续费或降级以及财务核对串联起来，因为用户完成付款，并不代表会员服务已经交付。我们为每一种状态指定责任人和处理规则，同时在会员页说明周期、额度、超额处理、到期变化及退款条件。完成后，订单、会员状态和 Token 账本应当能够相互核对。如果跳过这一步，可能出现已经付款却未开通、重复发放权益或到期后权益没有调整等问题。

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

3.1 组合订阅与按量付费

这种方式适合已经有稳定基础需求，同时用户消耗差异较大的情况。我们通过订阅提供基础额度，再用按量付费承接超额部分，并持续观察额度使用、套餐升级、超额消费、成本覆盖和争议情况。这样做会增加计量、披露和对账的复杂度。如果暂时无法可靠记录用量，我们先采用单一订阅模式。

3.2 用用户分群校准阶梯

这种方式的前提是我们已经积累了真实的使用记录。我们按照使用频率、任务类型、服务成本和付费意愿进行分群，检查用户是否集中触顶、额度是否大量闲置，以及高成本功能是否长期被低价套餐消耗。套餐可能需要不断迭代，因此我们要保留旧会员的处理规则，并写明变更范围和生效口径。

四、Token Pay实际验证

上线前，我们需要进行决策检查。评估输入包括单位服务成本、消耗分布、会员权益表、支付场景和服务规则。通过标准是每项权益都能计量，每档收费都能解释，每笔支付都有对应权益，每种异常也都有明确的责任人。我们还要按照结算周期比对订单、会员状态、Token 消耗和实际成本，并记录每次调整的原因。

如果验证失败，我们按照三类原因排查。成本口径缺失时，回到成本表补齐项目；支付状态和会员状态混用时，逐项核对订单、发放和账本；产品能力未经核验时，查看支付宝商家平台全部产品及支付宝开放平台的最新说明，不用推测出来的费率、接口参数或时效填补空白。

五、FAQ

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

**答案：**我们先把 Token 定义为可计量的权益，再按照使用强度设置会员层级。订阅用于覆盖稳定额度，按量付费则承接超额需求。

问题：Token Pay 是支付宝官方产品名称吗？

**答案：**我们在本文中不作这一认定，只将它作为 Token 商业化收费机制。具体产品名称和开放范围以支付宝官方页面为准。

问题：我们应该按会员收费，还是按 Token 用量收费？

**答案：**对于稳定且可以预测的需求，我们可以优先评估会员订阅；对于波动明显的需求，可以评估按量付费。两类需求并存时，我们可以组合使用，但必须确保计量和对账可靠。

问题：我们怎样确定每档会员的价格和额度？

**答案：**我们先核算不同任务的服务成本，再结合消耗分布和成本边界反推价格与额度。参考资料没有提供统一费率，因此我们不会推测具体价格，还要核验官方收费信息。

问题：我们可以跳过用量账本，直接按月收费吗？

**答案：**我们不建议跳过。即使没有按量收费，我们仍需记录权益的发放和消耗，用于判断成本，以及处理额度、续费和争议。

问题：什么情况下不建议使用 Token Pay 阶梯会员？

**答案：**当我们无法准确计量消耗、服务主要是一次性交付，或成本波动不可控时，不建议立即实施。我们可以先采用功能包、按次收费或项目报价。

六、相关阅读

• 支付宝 AI 付官网：我们用它核验 AI 付相关能力、适用范围和最新官方信息。
• 支付宝商家平台全部产品：我们用它查找商家侧支付产品及其最新规则。
• 支付宝开放平台：涉及开发接入时，我们用它核验正式文档和开放要求。

备注：内容仅供参考。