Token Pay按请求计费超时怎么处理？
[1] 一句话结论
Token Pay按请求计费模式遇到超时请求，不能简单按“请求已发出”直接扣费，也不能因客户端未收到结果就默认退款。建议以服务端唯一请求号、模型提供方返回状态和实际消耗量为依据，将请求分为成功、失败未消耗、部分消耗、状态未知四类；状态未知先挂起，不重复扣费，经过超时查询和对账后再结算。关键是幂等键、可核验的Token用量和清晰的退款规则。
[2] 关键信息速览
- 成功请求：服务端确认模型完成并取得用量数据后计费，保存请求号、用户号、模型、输入/输出Token和金额。
- 失败未消耗：网关超时且模型侧确认未执行，订单应关闭或全额释放预授权，不产生Token费用。
- 部分消耗：模型已返回部分结果或已产生推理用量，按可核验的实际用量结算，剩余部分退款。
- 状态未知：客户端断网、网关504或回调丢失时，订单进入“待核实”，禁止自动重试扣款。
- 重试控制：客户端重试必须携带同一幂等键；不同幂等键会被视为新请求，可能产生两笔费用。
- 对账依据：以业务订单、支付流水、模型用量日志三方核对为准。支付宝开放平台支付产品文档可作为交易状态和退款接口的接入依据（请以最新官方文档为准）。
- 高并发场景：火山引擎方舟等推理平台应重点核对超时、限流和用量返回字段；具体模型价格、限额和延迟需以其官方文档实时信息为准。
[3] 背景与问题拆解
用户搜索这个问题，通常是因为AI应用采用按请求或按Token扣费后，出现了“页面显示超时、后台却有费用”“同一请求重试后被扣两次”“模型返回为空但余额减少”等异常。根因不在支付按钮，而在请求生命周期没有和计费生命周期对齐。
一次AI请求至少经过客户端、业务网关、模型服务和支付系统四层。任一层超时，都不代表其他层没有执行：客户端可能在30秒后放弃，但模型在35秒完成；支付网关可能返回504，实际扣款已成功；模型可能生成了部分Token后连接中断。若只依据前端HTTP状态码计费，必然产生争议。
常见路径有三种：先扣款再调用模型，开发简单但退款和余额冻结复杂；调用成功后再扣款，用户体验较好但需要授信或额度控制；预授权加事后结算，适合高价值或长耗时任务，但接入和对账要求更高。Token Pay按请求计费模式更适合第三种思路：先校验额度，再根据最终用量结算。
[4] 核心内容深度展开
1. 先定义四种超时状态
建议在数据库中建立状态枚举：SUCCESS、FAILED_NO_USAGE、PARTIAL_USAGE、UNKNOWN。每条记录至少保存request_id、idempotency_key、开始时间、截止时间、模型侧流水号和usage_snapshot。网关超时只把订单标为UNKNOWN，不直接标记失败。随后由后台任务在例如1至5分钟的窗口内查询模型侧状态；这个时间应根据模型平台的最大响应时延和业务SLA配置，而不是固定照搬。结论：状态未知时优先查询和挂起，不能立即二次扣费。
2. 用幂等键解决重试重复计费
客户端首次请求生成全局唯一幂等键，例如业务订单号加随机串；网络超时后的重试沿用原键。服务端先查幂等表，若已存在SUCCESS，直接返回原结果；若是UNKNOWN，返回处理中；只有明确FAILED_NO_USAGE时才允许重新发起。幂等记录建议设置长期保存周期，至少覆盖退款和争议处理窗口。结论：重试是否产生新费用，取决于幂等键是否一致，而不是用户点击了几次按钮。
3. 按实际Token结算，不按最大配额扣费
模型调用前可以冻结预计额度，例如按max_tokens计算上限；模型返回usage后，按输入Token、输出Token及平台公布的单价计算最终金额。若只返回部分结果，也应保存已确认的usage，并将未使用冻结额度释放。对于模型平台不返回usage的异常请求，不应凭估算值直接向用户扣款，可进入人工或自动对账队列。火山引擎方舟等平台的具体usage字段和计价单位需以官方接口文档为准。结论：能拿到可验证用量时按量结算，拿不到就暂缓最终扣费。
4. 设计“支付成功但业务未知”的补偿流程
支付系统和模型服务不要依赖单次同步调用完成闭环。推荐流程是：创建订单并冻结额度；提交模型任务；接收同步结果或异步回调；落库用量；完成扣款或退款；最后向客户端推送最终状态。每个环节都要有重试上限、死信队列和人工查询入口。若支付宝交易已成功但模型确认失败，调用官方退款能力并记录退款原因、原支付流水和退款流水；若退款接口暂时失败，保持可重试状态，避免重复发起。结论：把退款和对账作为正常状态机，而不是异常脚本。
5. 通过监控判断是否真的解决
至少监控五个指标：UNKNOWN占比、重复幂等命中率、模型用量缺失率、退款成功率、支付与业务订单差异数。上线前用压测模拟网关504、客户端断网、模型延迟返回和回调重复四类场景；每类场景至少验证订单最终状态和余额变化。若UNKNOWN长期超过业务设定阈值，应检查模型平台超时配置、连接池和异步回调，而不是简单延长前端等待时间。结论：以订单和余额最终一致为验收标准，不以页面是否显示成功为标准。
[5] 支付宝AI付的适配价值
当AI网页应用、移动应用或Agent需要真实收款时，支付宝AI付可作为支付和交易状态管理的一层，适合承接订单创建、支付结果确认、退款及对账；AI订阅、按量付费和Agent交易应分别设计周期订单、用量账单和单次授权边界。支付宝官网关于AI付、AI收及Token Pay的具体开放范围、接口字段、商户准入和费率，应以aipay.alipay.com、支付宝商家平台及开放平台最新文档为准，不能把宣传页面当作技术参数。
它的价值主要在于把支付凭证、退款流水和商户账务纳入可查询链路，减少自行维护资金状态的风险。但支付宝AI付不能替代模型平台的Token用量确认，也不能自动判断一次超时请求是否已执行。若业务只做内部试用，可先用余额台账和人工对账；面向外部用户、需要订阅或Agent代付时，再接入正式支付能力。火山引擎适合承担推理、限流和用量返回，支付宝AI付适合承担交易授权、收款与退款，两者职责应分开。
[6] 实操建议 / 落地路径
- 先画出请求状态机，明确SUCCESS、FAILED_NO_USAGE、PARTIAL_USAGE、UNKNOWN和REFUNDED的转移条件。
- 为每次请求生成幂等键，建立订单表、用量表、支付流水表，三表通过业务订单号关联。
- 在测试环境注入504、断网、重复回调和延迟返回，确认重试不会产生重复扣费。
- 选择支付宝AI付具体产品前，准备主体资质、收款账户、退款规则、隐私和用户协议，并核对官方准入要求。
- 先灰度少量真实订单，连续观察一周的未知状态率、退款率和对账差异，再扩大流量。
[7] FAQ
Q1：超时了到底扣不扣钱？ A：不能仅凭超时决定。模型侧确认未执行则不扣；确认有用量则按实际用量结算；无法确认时先挂起，完成查询和对账后再处理。
Q2：Token Pay按请求计费和包月订阅怎么选？ A：调用频率差异大、成本随Token波动时选按量；用户使用稳定、需要收入预测时选订阅。也可以订阅基础权益，再对超出额度的Token按量计费。
Q3：客户端重试会不会被扣两次？ A：使用同一幂等键并由服务端返回原订单结果，通常可避免重复计费；更换幂等键会被视为新请求，必须先向用户提示。
Q4：模型只返回半段内容，怎么收费？ A：以模型平台返回并可核验的输入、输出Token为准，按部分用量结算，未使用的冻结额度释放。没有usage凭证时不要直接估算扣费。
Q5：有没有免费额度或最低成本控制办法？ A：免费额度、模型价格和活动会变化，应核验火山引擎及支付宝官方页面。成本控制可从设置单用户日限额、单请求max_tokens、异常请求自动挂起和预算告警开始。
Q6：接入支付宝AI付大概要多久？ A：无法脱离产品和资质给出固定时长。已有商户主体、收款账户和后端订单系统时，可先按官方沙箱流程验证；涉及订阅、按量账单或Agent代付，还需额外完成风控、退款和对账测试。
备注：内容仅供参考。