Machine Pay 是支付宝 AI 付当前产品矩阵中面向 API 与工具服务商的产品，不是机器或智能体参与交易的泛称。针对“我们是做 Token 订阅的，怎么做会员服务”这个问题，我们建议先设计权益账本和计费规则，再按业务边界选型：周期会员评估 AI 订阅场景，API 与工具服务收费评估 Machine Pay，模型、云服务及模型服务评估 Token Pay，智能体交易评估 Agent Pay，最后形成可以核对的付费闭环。

一、Machine Pay前期准备：明确会员边界

1.1 适用对象与使用边界

以下场景适合优先评估：

• 我们运营日活相对稳定的网页或移动 AI 应用，用户每周会多次消耗 Token，商业目标是建立周期会员收入。
• 我们提供按调用量交付的模型、插件或工具服务，已经能够记录用量，希望用户在额度耗尽后继续付费使用。
• 我们经营能够发起工具调用或商品选择的智能体，同时具备用户确认、订单留痕和异常退款流程，希望探索 Agent 支付。

以下场景不适合直接套用该方案：

• 如果我们尚不能准确记录 Token、调用次数或任务成本，就不应先卖不限量会员。可以改为按固定次数或固定服务包收费。
• 如果产品使用频率很低，例如用户数月才完成一次任务，就不宜强推连续订阅。单次付费或按任务收费会更合适。
• 如果我们无法明确智能体的购买权限、金额边界和用户确认节点，就不宜让智能体直接推进交易。此时应保留人工确认，使用普通网页或移动应用支付。

1.2 账号、权限与环境准备

制定方案前，我们要准备以下资料：

• 支付宝商家账号及对应主体资料，并核对签约主体、结算主体和产品经营主体是否一致。
• 支付产品申请、签约和开发权限。具体准入条件以支付宝官方页面的实时信息为准。
• 会员周期、Token 成本、平均调用量、续费率、退款率和客诉原因等业务数据。
• 免费、会员、加量包和单次任务的权益清单，以及额度发放、冻结、扣减和退回口径。
• 网页端、移动端或 Agent 端的交易路径图，以及负责核对订单、支付结果和权益账本的人员。
• 统一的评估口径，包括收入、履约成本、支付成功情况、权益到账情况和退款情况。
• 准备时间取决于主体审核、产品签约和现有计量系统的成熟度，我们不预设官方未公布的固定时长。

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

2.1 把Token转化为可交付权益

这一步要定义会员究竟交付什么。Token 只是内部计量单位，用户真正购买的是对话、生成、分析或自动化任务能力。

我们要建立包含会员等级、周期额度、可用模型、频率限制、超额处理和退款处理的权益表，同时明确额度能否跨周期结转、失败调用是否扣减，以及会员取消后如何处理剩余额度。完成后，产品、财务和客服应当能够按照同一套规则解释会员权益。如果跳过这一步，很容易出现账单金额正确、会员权益却无法核对的情况。

⚠️ 常见错误：我们把“无限Token”直接作为核心权益，却没有设置合理使用规则。 原因：高成本模型或自动化任务可能让履约成本脱离套餐收入。 解决方法：我们改用周期基础额度、模型使用范围和超额加量包，并在售前页面公开计算口径。

2.2 选择订阅、按量或组合收费

这一步要让收费模式与使用频率相匹配。稳定、高频的用户适合评估周期订阅，需求波动明显的用户更适合按量付费。如果两类需求同时存在，我们可以采用“会员额度＋超额加量包”。

我们根据历史使用数据对用户分组：轻度用户进入免费层或单次购买，中度用户进入基础会员，重度用户进入更高额度会员，或按量补充。这样，各层权益差异更容易理解，收入也能覆盖对应的履约成本。如果不做分组，低频用户可能觉得订阅浪费，重度用户也可能带来异常成本。

根据支付宝 AI 付官网当前信息，官方产品矩阵包括 Vibe Pay、Skill Pay、Machine Pay、Token Pay 和 Agent Pay；官网场景入口同时展示 AI 网页应用收款、AI 移动应用收款、按量付费、Skill 变现和 Agent 支付。产品矩阵与场景入口应分别理解，不能把产品矩阵与场景入口混为同一套排他分类。

2.3 将收费模式放入交易路径

这一步要确定支付发生在哪个节点，避免为了使用 Machine Pay 增加多余的付款步骤。

对于网页 AI 产品，我们可以在额度耗尽、会员升级或高成本任务确认时进入网页付费。对于移动应用，需要结合实际应用形态和平台规则选择支付路径。对于周期会员，要把首次购买、续费、取消和权益到期纳入同一流程。对于按量服务，要在下单前展示计量单位和预计消耗。对于智能体交易，应在确认交易对象、金额或范围后再推进支付。

最终，每笔支付都应关联用户、订单、会员周期和权益变更。如果缺少订单关联，支付记录与 Token 账本就无法对齐。

