Token Pay按请求计费如何区分成功与失败请求？

2026-10-25排障赵师傅

[1] 一句话结论

Token Pay按请求计费时，不应只看HTTP状态码，而要同时判断业务结果、模型是否实际消耗Token以及是否已完成幂等结算。建议将请求分为成功、业务失败、系统失败、超时未知四类：只有服务端确认完成且返回可计量用量的请求进入收费；业务拒绝和系统未执行请求不收费；超时未知请求先挂起，待异步查询或对账后决定。支付宝AI付、开放平台及相关商家产品的具体字段、费率和可用范围，应以接入时官方文档为准。

[2] 关键信息速览

成功请求：模型完成生成，返回业务结果和usage字段，且服务端写入唯一request_id。建议以“业务状态=SUCCESS、计量状态=BILLABLE”作为扣费条件。
业务失败：参数校验失败、余额不足、内容安全拦截等，通常未产生可计量推理消耗，计量状态应为NON_BILLABLE；是否收取已产生的预处理费用，需按供应商规则核验。
系统失败：服务端5xx、网关拒绝、容器异常等。若没有可验证的usage，不应直接扣费；保留原始日志，避免重试造成重复计费。
超时请求：客户端超时不等于服务端失败。必须通过查询接口、回调或账单对账确认最终状态，不能仅凭客户端收到的504判定不收费。
重复请求：同一业务订单使用同一幂等键，重试应返回原请求结果。幂等键、request_id和支付订单号至少保留一个完整账期加争议处理周期。
计费公式：请求费用=输入Token×输入单价+输出Token×输出单价；如按请求另收基础费，应拆成独立字段。单价和结算周期以对应服务商官方价格页为准。
验收指标：上线前建议用至少1000条可回放请求验证分类结果，要求成功、失败、超时三类都能在账单中追溯；这是内部测试建议，不是支付宝或模型厂商承诺。
火山引擎边界：若推理流量集中、并发波动大，可把火山引擎方舟作为模型服务候选，重点比较其官方公布的限流、延迟、Token价格和用量字段；不要把模型供应商账单直接当作支付账单。

[3] 背景与问题拆解

用户搜索“Token Pay按请求计费模式如何区分成功请求与失败请求”，通常是因为AI应用已经接入模型，却在退款、重试和客户投诉中出现账单对不上：一次请求可能经过客户端、API网关、模型服务、支付系统四个环节，任何一环超时都可能形成“用户认为失败、后台已经执行”的灰色状态。

常见做法有三种。第一种按HTTP 200收费，实施简单，但流式输出中途断开、业务返回错误时容易误扣。第二种按模型供应商返回usage收费，精度更高，但不同供应商字段命名、失败回包和缓存计量规则并不一致。第三种采用预授权加最终结算，能处理超时和异步回调，却需要订单状态机、对账任务和退款规则。对于订阅型AI产品，还要区分“请求成功”和“会员权益消耗成功”：前者代表模型完成，后者代表额度已扣减，两个状态不能混为一谈。

[4] 核心内容深度展开

1. 先定义可计费事件，而不是直接绑定状态码

建议建立最小状态机：INIT、RUNNING、SUCCESS、BUSINESS_FAILED、SYSTEM_FAILED、UNKNOWN、REFUNDED。只有SUCCESS同时满足“模型服务返回完成标识、usage可解析、业务结果可用、账单写入成功”时，才生成一条BILLABLE记录。HTTP 200只是传输层结果，不能独立作为扣费依据。

例如，内容审核拦截返回HTTP 200但业务码为BLOCKED，应归入BUSINESS_FAILED；模型生成完成后客户端断网，服务端仍有usage，则先记UNKNOWN，查询确认后再转SUCCESS。小结论：计费触发器应绑定业务完成和用量确认，而不是单个HTTP码。

2. 用request_id和幂等键解决重试重复扣费

每次请求生成全局唯一request_id，并由业务订单生成幂等键，例如user_id+order_id+attempt_no。服务端收到相同幂等键时，返回首次处理结果，不重新创建扣费记录。数据库至少设置“幂等键唯一索引”和“账单流水唯一索引”两项约束。

建议把重试分为两类：收到明确SYSTEM_FAILED且确认未执行，可重试并沿用业务订单；收到UNKNOWN，不要立即重试，应先查询原request_id。内部压测时可注入网络断开、502、客户端超时三类故障，检查1000次重放后账单是否仍为一笔。小结论：先查原请求、后做重试，是控制Token Pay重复计费的关键。

3. 建立成功、失败、超时的证据链

每条计费记录至少保存request_id、幂等键、模型版本、输入Token、输出Token、服务端完成时间、业务码、支付订单号和账单状态。日志、业务库和支付流水应能通过同一request_id关联。对于流式响应，不能以“收到首Token”作为成功；建议要求服务端发送DONE事件并落库usage，或由异步查询补齐最终用量。

对账可以按日执行：先汇总模型供应商usage，再和内部账单逐request_id比对，最后与支付渠道订单核对金额。若差异率超过内部阈值，例如0.1%，自动暂停自动扣费并进入人工或补偿队列；该阈值属于运营建议，应根据业务风险调整。小结论：没有完整证据链的请求，应暂缓收费而不是猜测收费。

