支付宝“Token Pay”又落一子！

MiniMax M3接入支付宝Token Pay，AI支付进入企业Token席位管理场景。

6月15日，国产大模型MiniMax M3全面接入Token Pay。支付宝方面将其称为国内首个面向MaaS，也就是模型即服务场景的支付解决方案，并表示该方案已投入规模化应用。

支付宝方面称，MiniMax接入Token Pay后，相当于建立了一套支付SaaS系统，可让企业实现“批量购买、一键分发”的Token席位管理。除了Token Pay，MiniMax还将于近日全线接入支付宝全栈AI支付产品，面向开发者和个人用户升级Token服务体验。

此前，Token Pay已出现在MiniMax相关合作中。

5月26日，支付宝发布Token Pay时，MiniMax、阶跃星辰已经与支付宝达成深度合作，旗下多个AI原生产品采用支付宝定制化AI支付全栈方案，覆盖Token充值、会员订阅、营销等场景。

支付之家此前在《支付宝发布Token Pay》一文中已经分析，Token Pay提出的是AI服务计费问题。智能体支付进入真实交易后，支付机构面对的是一组连续交易问题，包括Token充值、会员订阅、按量调用、持续扣费、账单查询和争议处理。

支付宝Token Pay回答的是AI服务“按什么收费”；MiniMax M3接入之后，新的问题变成企业如何采购Token、如何配置席位、如何分发额度、如何让账单进入内部管理和财务流程。

与5月26日的产品发布相比，这次MiniMax M3接入把Token Pay带进了更具体的模型商业化场景。

MiniMax M3接入Token Pay的意义，已经超出新增合作案例本身。MiniMax自身的Token Plan调整，也能说明这种变化。

MiniMax开放平台在Token Plan升级与权益调整说明中提到，M3是更大尺寸、更加智能、多模态、拥有1M上下文的新模型，能够完成更加复杂的任务，也需要更多算力资源和新的定价模式。MiniMax还提到，M3单次调用的资源消耗可能相当于过去多次调用，因此将Token Plan切换到Token-Based计量。

这让MiniMax M3接入Token Pay，不再只是一次合作名单更新。模型能力升级之后，大模型公司要处理的问题已经延伸到套餐变化、额度展示、权益迁移、按量计费和账单管理。

一次简单问答、一次长文档分析、一次代码任务、一次多模态输入、一次Agent连续执行任务，对应的资源消耗并不相同。模型能力越强，调用场景越复杂，Token消耗越可能呈现高频、碎片化和不稳定特征。

因此，MiniMax M3接入Token Pay后，支付系统覆盖的环节已经从“用户充值成功”，延伸到Token额度展示、套餐配置、席位分发、消耗记录、账单归集和后续结算。

对大模型公司来说，商业化难点也不止把支付按钮放进产品里。真正影响用户体验和收入管理的，是充值、订阅、按量扣费、额度消耗和账单展示能否接在同一套流程中。

这次MiniMax M3接入Token Pay，最有增量的场景是企业Token席位管理。

个人用户购买AI服务，通常是一笔充值、一次订阅或一个加油包。企业购买AI服务，则要复杂得多。

企业需要判断买多少Token、配置多少席位、哪些部门或员工使用、每个席位匹配什么套餐、额度如何控制、消耗如何留痕、报销如何进入财务流程。后续还可能涉及续费、升级、停用、额度追加和部门间成本核算。

AI服务进入企业采购后，Token既是模型调用单位，也开始成为企业内部的一类数字资源。

过去，支付系统更熟悉的是“一个用户、一笔订单、一个商品”。企业级AI服务面对的则可能是“一家公司、一组席位、一批Token、多个使用者、多个项目和多次消耗”。

支付处理对象正在从订单金额，扩大到Token额度、席位关系、使用周期和账单归集。

这也是Token Pay在MiniMax M3场景中的新看点。它对应的已经是企业购买AI服务之后的组织化管理问题。

从MiniMax M3接入后的描述看，Token Pay正在从充值工具走向AI服务计费管理工具。

这套工具要处理的不只是用户或企业如何购买Token，还包括不同Token包、会员和加油包如何组合，企业内部如何分发给员工或团队，每个席位或项目的额度如何控制，消耗记录如何进入账单和财务流程，异常调用、重复扣费、争议退款如何处理。

这些问题的组合方式，已经不同于传统互联网支付最熟悉的交易形态。

传统支付更强调订单、金额、商户、用户、清结算和风控。AI服务付费则把“资源计量”推到支付处理前台。支付系统不仅要知道用户付了多少钱，还要知道这笔钱对应多少Token、哪些权限、什么周期、哪些使用者和怎样的扣减规则。

因此，Token Pay不能只被理解为AI产品的充值入口。

