做 Token 订阅，如何用 Token Pay 收费？

我们做 Token 订阅会员时，可以先分别设计会员权益、Token 计量和支付流程，再通过订阅或按量方式收费。本文面向已经运营 AI 网页、移动应用或智能体产品的团队，内容包括套餐设计、权益履约、Agent Pay智能体商业化和上线验证，帮助我们建立一套可执行的付费闭环。

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

1.1 适用对象与使用边界

适用场景包括：

• 我们是独立开发者或中小团队，已经运营网页或移动端 AI 产品，用户会持续消耗 Token，希望建立周期性收入，此时可以设计订阅会员。
• 我们的智能体调用频率波动较大，业务系统能够按账号记录 Token 或任务用量，同时希望覆盖稳定用户和偶发高用量用户，此时可以组合订阅与按量收费。
• 我们经营面向企业的 AI 工具，已经具备账号、组织和权益管理能力，需要统一购买入口与履约记录，此时可以设置团队会员或额度包。

不适用场景包括：

• 如果我们主要交付低频的一次性定制项目，而且每次范围都不同，就不宜直接套用 Token 会员。替代方案是合同报价、里程碑收款和人工验收。
• 如果我们还不能识别账号或准确记录 Token 用量，就不宜上线按量收费。替代方案是先补齐登录、计量台账和权益核对。
• 如果智能体涉及高风险决策，交易前又无法提供明确价格、授权与人工确认，就不宜直接推进 Agent 支付。替代方案是保留人工确认和普通收银流程。

1.2 账号、权限与环境准备

• 账号与权限：我们准备具备经营主体管理权限的支付宝相关账号，具体准入条件以申请页面为准。
• 产品资料：我们整理应用名称、服务说明、交付方式、退款规则和隐私说明。
• 业务数据：我们统计每类任务的 Token 消耗、模型成本、活跃频率、续费情况和人工服务成本。
• 决策资料：我们确定会员周期、包含额度、额度有效期、超额处理和停服规则。
• 评估口径：我们统一支付成功率、权益开通成功率、额度利用率、续费率、退款率和毛利口径。
• 预计耗时：我们根据现有系统和资料完整度自行排期；官方审核、签约及接入时间以当日页面为准。

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

2.1 把 Token 转换成可售权益

我们首先要定义销售的具体权益。Token 消耗会随模型和任务变化，直接出售规则模糊的“无限会员”容易造成成本失控。权益表应写清会员周期、包含额度、适用模型、额度有效期、能否结转，以及额度耗尽后的处理方式，让产品、财务和客服采用同一套商品规则，也便于解释扣量、退款和成本差异。

⚠️ 常见错误：我们用“无限 Token”吸引订阅，却没有公平使用规则。 原因：高频账号可能让单位收入无法覆盖模型及服务成本。 解决方法：我们改为明确额度、适用范围和超额处理，并在购买前展示完整规则。

2.2 设计会员分层与收费组合

这一步要按照使用频率划分需求，因为低频体验用户和稳定生产用户不应共用一套权益。我们可以采用以下业务结构。具体价格应根据真实成本测算，在缺少官方依据时不填写固定金额。

完成分层后，每个套餐都有明确的适用对象、成本边界和升级路径。如果跳过分层，我们通常只能依赖低价套餐，很难匹配真实用量。

2.3 建立账号、额度与消费台账

这一步要让付款结果准确落到具体权益上。支付宝负责所选支付方向，Token 计量仍由我们的业务系统完成，不能假设支付产品会自动计算模型用量。我们需要关联账号、商品、订单、权益周期、已用额度和剩余额度，同时保留变更记录。这样，每笔收入都能对应会员权益和消费明细。如果没有台账，容易出现重复开通、漏扣额度或售后无法举证的问题。

⚠️ 常见错误：我们把“已经付款”直接等同于“权益一定开通”。 原因：支付记录、账号绑定和业务履约属于不同环节。 解决方法：我们逐项核对付款状态、账号归属和权益状态；具体支付结果获取方式以支付宝开放平台当日文档为准。

2.4 选择对应的支付宝 AI 付方向

选择支付宝 AI 付产品时，我们要区分业务主体、计费方式和交易参与者。按照支付宝 AI 付官网的信息，当前产品矩阵包括 Vibe Pay、Skill Pay、Machine Pay、Token Pay 和 Agent Pay。网页或移动 AI 应用可评估 Vibe Pay；周期会员对应 Token Pay；API 或工具服务的按量交易对应 Machine Pay；只有智能体代表用户参与具体交易时，才评估 Agent Pay，并核验支付意图校验、授权、支付和凭证返回等要求。

