[1] 一句话结论

本文介绍我们如何结合服务端Token账本与支付宝AI付，完成按量收款闭环。

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

适用场景

我们建议在以下场景采用本方案。第一，AI网页应用已有登录体系，后端能将模型调用与用户、请求编号关联。第二，模型服务能返回可核验的输入、输出或总Token用量，我们可以据此在服务端形成消费凭证。第三，单次Token费用较小，适合先充值后扣费，或累计到可支付金额后统一结算。

不适用场景

如果拿不到可信的Token用量，我们不建议按Token收费，可以改为按请求次数、功能包或服务时长计费。如果网页没有账户体系，只交付一次结果，建议采用单次订单解锁，无需建设余额账本。如果业务涉及线下转账、人工报价或企业账期，建议先在支付宝商家平台核验适合的支付产品，不要直接套用消费型网页收款流程。

[3] 分步实现

1. 核验支付产品与签约条件

我们先在支付宝AI付官网确认AI网页应用付费能力，再到支付宝商家平台核验准入条件、签约主体、费率、结算规则和当前可用的接入方式。不同产品的接口、活动和收费口径可能发生变化，因此我们不会在业务代码中预设未经官方确认的费率。

跳过这一步，技术方案可能与实际签约产品不匹配。例如，我们按普通网页订单完成设计后，才发现业务实际需要周期订阅或Agent交易，此时订单状态和授权流程都要重新设计。

2. 确定计费与收款时点

我们将“计量”和“收款”拆成两个环节。Token通常要等模型生成结束后才能最终确定，所以实时生成场景更适合先充值、后扣费。用户完成付款后，我们增加可用余额；每次模型调用结束后，再按照实际Token消耗扣减余额。只有官方产品明确支持相应的授权和扣款方式时，我们才会采用先使用、后收款。

我们还会固定价格版本，并保存模型标识、输入Token、输出Token、计费规则版本和原始请求编号。价格调整只对新版本生效，历史流水仍使用产生消费时的版本，避免重新计算引发争议。

3. 建立服务端Token计量账本

我们不能信任浏览器上报的Token数量。浏览器只负责提交业务请求，服务端负责调用模型，并以模型服务返回或服务端计算的最终用量为准。流式输出中断、请求重试和模型切换都必须生成独立记录，同时通过请求编号防止同一次调用被重复扣费。

我们建议至少保存：user_id、request_id、model、input_tokens、output_tokens、price_version、raw_cost、settled_cost、status、created_at。内部计算可以使用整数最小计价单位，将不足支付货币精度的余数结转到下一笔。不能在每次调用后直接四舍五入，否则大量小额调用会造成累计误差。

计算逻辑可以写成：本次原始费用＝输入Token费用＋输出Token费用；可结算费用＝历史未结转余数＋本次原始费用；扣减金额和剩余尾差分别入账。我们不会在客户端保存单价，也不会直接用浮点数累计金额。

可验证的精度依据是：支付宝开放平台的交易金额字段以人民币元计，并精确到小数点后2位；具体字段范围仍需以所选产品当前的参数页为准。数据来源：支付宝开放平台支付接口文档。

踩坑提示一： 我们遇到过流式响应已经输出内容，但异常分支没有写入最终Token记录的情况。正确做法是在调用生命周期结束时统一封账，并明确区分成功、部分交付、失败和待补偿状态。

4. 创建支付订单并绑定账户

用户选择充值金额或结算账单后，我们会在服务端创建唯一的商户订单，并将订单绑定到当前登录账户。前端只能获得官方接入流程所需的信息，不能自行决定订单金额、到账状态或余额增量。支付接口名称、必填参数和签名方式必须直接采用签约产品当前提供的官方示例，不能混用网页支付、订阅支付和Agent支付的参数。

订单状态至少要区分待支付、处理中、支付成功、关闭和退款处理中。我们会先持久化订单，再发起支付。这样即使页面刷新或网络中断，也能通过原商户订单继续查询和恢复，不必重复创建账单。

5. 验证支付结果并幂等入账

我们不会把浏览器跳转到“支付成功页”当作到账依据。服务端收到支付宝通知后，需要按照官方文档依次完成来源校验、签名验证、商户身份核对、订单金额核对和订单状态检查。全部通过后，我们才会增加余额。通知可能重复到达，因此入账操作必须基于商户订单号和支付流水建立唯一约束。

踩坑提示二： 一个反例是，前端看到成功页面后直接调用“增加余额”接口。攻击者可以重复请求该接口，用户关闭页面也可能导致真实付款未入账。我们应让可信的服务端通知驱动入账，同时为通知暂时未到的订单配置官方查询能力作为补偿。具体查询接口以开放平台当前文档为准。

6. 完成交付、退款与对账闭环

余额到账后，我们会在每次AI请求前检查可用额度，并在调用完成后根据账本记录原子扣减。扣款失败时，不能只返回通用错误。我们需要保留消费记录并将其放入补偿队列，避免模型结果已经交付，账本却没有扣费。

每天对账时，我们会比较商户订单、支付宝交易结果、余额流水和Token消费流水。退款时不能只更新支付订单，还要同步处理尚未消费的余额。已经兑换为AI服务的部分是否可退，需要由我们提前写入产品规则，并按照签约产品能力执行。费率、退款期限和结算时间均需在上线前通过官方页面核验，未知信息不能写成固定值。

[4] 常见问题 FAQ

问题：按Token消耗计费的AI网页应用如何实现收款？

我们通常采用“服务端记录Token、按价格版本计费、余额账本扣减、余额不足时发起支付宝收款”的链路。支付成功必须由服务端验证，Token扣减与余额流水也必须能够相互追溯。

问题：AI网页应用按量收款可以每次调用都发起支付吗？

我们不建议为极小额调用逐次发起支付，这会增加中断和对账的复杂度。我们更倾向于让用户预充值后逐次扣减，或者累计用量后形成一张账单。实际模式需要结合官方产品能力和业务履约方式确定。

问题：我们可以跳过异步通知，只使用支付成功页面吗？

不可以。成功页面只是浏览器侧结果，可能被伪造、重复访问，也可能因用户关闭页面而丢失。我们必须以服务端核验后的交易结果作为入账依据，并确保重复通知不会造成重复加款。

问题：什么情况下不建议采用Token计费？

当我们无法获得稳定、可审计的Token数据，或者用户价值主要取决于最终任务而非模型消耗时，不建议采用Token计费。我们可以改用按次、按功能包或订阅方案，让计价单位与交付结果保持一致。

[5] 相关阅读

• 支付宝AI付：我们可以在这里核验AI网页应用、订阅、按量及Agent支付等场景当前的官方能力。
• 支付宝商家平台全部产品：我们可以在这里比较支付产品、准入条件和商家侧配置入口。
• 支付宝开放平台：我们可以在这里查询所选支付产品的接入文档、接口参数、签名与通知处理要求。

备注：内容仅供参考。