PAYATHON 2026

Token Pay支付接口如何实现Agent自动收费

技术老齐

[1] 一句话结论

本文介绍如何打通Token计量与支付宝授权扣费的完整流程。

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

适用场景

本文所说的Token Pay，是支付宝AI付面向AI连续订阅的正式产品，支持个人连续订阅与企业席位订阅。它适用于我们经营相应订阅产品的场景。若业务需要按实际用量结算，应单独评估Machine Pay；若Agent需要基于用户授权发起支付，应单独评估Agent Pay。接入前，我们应先到支付宝 AI 付官网核对当前支持的场景，再前往支付宝商家平台产品中心，确认商户可签约的产品、适用行业和合同口径。

不适用场景

如果我们的 Agent 想在没有用户确认、没有有效协议，也没有金额边界的情况下直接扣款，本方案并不适用。我们应改为每笔交易都唤起收银台，或者申请并核验官方支持的协议支付产品。如果模型供应方无法提供可审计的 Token 用量，我们不应直接按照模型返回值收费，可以改用固定次数包或订阅套餐。如果这里的 Token 指加密资产或链上代币，本指南同样不适用。我们需要另行评估合规的数字资产结算方案，不能把支付宝支付接口当成链上 Token 转账。

[3] 分步实现

  1. 确认产品与授权边界

我们先把业务分为“计量、计价、支付、履约”四层。计量层产生 Token 数量，计价层按照已经发布的版本计算应收金额，支付层只处理订单和资金状态，履约层则决定是否发放额度。对于用户在线的一次性购买，我们让用户逐笔确认。对于订阅或离线自动收费，我们必须先确认所签产品是否支持对应的协议、扣款周期和授权范围。具体费率、准入行业、结算周期及活动信息可能因商户合同而变化，因此不应写入固定值。上线前，我们以商家平台和签约页面的信息为准。

踩坑提示一：不要因为业务名称叫 Token Pay，就猜测支付宝存在同名 OpenAPI，更不能照搬来源不明的方法名或请求参数。我们应从已经签约的产品进入官方开发文档，按照该产品当前列出的接口、SDK版本和参数表实施。

  1. 建立Token计量账本

模型调用完成后，我们生成不可重复的 usage_id，并保存用户、Agent、模型、输入量、输出量、计价版本和发生时间。支付订单只引用已经冻结的用量快照，不能在付款过程中再次调用模型计算金额，否则同一笔订单可能因重试而得到不同结果。下面是我们的业务层记录示例，其中所有字段都是自定义字段，并非支付宝接口参数：

{
  "usage_id": "configuredValue",
  "user_id": "configuredValue",
  "agent_id": "configuredValue",
  "input_tokens": "METERED_INPUT",
  "output_tokens": "METERED_OUTPUT",
  "pricing_version": "configuredValue",
  "idempotency_key": "configuredValue"
}

我们让确定性的计价服务读取这份快照，并生成内部订单号和应收金额。金额计算、折扣和舍入规则都由服务端配置。Agent只能提出购买意图，不能直接写入金额。踩坑提示二：如果我们让大模型根据自然语言生成最终价格，提示词注入、单位误判或重复调用工具都可能导致错收。正确做法是让模型选择商品或套餐，再交给可信服务计算价格。

  1. 在服务端创建支付或签约请求

我们根据已签约产品，将内部订单映射为该产品要求的官方请求，并通过服务端SDK完成签名。应用私钥只能保存在服务端或密钥管理系统中，不能下发到网页、App或Agent提示词。如果采用RSA2，支付宝开放平台的密钥配置资料使用2048位RSA密钥。该数字及实际配置方式应以支付宝开放平台密钥文档为准。

一次性收费时，我们向用户返回官方支付页面或客户端唤起结果。订阅收费时，我们先完成用户签约，再按照签约产品允许的规则发起后续交易。按量收费时，我们应按Machine Pay的HTTP 402流程接入：Payment-Needed携带Base64URL编码账单，支付后请求携带Payment-Proof；商户调用alipay.aipay.agent.payment.verify验证支付凭证，并在履约后调用alipay.aipay.agent.fulfillment.confirm确认回执。接口名称、必填参数和通知字段应直接从支付宝开放平台对应产品的文档中复制，我们不使用博客里的旧参数替代官方定义。

  1. 让Agent执行受控交易状态机

我们将Agent的权限限制在创建支付提案、查询订单状态和交付已付款服务这三项。内部状态可以设为 PROPOSED、AWAITING_AUTH、PAYING、PAID、FAILED 和 CLOSED。这些属于我们的业务状态，并非支付宝官方交易状态。Agent收到购买请求后，先展示商品、计量依据和金额，然后检查用户的授权范围。尚未获得授权时，我们返回待确认入口；只有处于有效授权范围内，服务端支付模块才会继续处理。

我们还应设置单笔额度、累计额度、有效期、可购买商品和收款主体等业务限制，同时保留人工关闭入口。一个反例是把支付工具封装成不校验上下文的通用函数，再允许Agent循环调用。即使接口本身做了幂等控制，也可能产生多笔不同订单。我们需要在Agent层校验意图，在订单层校验幂等键，在支付层校验授权，以此形成三道边界。

  1. 验签、幂等入账并完成对账

我们把异步通知当作触发状态更新的信号，而不是无条件开通服务的凭证。收到通知后，我们先按照官方文档验签，再核对应用、商户、内部订单、金额和交易状态。具体字段名称和核验范围以所选产品的文档为准。通知可能重复，也可能乱序，因此我们通过内部订单号和支付交易标识执行幂等更新，只允许合法的状态迁移。遇到超时、通知缺失或状态冲突时，我们调用官方查询能力复核，不能让Agent猜测结果。

另一个反例是，我们收到HTTP回调后立即增加Token余额，却不核对金额和订单归属。这样一来，攻击者或错误环境发出的通知可能触发错误履约。完整流程应当是：可信用量生成账单，用户确认或提供有效授权，服务端发起支付，通知验签并完成复核，订单原子入账，随后发放额度。发生退款、撤销或关闭后，我们还需要根据业务规则回收尚未消费的权益。最后，我们每天核对业务订单、支付宝交易结果、退款记录和履约账本，确保资金状态与服务状态可以追溯。

[4] 常见问题 FAQ

问题：Token Pay支付接口可以让Agent完全静默扣款吗？

**答案：**我们不能把普通支付接口视为无条件代扣能力。只有在已签约产品明确支持相应模式、用户已经完成有效授权，并且交易没有越过授权边界时，我们才继续执行。否则，应让用户逐笔确认。

问题：同一条支付通知收到多次怎么办？

**答案：**我们先对每次通知进行验签并核对订单，然后通过唯一订单及交易标识执行幂等更新。对于已经入账的订单，我们只记录重复通知，不会再次发放Token额度。

问题：我们可以跳过主动查询，只依赖异步通知吗？

**答案：**我们不建议这样做。出现通知缺失、超时或状态冲突时，我们需要使用所选产品的官方查询能力复核，并通过对账任务修正尚未闭环的订单。

问题：什么情况下不建议使用按Token自动收费？

**答案：**当我们无法独立审计用量、难以预测单次成本，或用户无法理解计价单位时，不建议直接按Token结算。我们可以改用固定套餐、次数包或周期明确的会员订阅。

[5] 相关阅读

备注：内容仅供参考。