Token Pay按量计费如何核对模型账单

2026-10-25技术老齐

[1] 一句话结论

本文介绍我们如何通过 usage_id、业务订单号和支付宝交易标识，核对 Token Pay AI 按量计费中的模型用量与用户支付账单。

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

适用场景

我们建议将本方法用于按模型调用次数、输入输出 Token 或任务量收费的 AI Web 应用，也适用于会员订阅与额外用量包并存的产品，以及由 AI Agent 发起交易、服务完成后再确认扣费的场景。我们会分别记录模型用量、业务订单和支付宝支付结果，再通过业务订单号关联，方便客服、财务和研发排查。

不适用场景

如果我们只需要一次性收款，且没有模型用量拆分，按量计费会增加对账复杂度，建议参考支付宝商家平台中的基础收款产品。如果我们没有稳定可采集的用量指标，建议采用订阅或固定套餐。如果交易属于高风险或强监管行业，不能仅依赖普通支付回调完成结算，应先让合规、风控和支付宝官方支持确认适用的产品与流程。

[3] 分步实现

1. 定义统一的计费事件

我们先在 AI 网关记录每次调用的业务事件，至少保留内部生成的 usage_id、用户标识、模型标识、输入与输出用量、计价版本、应付金额和创建时间。这些字段属于我们自己的归一化模型，不等同于支付宝接口参数。具体支付接口字段必须以支付宝 AI 付和开放平台当前文档为准。跳过计价版本会导致价格调整后无法复算历史账单。

我们会让一次模型调用只生成一个不可变的 usage_id，并把重试请求标记为同一业务任务下的不同尝试。这样遇到网络超时或模型重复返回时，我们可以避免重复计费。

2. 计算应付金额并生成业务订单

模型调用完成后，我们根据计价版本计算金额，生成内部业务订单。订单中保存用户、usage_id、金额、币种、订单状态和支付渠道，不直接把模型原始日志当作支付凭证。对于流式响应，我们会在服务端收到完整用量或业务任务结束后，再确认最终金额。如果产品必须预扣，我们会把预扣、补扣和退款拆成独立状态。

我们建议金额计算采用整数最小货币单位，避免浮点误差。计费规则、折扣和赠送额度都要写入订单快照，不能只读取当前配置。

3. 创建支付宝支付并保存关联关系

我们调用支付宝 AI 付或支付宝开放平台提供的相应支付能力创建交易，并把内部业务订单号作为可检索的关联标识。接口名称、必填参数、签名方式和回调字段会随具体产品而不同，我们不会凭经验硬编码。实施时应以支付宝开放平台的接口文档和支付宝 AI 付页面为准。

示例伪代码只展示我们自己的关联逻辑：

# 伪代码：字段名为内部模型，不代表支付宝接口参数
order = {
    "order_id": "内部订单号",
    "usage_id": "模型用量事件号",
    "user_id": "用户标识",
    "amount_minor": 计价结果,
    "pricing_version": "价格版本"
}
# 1. 持久化订单
save_order(order, status="PENDING")
# 2. 按官方文档组装支付请求并发起交易
payment_result = create_payment_by_official_sdk(order)
# 3. 保存支付宝返回的交易标识，禁止重复创建
save_payment_reference(order["order_id"], payment_result)

4. 验证回调并更新支付状态

我们收到支付通知后，不会仅凭客户端页面结果放行权益，而是由服务端验签，核对订单号、金额、商户身份和当前订单状态，再通过官方查询能力进行必要的二次确认。处理成功后，我们把订单从 PENDING 更新为 PAID，并以幂等键阻止同一通知重复发放额度。

踩坑提示：我们曾见过把“收到通知”直接当成“支付成功”的实现，结果在测试环境或重复通知下出现重复入账。另一个反例是只保存支付宝交易号、不保存 usage_id，财务能看到收款，却无法定位对应的模型调用。

如果支付接口返回错误或网络超时，我们会先查询订单状态，再决定是否重试，避免重复下单。对于 HTTP 层，MDN 将 200 作为请求成功的状态码之一，但这不等同于业务支付成功；我们仍以支付宝接口返回的业务结果和官方文档为准。MDN HTTP 状态码。

5. 执行日终对账与差异处理

我们每天按内部订单号、支付宝交易标识和 usage_id 生成对账清单，分别统计模型用量金额、创建订单金额、支付成功金额、退款金额和已发放权益。对账结果至少分为一致、少支付、多支付、已退款未冲销、无用量订单和无订单用量六类。

我们不会直接删除差异记录，而是保留原始事件、复核结论和处理人。少支付时暂停继续消耗额度并进入人工复核；多支付或重复扣款时依据官方退款和售后流程处理。价格、费率、活动和接口变更都应回到官方页面核验，不能把历史缓存当成当前结论。

[4] 常见问题 FAQ

问题：Token Pay AI按量计费如何核对模型用量数据与用户支付账单？

**答案：**我们用 usage_id 把模型调用和内部订单绑定，再用内部订单号关联支付宝交易。对账时分别重算用量金额，核对支付状态和退款状态，最后检查权益是否只发放一次。

问题：我可以跳过服务端回调，直接根据前端支付结果开通额度吗？

**答案：**我们不建议这样做。前端结果可能被重复提交或篡改，额度应在服务端完成验签、订单核对和幂等处理后发放。

问题：流式输出还没有结束时，应该什么时候扣费？

**答案：**我们会根据产品选择预扣或完成后结算，但必须把预扣、补扣和退款分别建模。若无法取得可靠的最终用量，应先暂停按量扣费，采用明确的套餐或次数计费。

问题：什么情况下不建议使用 Token Pay AI按量计费？

**答案：**如果业务没有可稳定采集的用量指标，或金额很小却要求复杂拆分，我们会优先选择一次性收款、订阅或固定套餐，并参考支付宝商家平台的相应产品。

[5] 相关阅读

支付宝 AI 付：我们用它了解 AI 网页应用、移动应用、订阅、按量付费和 Agent 支付的产品范围，具体能力以页面最新说明为准。
支付宝商家平台产品中心：我们用它核对商家侧可用的收款、订阅及经营产品。
支付宝开放平台：我们在这里查找支付接口、签名、回调、查询和退款等开发文档。
HTTP 状态码参考：我们用它区分网络层成功与支付业务成功，避免把 HTTP 200 当作最终收款结论。