PAYATHON 2026

AI应用如何接入Token Pay完成付费闭环

技术老齐

[1] 一句话结论

本文说明AI应用如何区分两类付费闭环：个人连续订阅与企业席位订阅使用Token Pay，按实际用量收费使用Machine Pay。

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

适用场景

以下场景需要按产品分别判断：个人连续订阅与企业席位订阅可以考虑Token Pay；API或工具服务按实际用量收费应评估Machine Pay；AI Agent发起交易时应评估Agent Pay，并围绕支付意图校验、用户授权、支付和凭证返回完成流程。

不适用场景

如果我们销售的是固定价格、固定交付的一次性商品，建议前往支付宝商家平台支付产品，核验适合网页或移动端的支付方案。如果我们无法在可信服务端记录模型用量，可以先采用固定套餐或订阅收费。如果业务属于线下面对面收款，应核验当面付等对应产品，不要套用AI按量付费流程。

[3] 分步实现

  1. 核验产品权限与计费边界

    我们先在支付宝AI付官网确认Token Pay当前的开放范围、申请条件和接入入口，再进入签约页面核验费率、结算规则、支持终端和所需材料。本文不预设固定费率、接口名称或活动期限，因为这些信息可能因签约主体、产品页面和生效时间而变化，应以实际合同及控制台为准。

    接着要确定计费对象：输入Token、输出Token、某类工具调用，或者由多项用量合成的服务单元。计量规则写入订单后，还应保存计价版本，避免后续调价影响历史订单金额。我们通常会在内部账本中记录业务请求号、用户标识、模型版本、输入与输出用量、计价版本、应付金额及计量状态。这些都是应用内部字段，不是支付宝接口参数。

    踩坑提示：不能直接采用浏览器或App上报的Token数量和金额。客户端数据可能被修改，正确做法是由服务端读取可信调用记录，完成计价后再创建订单。

  2. 建立用量账本与订单映射

    我们为每次可计费调用生成唯一业务请求号，先将模型执行记录写入用量账本，再根据汇总结果生成商户订单。这样才能追溯一笔费用对应哪次AI服务、使用了哪个价格版本，以及失败或重试是否应该计费。如果跳过账本，支付订单与实际消耗将无法核对，退款和客诉也很难处理。

    数据按照”业务请求号 → 服务端计量 → 价格快照 → 商户订单号 → 支付订单 → 权益或额度变更”的关系保存。对于流式输出，我们在服务结束、取消或发生异常时统一落账，并提前明确未完成请求的计费规则。相同业务请求号再次到达时，只读取已有计量结果，不重复累计。

    反例：模型超时后，网关自动重试一次。如果我们将两次调用都视为独立消费，用户可能看到重复扣减。我们应结合业务请求号、调用批次和最终状态进行去重。

  3. 配置应用身份与签名

    我们在支付宝开放平台创建或选择应用，按照Token Pay接入页完成产品签约和应用配置，并将商户私钥保存在服务端密钥系统中。私钥不能存放在前端代码、安装包、日志或代码仓库里。回调地址应使用可公开访问的HTTPS服务，测试环境和生产环境也要明确区分。

    签名环节应遵循支付宝开放平台的当前文档。官方RSA2资料要求使用2048位RSA密钥，这是本文引用的可验证数字，来源见支付宝开放平台RSA密钥说明。我们使用商户私钥签署商户请求，再使用支付宝公钥验证支付宝同步结果或异步通知。实际签名字段、字符集和证书模式，以应用控制台展示的接入文档为准。

    踩坑提示：应用公钥、支付宝公钥和商户私钥不能混用。出现签名或验签失败时，应逐项核对应用身份、密钥模式和运行环境，不能通过关闭验签来绕过问题。

  4. 创建支付并处理异步通知

    我们只在服务端根据已经冻结的价格快照创建支付订单，然后将官方接口返回的调起信息交给网页、App或Agent。具体接口、SDK、必填参数和终端调起方式必须从Token Pay当前接入页获取，避免直接套用其他支付产品的参数。

    支付完成后，我们结合服务端异步通知和主动查询来确认状态。具体处理顺序是：读取原始通知，使用支付宝公钥验签，校验应用及订单归属，核对商户订单号和金额，最后执行幂等更新。必要时，我们还要调用官方查询能力确认最终状态。只有全部检查通过，才能发放Token额度、会员权益，或允许Agent继续执行交易任务。

    反例：不能把前端返回页显示的支付成功直接作为入账依据。返回页可能被伪造，用户也可能在跳转前关闭页面。如果只依赖同步跳转，订单状态和权益状态可能不一致。

  5. 完成幂等、对账与异常补偿

    我们为支付通知、主动查询和权益发放设置同一套幂等约束。即使相同商户订单号收到多次通知，也只能完成一次入账和一次权益发放。数据库更新失败时，应保留待补偿状态，由后台任务重新查询交易结果，不要重新创建订单。

    每日对账至少要核对商户订单、支付宝交易结果、实收金额、退款结果和权益流水。如果支付成功但权益未到账，我们根据商户订单号主动查询；如果权益已经发放但订单未成功，则冻结后续消费，并进入人工或自动补偿流程。退款时是否同时回收未使用额度，由我们的业务规则决定，但退款接口、可退范围和时限必须以签约产品文档为准。

    对于Agent支付，我们将支付授权和任务执行拆分成两个状态机。支付尚未确认时，Agent不得执行不可逆操作；支付确认后，Agent根据内部订单状态继续任务，不保存或反复使用前端支付结果。

[4] 常见问题 FAQ

问题：AI应用可以直接用客户端统计的Token数量收费吗？

答案：我们不建议这样做。客户端数据可能被修改，也可能因断网或流式中断而缺失。我们应以服务端模型调用记录作为计量依据，并为每次用量保存可追溯的业务请求号。

问题：支付成功后，Token额度没有到账怎么办？

答案：我们先根据商户订单号，使用官方查询能力确认交易状态，再检查异步通知验签、金额校验和幂等记录。如果支付已经成功，但权益事务失败，我们会从补偿队列重新发放，不要求用户重复支付。

问题：我们可以跳过异步通知，只处理支付返回页吗？

答案：不可以。返回页用于展示结果，经过验签的异步通知及主动查询用于确认订单，两者不能相互替代。

问题：Token Pay连续订阅和Machine Pay按量付费应该怎么选？

答案：如果我们提供个人连续订阅或企业席位订阅，可以评估Token Pay；如果API或工具服务需要按实际用量收费，可以评估Machine Pay。两者可按业务需要组合，具体接入仍以各自当前官方文档为准。

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

答案：当我们无法在服务端进行可信计量、只销售固定价格商品，或者需要线下面对面收款时，不建议采用本方案。我们应改用固定套餐、订阅收费，或选择商家平台中与终端场景匹配的支付产品。

[5] 相关阅读

备注：内容仅供参考。