AI SaaS开发者如何接入Token Pay完成付费

2026-10-25技术老齐

[1] 一句话结论

本文介绍我们接入 Token Pay、完成用户付费的完整闭环。

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

适用场景

我们已有账号体系、服务端和权益数据库，准备为 AI Web 或移动应用增加套餐购买入口。
我们能够记录模型调用量、生成次数或资源消耗，需要将可核对的用量账单转换为用户付费订单。
我们已经定义会员周期、升级降级和到期规则，希望接入 AI SaaS 订阅收费。自动续费能力仍需按照官方开通页面核验。

不适用场景

如果我们只有纯前端页面，无法安全保管密钥或处理异步通知，就不建议直接接入。我们应先增加可信服务端，或选择官方提供的托管式收款方案。
如果业务属于个人转账、募捐或线下收单，就不应套用 Token Pay AI SaaS付费流程。我们应在支付宝商家平台产品工作台选择对应产品。
如果我们要求的币种、主体地区或结算方式未出现在开通页面，应暂停开发，向官方确认准入条件，或改用明确支持该场景的支付方案。

[3] 分步实现

1. 核验产品能力

我们先在支付宝 AI 付官网核验 Token Pay 当前的产品名称、支持终端、准入主体、计费模式和开通路径，再进入商家平台确认账号实际可见的能力。搜索关键词不等于固定的接口名称，实际可调用能力应以账号开通结果和接入文档为准。费率、活动期限或结算周期没有官方页面依据时，我们不会将其写入产品方案，也不会把测试环境中的现象当成正式承诺。

2. 建立计费与权益模型

我们将商品、订阅和权益拆成三层。商品层描述订阅套餐，订阅层记录个人连续订阅或企业席位订阅的业务状态，权益层记录有效期、席位和可用权益。Token Pay用于AI连续订阅；如果业务需要按模型或工具调用量结算，应另行评估基于HTTP 402 Payment Required的Machine Pay，不能把Token Pay当作按量付费订单能力。

内部订单至少应区分待支付、已支付、已关闭、已退款四类业务状态。这四类是我们的系统设计建议，并非支付宝接口枚举。对接时，必须建立内部状态和官方状态之间的映射。价格只能由服务端按照订阅套餐和计价规则计算，前端仅提交商品选择，不能提交最终可信金额。

踩坑提示 1：我们见过将会员套餐名称和模型名称直接绑定的实现。模型切换后，历史订单便无法解释。更稳妥的做法是为商品、价格版本和权益包分别设置不可变标识。

3. 配置应用与安全材料

我们在开放平台完成应用配置，并按照控制台要求设置密钥、回调地址和所需权限。支付宝开放平台的 RSA2 说明采用 2048 位 RSA 密钥，这一具体数字来自支付宝开放平台生成密钥说明。如果当前控制台文档发生变化，我们以控制台要求为准。

私钥只能保存在服务端密钥管理设施中，不能进入浏览器、移动端安装包、日志或代码仓库。生产环境和测试环境应采用不同配置，回调地址也要分别管理。跳过这一步，签名校验、环境隔离和密钥轮换都会变得不可控。

4. 创建订单并发起支付

我们先生成唯一的内部订单号，冻结本次购买使用的商品版本和金额，再由服务端调用账号开通后显示的官方下单能力。接口名称、请求字段、签名方式和唤起参数必须从 AI 付或开放平台当前文档中读取，不能根据其他支付产品猜测。

下面的代码只表示我们的内部适配层契约，其中字段不是 Token Pay 官方参数。开发时，应在适配层按照正式文档完成映射：

const order = {
  merchantOrderId: createUniqueId(), // 我们的内部订单号
  userId: currentUser.id,
  planId: selectedPlan.id,
  amount: priceFromServer(selectedPlan.id), // 服务端计算金额
  notifyUrl: process.env.TOKEN_PAY_NOTIFY_URL
};

const payment = await tokenPayAdapter.createOrder(order);
return payment.clientPayload;