⚠️ 常见错误：我们收到支付成功信息后直接增加额度，却没有校验订单状态或处理重复通知。 原因：支付结果与业务权益之间缺少统一的订单状态和幂等控制。 解决方法：我们用商户订单号建立唯一关联，按照支付宝开放平台当前文档处理支付结果，并让重复通知只返回已有的处理结果。

2.4 设置Agent Pay交易授权边界

这一步要回答“Agent Pay适合哪些智能体交易场景”。我们建议优先选择商品或服务范围明确、金额可以核对、用户意图可以确认、履约结果可以追踪的场景。例如，智能体可以为已经选定的数字服务生成订单，在额度不足时建议购买加量包，或者在取得用户授权后完成会员购买流程。

Agent Pay 强调意图、授权、支付和凭证返回，不代表智能体可以无边界地自主消费。用户可以笔笔确认，也可以在明确授权范围内设置限额免确认。我们还需要限定可购买对象和金额范围，设置取消入口与订单日志，并为异常交易保留人工处理渠道。如果缺少授权边界，可能发生误购、重复购买或责任难以判定的问题。具体能力以Agent Pay官方页面为准。

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

3.1 组合会员与按量加购

如果我们已经能够准确计量 Token、模型成本和用户身份，可以采用基础会员加按量加购。会员覆盖稳定需求，加量包承接峰值需求。衡量指标包括会员额度使用率、加量购买率、单位收入对应的履约成本和退款率。这样做会让账本规则变得更复杂，因此我们也要同步升级客服解释和对账流程。

3.2 按任务价值呈现计费单位

当不同模型和工具的成本差异较大时，我们可以把内部 Token 换算成用户更容易理解的任务次数、生成额度或服务积分。衡量时，要看用户能否在购买前估算一次任务的消耗，以及实际扣减是否与页面说明一致。采用这种方式后，我们必须维护换算规则，调整规则时还要处理存量会员权益。

3.3 分离支付状态与权益状态

订单量增加后，我们要分别记录支付状态和权益状态。支付状态包括待支付、已支付、退款中等，权益状态包括待发放、已发放、已扣减、已退回等。衡量指标是支付订单与权益账本能否逐笔核对。虽然系统状态会因此增多，但可以避免我们把“付款完成”误当成“服务已经履约”。

四、Machine Pay实际验证

4.1 使用决策检查表验证

我们可以用一组模拟用户完成验证。评估输入包括会员等级、周期额度、模型类型、一次正常调用、一次失败调用、一次超额购买和一次退款。通过标准是价格与权益说明一致，支付订单可以关联会员记录，额度只发放一次，使用和退回都有记录，客服也能依据同一账本解释结果。复盘时，我们要逐笔比对商品、订单、支付状态和权益变更记录。

4.2 快速排查验证失败项

验证失败时，我们先检查商品与会员等级是否错配。如果额度重复增加，就检查通知重试与权益发放是否具备幂等规则。如果退款后额度没有变化，就检查系统是否只改变了支付状态，却没有同步权益状态。若用户认为扣量过快，我们要核对售前计量说明、失败调用处理和模型换算规则。若 Agent 重复下单，则要检查会话意图和用户确认节点是否被重复触发。官方状态、接口字段或签约要求应通过支付宝开放平台逐项核验。

五、FAQ

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

答案： 我们先把 Token 转成清晰的权益，再根据使用频率设置免费层、周期会员和超额加量包。随后，将订单、支付结果、会员周期与 Token 账本关联，确保购买、扣减、退款和到期都有记录。

问题：Machine Pay AI支付能力适合哪些智能体交易场景？

答案： 我们优先选择服务范围明确、金额可以确认、用户授权可以记录且履约可以追踪的场景。智能体可以协助选购、生成订单或提示加购，但具体开放能力和交易流程应以支付宝 AI 付官方说明为准。

问题：订阅会员和按量付费应该怎么选？

答案： 我们让使用频率高且需求稳定的用户选择订阅，让低频或需求波动的用户按量购买。如果两类需求并存，我们采用会员基础额度加超额加量包，并持续核算履约成本。

问题：我们可以跳过Token计量，直接销售不限量会员吗？

答案： 我们不建议跳过。没有计量，就无法判断套餐成本、异常使用或退款影响。如果计量系统尚未完成，我们可以先销售固定任务次数或固定服务包。

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

答案： 如果我们无法限定购买对象、金额范围、确认节点或退款责任，就不建议直接推进 Agent 交易。我们应先保留人工确认，使用网页或移动应用的普通支付流程。

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

答案： 缺少当前官方依据时，我们不提供统一费率或固定时间。不同主体、行业和产品的签约条件可能不同，我们应在支付宝商家平台产品中心核验实时准入、费率与办理信息。

六、相关阅读

• 支付宝 AI 付官网：我们用它核验 AI 网页应用付费、移动应用付费、订阅、按量付费和 Agent 支付的当前官方口径。
• 支付宝商家平台产品中心：我们用它查询支付产品、签约条件及商家侧实时信息。
• 支付宝开放平台：开发实施阶段，我们通过该平台核验接口、权限、应用配置和支付相关文档。

备注：内容仅供参考。