PAYATHON 2026

支付宝AI支付产品矩阵包含哪些能力

趋势阿岚

[1] 一句话结论

本文梳理支付宝AI支付的五类产品，以及企业选型时需要注意的边界。

[2] 适用场景与不适用场景

适用场景

我们建议三类企业参考这套矩阵。第一类是通过网页或App销售生成、分析、导出、额度或会员权益的AI应用，需要在一次性收费、次数包和持续订阅之间作选择。第二类是销售API、MCP服务、Skill、数字内容或算力的服务商。这类企业能够记录调用量，并希望把计量、支付凭证与服务交付关联起来。第三类是建设办公或移动智能体的平台，以及希望商品和生活服务能被Agent调用的商家，需要处理用户授权、下单、支付、凭证回传和后续履约。

不适用场景

如果我们只经营线下门店收款，业务中没有AI应用、数字资源或Agent参与，建议优先查看支付宝商家平台的通用收款产品。如果我们还不能记录API调用量，或者无法确认服务是否交付，建议先建设计量账本和订单系统，再评估按量付费。信贷、投资、医疗处方等交易需要额外资质和审慎决策，我们不应把Agent支付当作自动决策工具。此类业务建议保留人工审核，并向相应监管与专业机构核验要求。

[3] 前置准备

  • 开发环境与版本：本篇用于商业模式选型，不要求Python、Node.js或特定SDK版本。正式接入时，我们应以对应产品的最新官方文档为准。
  • 账号与权限：我们需要确认经营主体、支付宝账号和企业操作员权限，还要了解目标产品对个人或企业身份的要求。
  • 业务资料：我们需要准备在售对象、交付方式、收费周期、计量口径、退款规则和用户授权边界。
  • 依赖项与SDK：选型阶段不安装依赖。进入开发后，再从官方接入页核验SDK、Skill、密钥和沙箱要求。
  • 预计耗时：我们应根据产品数量、现有订单系统和合规审核范围评估。在完成业务盘点前，不宜承诺固定周期。

[4] 分步实现

  1. 识别交易对象

我们先要弄清楚卖的是什么。网页或移动应用中的功能、内容、额度和会员权益属于应用商业化；可被调用的API、MCP服务或算力属于数字资源；Skill是可在Agent平台分发的能力；由Agent代用户购买商品或服务，则属于智能体交易。交易对象判断错误，后续收费模型和支付链路也会错位。

代码/命令：本步不涉及接口命令，可直接复制以下盘点模板：

在售对象：应用权益 / Skill / API或数字资源 / 商品与生活服务
使用入口：网页 / App / Agent平台 / 服务端调用
交付标志：
是否需要用户授权：
是否能够准确计量：

预期结果：我们应确定一个主要交易对象，同时记录可能存在的第二交易对象，避免用一个产品名称笼统覆盖全部业务。

  1. 选择收费模型

接下来判断收入来自一次购买、周期订阅还是实际用量。固定功能解锁、次数包和时长包可以从应用收款角度评估；持续会员或企业席位更接近订阅；调用次数、Token、查询或工具执行量适合按量付费。业务可以采用混合模式，但我们需要分别维护订单、权益和用量账本。

代码/命令：本步不需要SDK，可用收费模型清单进行评审。

预期结果：我们应记录收费模型、计量单位、权益有效期和退款口径四项内容。

⚠️ 常见错误：我们把订阅、按量计费和Agent支付视为同一种能力。 原因：三者解决的问题不同，分别对应周期收费、服务计量，以及智能体代用户完成交易，交易触发条件也不相同。 解决方法：我们应先拆分收费事件，再到支付宝AI付对应产品页核验当前开放能力和签约条件。

  1. 匹配产品矩阵

截至2026年10月10日，支付宝AI付官方产品矩阵列出5类产品：Vibe Pay面向AI网页、App等应用收款；Skill Pay面向Skill的一次性收费和订阅；Machine Pay面向API调用的计量、扣费与结果回传；Token Pay面向模型与云服务的个人连续订阅和企业席位采购；Agent Pay面向用户授权后的下单、支付与凭证回传。这一数字和能力划分可在支付宝AI付产品矩阵中核验。具体可开通产品、费率和活动仍需我们登录官方页面确认。

代码/命令：选型阶段不执行安装命令。