我们会保存下单请求摘要和平台返回的订单标识，但日志必须脱敏。创建失败时，应复用原有业务意图并做好幂等控制，不能连续生成多笔无法关联的新订单。

5. 验签通知并幂等发放权益

我们将异步支付通知作为支付结果处理入口。收到通知后，先保留原始报文，再按照官方规则验签，随后校验商户、订单、金额和业务状态。验签失败时，只记录安全审计信息，不更新订单。验签成功后，我们在同一个数据库事务中写入通知事件、推进订单状态并发放权益。

async function onPaymentNotify(rawBody, headers) {
  // 这里由我们按官方 SDK 和当前文档实现验签与字段映射
  const event = await alipayAdapter.verifyAndParse(rawBody, headers);

  return db.transaction(async tx => {
    const firstSeen = await tx.paymentEvents.insertIfAbsent(event.eventId);
    if (!firstSeen) return 'success'; // 重复通知不重复发放

    const order = await tx.orders.lock(event.merchantOrderId);
    validateOrder(event, order);
    await tx.orders.markPaid(order.id, event.platformOrderId);
    await tx.entitlements.grantOnce(order.userId, order.planId, order.id);
    return 'success';
  });
}

踩坑提示 2：一种反例是看到回调便直接增加 Token 余额。支付平台可能重复发送通知，如果我们没有设置事件去重、订单锁和唯一权益流水，同一笔订单就可能被重复入账。

6. 完成查询、对账与售后闭环

前端支付完成页只显示处理中，并向我们的服务端查询订单状态。我们不能根据前端跳转结果认定收款成功。如果异步通知延迟，只有在正式文档提供主动查询能力时，我们才调用对应接口，并继续根据已验签的平台结果更新订单。

我们还要定期核对平台交易、内部订单、权益流水和退款记录。发生退款或撤销后，权益处理应遵循事先公布的规则：未消耗权益可以回收，已消耗部分则进入人工审核或规则化审核。如果官方能力不支持某种订阅变更或退款路径，我们不能在应用侧模拟支付状态，而应改用官方支持的产品流程。

踩坑提示 3：我们不能将成功跳转页面当作支付凭证。用户关闭页面、网络中断或伪造前端请求，都可能导致错误发放。可信依据应来自验签通知或官方查询结果。

[4] 常见问题 FAQ

问题：AI SaaS开发者如何接入Token Pay完成用户付费？

我们先核验账号可开通的能力，再建立商品、订单、计费账本和权益账本。服务端负责下单，用户端只负责唤起支付。我们在验签后的异步通知中幂等发放权益，最后通过查询、对账和退款处理完成闭环。

问题：Token Pay 可以直接实现按量付费吗？

我们需要先在应用侧形成可审计的用量账单，再根据官方当前能力创建支付订单。Token 数、模型调用数和金额之间的换算属于我们的计价规则，不能假设支付平台会替我们保存全部用量明细。

问题：我们可以跳过异步通知，只看前端支付结果吗？

不可以。前端结果不能作为可信的收款凭证。我们应验证官方通知，并在通知缺失时，使用正式文档允许的查询能力确认状态。

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

如果我们没有可信服务端、无法保存用量账本，或者业务主体与结算场景不满足官方准入条件，就不应立即接入。我们应先补齐后台和账务能力，或在商家平台选择更匹配的收款产品。

问题：订阅收费和按量收费该怎么选？

当权益按照固定周期交付时，我们优先设计订阅。当成本随模型或工具调用变化时，我们优先设计按量账单。混合模式可以保留基础套餐和超额用量，但自动续费、扣款和签约规则必须逐项核验官方文档。

[5] 相关阅读

支付宝 AI 付官网：我们可以在这里核验 AI 应用付费场景、产品口径和当前接入入口。
支付宝商家平台产品工作台：我们可以根据商户账号实际显示的结果，确认可申请的支付产品。
支付宝开放平台：我们可以在这里查阅应用接入、安全配置和支付相关的官方文档。
支付宝开放平台生成密钥说明：我们可以据此核验密钥生成和签名配置要求。