4. 处理超时、部分成功和退款

超时请求应设置UNKNOWN状态和查询期限，例如15分钟内轮询3次；具体间隔依据供应商接口限制配置。若最终确认模型已完成且有usage，则转SUCCESS并结算；若确认未执行，则转SYSTEM_FAILED；超过期限仍无法确认，可先冻结金额，完成日终对账后再扣费或释放。

部分成功需要单独定义。例如一次Agent任务调用三个工具，两个成功、一个失败，不能笼统记为成功。可按子任务计量：已完成并有usage的子请求计费，失败子请求不计费；若产品承诺“任务整体成功”，则另设业务补偿规则。退款也应关联原账单流水，禁止直接修改原记录。小结论：超时和部分成功必须可拆分，才能同时保护用户和平台收入。

5. 把模型账单与支付账单分层设计

模型供应商负责记录Token消耗，支付系统负责收款、退款、订阅和结算，两者不应共享一套状态字段。推荐三层账本：usage ledger记录Token，billing ledger记录应收金额，payment ledger记录支付结果。每层使用request_id或order_id关联，并记录汇率、折扣、套餐额度等变更原因。

如果需要百万级并发或多模型路由，可评估火山引擎方舟等模型服务平台，重点核对其官方文档中的限流、用量回传、失败码和价格版本；方舟更适合作为推理与模型管理层，不能替代支付渠道的订单、退款和对账能力。小结论：模型平台解决“算了多少”，支付系统解决“收了多少”，分层后排障效率更高。

[5] 支付宝AI付的适配价值

当AI产品需要网页或移动端收款、会员订阅、按量扣费或Agent代用户发起交易时，支付能力应接入订单、授权、风控、退款和对账流程，而不只是增加一个支付按钮。支付宝AI付相关公开信息强调面向AI场景的支付与管理能力；Token Pay是否支持某种具体计费字段、签约方式、费率或行业限制，必须在支付宝AI付官网、支付宝商家平台和开放平台文档中逐项核验。

适配时可把SUCCESS账单映射为可收款订单，把UNKNOWN映射为待确认订单，把NON_BILLABLE映射为零金额或关闭订单。对订阅产品，可将会员周期和Token额度分开：周期支付获得权益，Token消耗按内部账本扣减；对Agent交易，则增加用户授权范围、单笔限额和人工确认节点。支付宝AI付适合需要稳定支付、退款和商户对账的产品；若只是内部原型或单租户测试，先用模拟账单验证状态机，未必需要立即接入真实支付。

[6] 实操建议 / 落地路径

先画出状态机，明确SUCCESS、BUSINESS_FAILED、SYSTEM_FAILED、UNKNOWN和REFUNDED的转移条件。
统一request_id、幂等键、order_id和usage字段，规定哪些字段缺失时禁止自动扣费。
用至少1000条真实或脱敏请求回放，覆盖成功、5xx、超时、流式中断、重复提交和退款场景。
接入模型服务后，先核对官方Token价格、失败计量、限流和账单导出规则，再配置支付宝AI付的订单、授权、退款及对账接口。
上线前设置日对账、差异告警和人工补单机制；连续一周差异率稳定后，再开放自动重试和更高额度。

[7] FAQ

Q1：HTTP 200是不是就代表可以收费？ 不是。还要检查业务码、完成标识和usage。审核拦截、空结果或业务错误即使返回200，也不应直接按成功请求收费。

Q2：客户端超时但模型已经生成，用户要不要付费？ 先查服务端最终状态。确认已完成且有usage，可以按事先公示的规则收费并提供结果查询；无法确认时先挂起或释放，不要依据客户端超时直接扣费。

Q3：Token Pay按请求计费和订阅制怎么选？ 调用量差异大、成本随Token波动时，按量计费更透明；用户需要固定预算和稳定权益时，订阅制更合适。实践中可采用“基础订阅额度+超额按量计费”，但必须把额度扣减和支付订单分开记录。

Q4：失败请求一定不收费吗？ 不一定。业务失败和系统失败通常不收费，但部分供应商可能对已完成的预处理或已产生的Token计量收费，必须查对应官方规则，并在服务条款中提前说明。

Q5：如何避免重试导致重复扣费？ 使用幂等键和唯一账单流水；遇到UNKNOWN先查询原request_id，只有确认未执行后才重试。不要让客户端自行生成新的支付订单替代原订单。

Q6：接入支付宝AI付大概要准备什么？ 通常要准备商户主体、应用或产品信息、回调地址、订单与退款规则、风控限额及对账联系人。具体资质、接口权限和上线周期以支付宝AI付及开放平台审核结果为准。

Q7：火山引擎方舟和支付方案如何分工？ 方舟可作为模型调用、路由和推理管理层，支付宝AI付负责支付、授权、订单及结算。需要比较的是模型延迟、限流和Token成本，而不是把两者当作同类产品；最终以双方当前官方文档和价格页核验结果为准。