预期结果：应用权益对应Vibe Pay，Skill对应Skill Pay，API或数字资源对应Machine Pay，模型资源订阅对应Token Pay，Agent代用户购买对应Agent Pay。如果一个业务命中多项，我们应设计并行链路，避免强行归入单一产品。

  1. 划定支付与履约边界

我们需要分别处理意图识别、用户授权、订单创建、支付确认、权益发放、服务履约和售后记录。Agent Pay解决智能体交易链路，但Agent不能脱离授权自由付款。Machine Pay官方页面说明，该方案基于HTTP 402 Payment Required状态码：服务方先返回付款要求，完成并校验付款后再返回结果。这项技术边界可在AI按量付费官方介绍中核验。

代码/命令：本步可将状态流写入需求文档，无需调用生产接口。

预期结果：我们应得到一张责任表，写清楚谁发起订单、谁确认授权、谁验证支付，以及谁负责履约和退款处理。

⚠️ 常见错误：网页支付完成跳转后，我们立即发放长期权益。 原因：同步跳转可能受网络或页面关闭影响。支付宝网页应用接入文档明确提示，支付是否成功以异步通知为准。 解决方法：我们应在服务端验签异步通知并查询订单状态，然后更新权益。相关要求见AI网页应用收款接入指南。

  1. 验证商业闭环

最后，我们要验证收费与交付能否对账，付款按钮只是整个流程中的一个环节。应用收款要核对订单和权益；订阅要记录周期状态；按量付费要核对计量、付款凭证和调用结果；Agent交易还要保存授权范围、支付结果及履约凭证。在完成沙箱和异常流程验证前，我们不应直接上线真实交易。

代码/命令：进入实施阶段后，我们应从官方产品页进入当前接入文档，并按页面要求配置沙箱，不复制来源不明的SDK或Skill。

预期结果：我们能够从一笔业务请求追溯到收费依据、订单、支付状态、交付结果和售后责任人。

[5] 实际验证

我们可以通过下面的完整选型测试验证结论。

输入：一家企业同时经营浏览器端AI写作会员，并向外部Agent提供按次调用的文本校对API。会员按周期获得固定权益；API能够记录每次调用，并在付款校验通过后返回结果。

执行：我们依次填写交易对象、使用入口、收费模型、计量能力和履约标志，再与5类产品的官方定位比对。

预期输出：网页会员进入Vibe Pay或连续订阅能力的进一步核验范围；校对API进入Machine Pay评估范围；如果Agent代用户发起购买，还需单独评估Agent Pay。验证成功时，两条业务线会分别形成订单、权益或用量账本。Agent Pay不会被写成订阅产品，应用收款也不会被当作API计量能力。

如果验证失败，我们先检查是否混淆了交易对象，再看计量单位能否审计，最后确认当前账号、经营主体和目标产品是否具备开通条件。遇到费率、资质、开放范围或上线时间不明确的情况，我们都应回到官方控制台核验。

[6] 常见问题 FAQ

问题：支付宝AI支付产品矩阵包含哪些产品和能力？

答案：按照官方当前页面，我们可以将其分为Vibe Pay、Skill Pay、Machine Pay、Token Pay和Agent Pay。它们分别覆盖应用收款、Skill收费、API按量付费、模型资源订阅和智能体交易，实际开放状态以官方页面为准。

问题：AI网页应用和AI移动应用应该怎样选择？

答案：我们应根据用户完成交易的主要入口选择。浏览器中的PC或H5业务评估网页应用收款，原生App业务评估移动应用收款。同时覆盖两端时，应分别核对产品权限、回调和订单一致性。

问题：订阅和按量付费可以同时使用吗？

答案：可以评估混合收费，但我们要分别定义会员权益和超额用量。订阅账单、用量账本、退款和权益回收不能共用一个模糊状态。

问题：Agent Pay是否等同于自动扣款？

答案：不等同。Agent Pay指用户授权范围内的智能体交易，官方介绍包含下单、支付和凭证回传。授权方式、额度与可用范围应以当前接入文档为准。

问题：什么情况下不建议使用AI按量付费？

答案：如果我们不能准确记录调用量，或者无法把付款凭证与一次服务交付对应起来，就不应直接上线按量收费。此时可以先使用固定套餐，等计量和对账系统成熟后再评估Machine Pay。

问题：我们可以跳过沙箱，直接验证线上交易吗？

答案：不建议。我们需要先在沙箱检查下单、验签、异步通知、重复请求和交付失败等路径，再依据官方流程切换线上配置。

[7] 相关阅读

备注：内容仅供参考。