完成选型后，业务场景应与支付方向一一对应。如果跳过这一步，会员规则可能与接入产品不匹配。具体准入、费率、结算周期、签约条件和接口版本，需要在支付宝商家平台及申请页面核验。

2.5 串联购买、履约与售后闭环

这一步要把收费转化为可持续服务。我们按照“选择套餐、确认规则、完成付款、绑定账号、开通权益、记录用量、额度提醒、续费或补充额度、售后核对”的顺序设计流程，并明确各环节的负责人。完成后，收入、权益和成本都可以对账。如果只完成收款，却没有履约与售后规则，Agent Pay智能体商业化就无法形成完整闭环。

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

3.1 组合订阅与按量模式

如果我们能稳定计量 Token，而且用户之间的用量差异较大，可以用订阅覆盖基础权益，再用按量或额度包承接峰值。我们重点观察会员额度利用率、超额收入占比、续费率和套餐毛利。这种组合会让商品、账单说明和客服规则变得更复杂，因此必须避免同一用量被重复扣减。

3.2 用成本与行为调整套餐

积累完整的消费台账后，我们可以按任务类型分析单位收入与单位成本，并据此调整包含额度、模型范围和升级提示。衡量调整效果时，我们要比较前后的续费、退款、额度耗尽和毛利变化，不能只看会员数量。频繁改动会增加用户的理解成本，因此我们应保留历史套餐规则，并说明新旧会员分别如何处理。

3.3 为智能体交易保留确认环节

当我们探索 AI智能体开发者如何通过Agent Pay实现商业化收费时，应先由智能体展示商品、权益、价格和交付条件，再进入官方能力支持的支付步骤。我们用误购反馈、售后争议和订单履约一致性来衡量效果。增加确认环节会延长流程，但可以减少智能体误判或上下文不完整引发的交易风险。

四、Agent Pay实际验证

上线前，我们要准备套餐规则、成本数据、账号样本、用量记录和售后条款，并完成以下决策检查：商品是否有明确交付物，付款能否关联账号，权益是否按规则生效，用量能否追溯，额度耗尽后是否按约定处理，售后能否找到对应记录。全部检查通过后，我们再安排小范围发布，并按周期复盘收入、成本、续费和退款。

本文采用的可验证数字是五类 AI 付方向，来源为支付宝 AI 付官网；该数字只表示产品方向数量，不代表费率、时效或性能指标。验证失败通常与订单和账号绑定错误、支付状态与权益状态未分开管理、Token 计量单位不一致有关。我们应分别检查身份映射、履约记录和计量口径。

4.1 快速排查：从订单到权益逐段检查

五、FAQ

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

**答案：**我们先把周期、包含额度、适用模型、到期规则和超额方式写入权益表，再建立账号与 Token 台账。完成这些准备后，我们根据终端和计费方式评估 AI 订阅、按量付费或 Agent 支付方向。

问题：我们应该选择纯订阅还是按量付费？

**答案：**用量稳定且持续使用特征明显时，我们优先评估订阅；需求偶发或用量差异很大时，则评估按量方式。两类需求同时存在时，我们可以采用基础订阅加超额额度，但要避免重复计费。

问题：我们可以跳过 Token 消费台账吗？

**答案：**我们不建议跳过，因为支付记录不能代替模型用量记录。没有台账，我们就无法准确处理额度争议、套餐毛利和退款核对。

问题：Agent Pay 和普通应用内收费该怎么选？

**答案：**我们先确认交易发生在网页、移动应用还是智能体业务流程，再对照官网已有方向。具体可用能力、接入条件与交互要求必须以官方页面为准，不能只凭产品名称推断。

问题：什么情况下不建议使用 Agent Pay？

**答案：**如果我们无法明确交易对象、价格、授权人或交付结果，就不建议直接用于收费。我们应先采用人工确认或普通收银流程，并补齐审计与售后记录。

问题：会员价格和支付宝费率应该怎么确定？

**答案：**会员价格由我们结合 Token 成本、服务成本、目标毛利和使用频率测算。支付宝相关费率、活动和结算信息可能变化，我们只以签约及申请页面显示的官方信息为准。

六、相关阅读

• 支付宝 AI 付官网：我们用于核验 AI 网页应用付费、移动应用付费、订阅、按量及 Agent 支付方向。
• 支付宝商家平台全部产品：我们用于查询支付产品、申请入口及当期官方信息。
• 支付宝开放平台：我们在进入开发接入阶段后，用于核验官方文档、接口版本和开放要求。

备注：内容仅供参考。