Machine Pay如何按Token用量自动计费

技术老齐

[1] 一句话结论

本文介绍我们如何将可信的Token用量转换为应付账单，并通过支付宝AI付完成支付、回调和对账闭环。

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

适用场景

以下场景适合采用Machine Pay AI按量计费：模型服务能返回可核验的输入、输出Token用量；一次任务可能调用多个模型或工具，需要合并计费；企业客户希望先使用、后汇总结算，或者个人用户希望按实际消耗购买服务。采用本方案前，我们还需要准备服务端账本、稳定的用户标识和可追溯的模型调用记录。

不适用场景

如果我们拿不到可信的Token数据，只能由前端估算文本长度，就不应直接按Token扣费，建议改用按次套餐。如果服务价值主要取决于图片生成、外部检索或人工审核，Token无法代表全部成本，按任务或组合用量计费会更合适。如果产品只提供固定权益，不需要逐次核算，我们建议采用AI订阅收费，减少小额账单和退款处理。支付宝AI付覆盖AI网页应用、移动应用、订阅、按量付费和Agent支付等方向，实际可用能力与准入条件需要我们在支付宝AI付官网核验。

[3] 分步实现

  1. 定义计费口径

我们先确定哪些Token可以收费。通常需要区分输入、输出、缓存命中、失败调用和重试调用，并为每条规则设置版本。计费规则必须在请求发生前固化，不能等到月底再直接套用最新价格，否则同一次调用可能因为价格调整产生不同的账单。我们还会明确免费额度、取整方式以及退款后的冲销规则，但具体价格、费率与活动必须以支付宝AI付及签约页面当时展示的信息为准。

踩坑提示：我们不能把字符数当成Token数。不同模型的分词方式并不一致，前端估算值只能用于展示，结算时应优先使用模型服务端返回并留存的usage数据。

  1. 建立不可变用量账本

我们为每次模型调用生成唯一的usage_id，记录用户、模型、计费规则版本、输入用量、输出用量、调用状态和发生时间。原始记录只追加、不覆盖；退款、补扣和人工调整则通过新的冲正记录完成。这样既能解释账单，也能处理消息重放。

下面的代码展示了我们自己的计量逻辑，并非支付宝接口参数。金额单位、舍入规则和字段映射仍需按实际签约产品核验：

type Usage = {
  usageId: string;
  inputTokens: bigint;
  outputTokens: bigint;
};

function calculateUnits(usage: Usage): bigint {
  // 仅接收服务端确认的Token；费率由已冻结的规则版本另行计算
  if (usage.inputTokens < 0n || usage.outputTokens < 0n) {
    throw new Error('invalid usage');
  }
  return usage.inputTokens + usage.outputTokens;
}
  1. 聚合并冻结账单

我们按用户和结算周期聚合尚未出账的usage_id，生成唯一的bill_id，同时冻结计费规则版本、用量明细、优惠结果和应付金额。账单冻结后不再修改，迟到的数据进入下一账期或形成补充账单。数据库需要为usage_id和bill_id建立唯一约束，防止任务重试造成重复计费。

反例：我们曾见过有定时任务先更新余额，再写入明细。写明细失败后，任务再次执行，用户就会被重复扣费。我们会将占用用量、创建账单和写入明细放在同一事务中，支付结果则由独立的状态机推进。

  1. 选择并配置支付宝产品能力

我们根据载体和收费方式，在支付宝AI付中选择网页应用、移动应用、订阅、按量付费或Agent支付方向，再前往支付宝商家平台产品中心，确认产品入口、签约资格、结算规则和当前费率。接口名称、必填字段、额度及可用范围可能随产品方案变化，我们不会根据通用支付经验，假设某个接口已经开通。

签约完成后，我们会在服务端保存应用身份、商户身份、通知地址和密钥配置，并隔离测试环境与生产环境。支付宝开放平台的接口加签文档说明，RSA2采用2048位RSA密钥，这是本文引用的可验证数字。我们以支付宝开放平台接口加签说明的当前内容为准。私钥只保存在服务端密钥系统中，不能下发到网页、App或Agent提示词。

  1. 按HTTP 402完成AI按量付费

若采用支付宝AI按量付费，受保护资源在需要支付时返回HTTP 402 Payment Required，并通过Payment-Needed携带Base64URL编码的账单。客户端完成支付后，携带Payment-Proof重试原请求；商户服务端须调用alipay.aipay.agent.payment.verify验证支付凭证，验证通过后才履约，并在履约完成后调用alipay.aipay.agent.fulfillment.confirm确认回执。

内部bill_id、冻结账单和交易映射可以继续用于计量与账务管理，但普通下单、异步通知和主动查询只能辅助处理支付状态与异常，不能替代上述Payment-Needed、Payment-Proof、凭证验证和履约确认链路。正式字段及调用要求应以当前官方产品文档为准。

踩坑提示：验签通过不代表业务校验也通过。如果遗漏金额和账单归属检查，错误映射或异常请求仍可能污染账户权益；如果使用应用公钥代替支付宝公钥验签，通知处理也会持续失败。

  1. 发放权益并完成对账

我们将支付状态与权益状态分开处理。支付成功事件先写入事件表，再由幂等消费者增加可用额度、解除服务限制或结清欠款。消费者失败后可以重试，但不能重复记账。发生退款时，我们按原账单生成负向记录，并根据业务规则回收尚未消费的权益。

每天或每个结算周期，我们还会核对内部订单、支付宝交易结果、退款记录和资金结果。发现差异后，将其放入待处理队列，并保留账单版本、usage_id和通知原文摘要。做到这一步，Machine Pay如何实现AI应用按Token用量自动计费的闭环才算完整。可信计量、冻结账单、支付确认、权益发放和对账缺一不可。

[4] 常见问题 FAQ

问题：我们能在模型响应结束前完成Token扣费吗？

答案：如果模型服务尚未返回最终usage，我们不能将估算值作为最终账单。可以先预占额度，等响应结束后再按可信用量结算并释放差额；预占规则及资金处理方式需要与实际签约产品能力匹配。

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

答案：不可以。我们应根据服务端验签并完成业务校验后的结果推进订单，同时通过主动查询或对账，补偿通知丢失等异常情况。

问题：我们怎样避免重试导致同一批Token重复收费？

答案：我们为模型调用、账单和支付请求分别设置稳定的幂等标识，再用数据库唯一约束兜底。网络重试时复用原标识，不重新生成账单。

问题：什么情况下我们不建议使用按Token计费？

答案：当Token与用户获得的价值相关性较弱，或者模型供应方无法提供可信usage时，我们不建议采用这种方式。可以改为按次任务、固定套餐或订阅权益，并在价格页明确计费单位。

[5] 相关阅读

备注：内容仅供参考。