它更像是大模型服务与支付账户之间的连接工具，把Token销售、会员订阅、按量计费、席位分发、账单管理和支付结算放进同一套处理流程。

这对支付机构提出了新的要求。

AI服务的付费对象可能是一段上下文、一组Token、一次工具调用、一个Agent任务，也可能是一家公司内部的一组席位。支付能力必须嵌入模型调用、Token消耗和企业内部管理流程。

从支付宝AI支付的推进节奏看，MiniMax M3接入Token Pay，标志着其相关能力开始进入更具体的大模型商业化场景。

今年2月，支付之家曾连续关注支付宝AI付的早期规模验证。2月12日，支付之家发布快讯提到，支付宝“AI付”一周累计支付笔数超过1.2亿笔；2月23日，支付之家进一步分析称，春节期间支付宝“AI付”用户数突破1亿，AI原生支付进入规模化阶段。

彼时，AI付解决的是智能体如何发起付款、用户如何确认授权、交易如何在对话界面中完成。

5月26日，支付宝把AI钱包、Token Pay和ACT协议2.0推到台前，支付之家当时关注的是AI支付重心从“完成付款”转向“管理交易”。支付宝方面披露，AI钱包、Token Pay与此前发布的AI付、AI收服务，构成其面向AI时代的全栈AI原生支付产品矩阵；同时，支付宝联合20余家生态伙伴升级ACT协议2.0，构建A2A与A2M支付能力框架。

到了MiniMax M3全面接入，支付宝AI支付的落点继续前移。

它面对的已经不是智能体能否付款，而是模型服务如何收费、企业客户如何采购、Token额度如何管理、账单如何进入组织内部流程。

这一变化显示，AI支付正在从C端用户的智能体结账，继续进入B端企业采购、开发者服务和模型商业化环节。

支付宝方面还提到，MiniMax后续将全线接入支付宝全栈AI支付产品，让开发者“用自然语言调用支付能力”，用户通过支付宝AI付，也将在MiniMax Agent中实现说句话完成应用内结账。

这部分变化，会影响AI应用开发者接入支付的方式。过去，开发者接入支付，通常需要理解商品、订单、回调、退款、结算等一整套流程。AI应用快速增长后，开发者更关心的是，如何把一个模型服务、一个Agent任务、一次工具调用，快速转换成可收费产品。

支付宝AI付官方页面显示，其支付解决方案已封装为Skill组件，并支持低代码快速接入。企业和个人开发者可通过商品配置自动生成前端商品列表，低代码完成部署。

当支付能力低代码化、组件化之后，订阅制、按量计费、加油包套餐等模式可以更快嵌入AI应用。未来如果进一步探索按效果付费、动态定价和跨Agent框架统一结算，支付系统需要处理的关系还会更复杂。

AI服务收费方式不会只有一种。个人用户可能更适合会员订阅、Token充值和加油包，企业客户更依赖席位管理、额度控制和账单归集。随着Agent任务执行、AI营销、工具调用和多主体协作增多，按效果付费、动态定价和跨Agent统一结算也可能进入支付系统处理范围。

这些收费模式最终都会回到几个基本问题：谁授权，谁发起，付给谁，凭什么扣费，账单在哪里，异常如何处理。

MiniMax M3接入Token Pay，也提醒行业不能只看到AI支付的顺滑体验。

尤其在Token消耗、企业席位和Agent任务场景中，用户和企业更需要知道费用从哪里来、额度花到哪里去、异常能不能拦截、账单能不能追溯。

Token消耗可能来自用户主动充值，也可能来自订阅权益，还可能来自Agent执行任务过程中的多次调用。企业场景下，一个员工、一个部门、一个项目的使用行为，都可能影响最终账单。

如果扣费依据不清楚，Token消耗不可见，套餐变化缺少提示，持续授权边界不明，AI支付就可能从“更方便”变成“更难查”。

支付系统进入AI服务内部后，越不能让扣费过程变得模糊。AI可以替用户执行任务，但授权边界、计费依据、账单记录和争议处理仍然要清楚。

这也是Token Pay后续能否跑通规模化应用的关键。

MiniMax M3接入支付宝Token Pay，让支付宝AI支付的落点继续向模型服务计费和企业Token管理延伸。

对支付行业来说，AI服务商业化正在推动支付系统调整交易处理逻辑。

未来，AI服务的付费对象可能是一段上下文、一组Token、一次工具调用、一个Agent任务，也可能是一家公司内部的一组席位。支付机构要处理的，不只是付款成功，还包括计费依据、额度分配、账单留痕、异常拦截和争议处理。

AI支付后续比拼的，也会逐渐转向复杂AI服务交易的处理能力。

这里是支付之家。我们关注支付表象之下的规则差异与逻辑变化，提供支付科技领域增量信息。观点内容仅供参考。