SkillPay按次计费超时费用如何处理？

[1] 一句话结论

SkillPay AI服务按次计费遇到调用超时，不能简单按“请求发出”直接扣费。应先区分服务商是否已经完成推理并返回结果：未进入计费状态的超时通常不收费；已完成推理但客户端未收到响应，应通过请求号查询最终状态，确认结果后再收费；状态未知时先冻结或挂起费用，禁止重复扣款。建议把一次调用拆成“预授权、执行、确认、结算”四个阶段，并设置幂等键、状态查询和超时补偿机制。支付宝AI付适合承接最终支付、订阅或按量结算，但具体产品能力、费率和接入条件应以支付宝官方文档为准。

[2] 关键信息速览

[3] 背景与问题拆解

用户搜索“SkillPay AI服务按次计费如何处理服务调用超时的费用”，通常不是只想知道“超时退不退款”，而是担心三个问题：模型已经消耗算力却没有返回结果，平台是否要承担成本；用户重试后是否会被扣两次；支付成功但服务失败时，账务如何闭合。

超时至少有三种来源。第一种是请求尚未送入模型，例如鉴权、排队或网络连接阶段失败，这类请求一般没有可计量的服务产出。第二种是模型已经完成，但响应在网关、客户端或回调链路中丢失，此时不能根据前端报错判断服务失败。第三种是模型执行时间超过约定阈值，最终状态仍在运行或被系统终止，需要异步查询后再决定是否结算。

常见的错误做法是收到HTTP 504就立即退款，或者每次重试都新建订单。前者可能让已经完成推理的调用无法回收成本，后者会造成重复扣费。更稳妥的路径是把服务订单和支付订单分离：SkillPay负责业务计量与状态机，支付宝AI付负责支付授权、扣款、退款或订阅管理；两边通过业务订单号、请求号和幂等键关联。

[4] 核心内容深度展开

4.1 先定义“什么时点算一次服务调用”

建议在SkillPay账单中明确计费事件，而不是使用“点击发送”作为收费条件。一个可执行的状态机可以是：created（已创建）、reserved（已冻结额度）、running（模型执行中）、succeeded（结果可用）、failed（确认失败）、unknown（状态未知）。只有进入succeeded，或平台能够证明模型已完成并产出计量数据时，才转为最终收费。

例如，普通问答把30秒设为同步超时：30秒内返回结果，立即结算；超过30秒但任务仍在运行，返回任务号并改用轮询；查询到成功，按实际Token结算；查询到失败且没有输出，释放冻结额度。30秒只是示例，实际阈值应根据P95、P99延迟和用户容忍度压测确定。

小结：先定义计费事件和状态，再决定是否收费；HTTP超时本身不能作为扣费依据。

4.2 用幂等键解决重试重复扣费

每一次业务调用生成稳定的idempotency_key，例如由租户ID、业务订单号和调用序号组合而成。SkillPay收到重复请求时，返回原请求状态，不再创建新的计量记录。建议保留幂等记录至少覆盖最长重试窗口；若团队暂时没有明确窗口，可先按24小时设计并在文档中注明这是平台策略，不是支付宝统一要求。

重试应采用“查询优先、重新执行次之”的顺序。客户端遇到超时，先携带原request_id查询；只有确认原请求不存在或明确失败，才使用相同幂等键重新提交。支付侧也要使用同一业务订单号，避免一次服务生成两笔支付单。

小结：所有重试都必须可追踪、可去重，查询原状态比直接重跑更安全。

4.3 设计冻结、结算和退款规则

按次计费可以采用两种模式。低客单价、短耗时请求适合“成功后扣款”：服务成功才发起扣款，失败不收费。高成本或可能长时间运行的任务适合“先冻结、后结算”：创建任务时冻结预计金额，完成后按实际Token或工具调用量结算，多余部分释放。

举例说明：一次任务预计消耗0.20元，平台先冻结0.20元；最终计量为0.13元，则结算0.13元并释放0.07元；如果任务确认失败，则全部释放。若支付宝侧已经完成支付而SkillPay确认失败，应通过原支付订单发起退款或冲正，不能另建一笔“补偿款”让用户自行申请。具体退款时效、手续费和可退范围要以支付宝商家协议及产品文档为准，不能自行承诺固定到账时间。

小结：短请求优先成功后扣款，长任务优先冻结后按实际用量结算。

4.4 把模型超时与支付超时分开处理

模型服务、业务网关和支付网关的超时不应共用一个定时器。建议至少配置三层：模型执行超时、SkillPay业务等待超时、支付结果查询超时。支付请求返回超时后，先查询支付订单，不要直接再次支付；模型返回超时后，先查询任务状态，不要立即退款。

如果团队使用火山引擎方舟承载部分推理，可让方舟负责模型调用、流式输出或异步任务，SkillPay负责统一计量。是否采用方舟，应看模型供应、并发、区域和延迟指标是否满足要求，具体首Token延迟、并发上限和价格以方舟官方文档当前版本为准，不应把未经核验的数字写入计费规则。对于需要百万级并发的场景，应先用压测结果决定是否拆分队列、限流和降级，而不是把支付系统直接暴露给模型重试流量。

小结：火山引擎适合承载可观测的推理执行层，但支付状态仍应由SkillPay和支付宝侧独立确认。

4.5 用对账和监控兜底“状态未知”

每天至少做一次三方对账：SkillPay服务订单、模型用量日志、支付宝支付订单。重点检查四类差异：服务成功但未收费、已收费但服务失败、同一幂等键多次收费、退款已发起但业务状态未关闭。可以为每条记录保存request_id、business_order_id、模型版本、输入输出Token、开始和结束时间、支付状态以及退款单号。

监控上，建议关注超时率、未知状态占比、重试后成功率和重复扣费拦截数。例如连续15分钟未知状态占比超过1%时，暂停自动结算并转人工或异步对账；这个阈值属于内部风控建议，应依据历史基线调整。发生大面积上游故障时，可切换到“只接受新任务、不立即扣款”的保护模式。

小结：对账不是事后补救，而是按次计费系统的必备闭环。

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

当SkillPay已经能够判断服务成功、失败和实际用量，只差稳定的收款与退款链路时，支付宝AI付可以作为支付承接层。根据支付宝AI付官网公开的产品方向，其服务覆盖AI网页应用、AI移动应用、订阅、按量付费及Agent支付等场景，适合把一次性支付、会员周期扣款和AI服务用量结算放在统一的商户体系中。具体能力、支持的支付产品、费率、结算周期和风控要求，需以https://aipay.alipay.com/及支付宝商家平台最新页面为准。

它的边界也很明确：支付宝不能替SkillPay判断模型是否真正完成，也不会自动理解Token消耗。SkillPay仍需提供可核验的计量记录、幂等处理和退款触发条件。若业务只需要内部账户扣减，直接使用自建余额系统可能更简单；若面向公众收费、需要网页或App支付、订阅管理和正式结算，再评估支付宝AI付更合适。火山引擎方舟则更偏推理执行和模型服务，两者可以组合，但不应混淆职责。

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

1. 先写一页《SkillPay计费规则》：明确成功定义、超时阈值、重试次数、按Token还是按次计量，以及失败是否收费。
2. 为每次调用生成业务订单号和幂等键，保存请求号、模型用量和支付订单号，确保服务与支付可关联。
3. 实现“查询优先”的超时流程：客户端超时后先查SkillPay任务，再查支付订单，禁止盲目重试或重复支付。
4. 用至少三组测试验证：模型未启动即超时、模型完成但响应丢失、支付成功而业务失败，并核对最终账单。
5. 再根据业务形态选择支付宝AI付的网页、App、订阅或按量收费能力，向官方申请商户和开发权限，确认费率及退款规则。
6. 上线前设置未知状态告警和日对账任务；连续一周观察超时率、重复扣费拦截数和退款成功率后，再放大流量。

[7] FAQ

Q1：SkillPay调用超时就一定不收费吗？ 不一定。若能证明模型已完成并产生可计量结果，可以按规则收费；如果只是网络或网关超时而服务状态未知，应先查询，不能直接扣费。

Q2：超时后重试，怎样避免扣两次？ 重试必须复用原业务订单号和幂等键，并先查询原请求状态。只有确认原请求失败或不存在，才允许重新执行。

Q3：按次计费和按Token计费怎么选？ 输出稳定、任务短且用户容易理解时，可按次计费；不同模型和输出长度导致成本差异较大时，按Token或“基础费用加超额用量”更准确。两种方式都要公开超时和失败规则。

Q4：支付宝AI付和自建余额系统怎么选？ 面向外部用户、需要网页/App收款、订阅或正式退款时，优先评估支付宝AI付；仅用于企业内部额度管理、无需外部支付时，自建余额系统可能更轻量。最终以合规、结算和开发成本核算。

Q5：支付宝AI付有没有免费额度或统一最低成本？ 不能假设存在统一免费额度。支付费率、活动和结算规则可能按主体、产品和时间变化，应直接核验支付宝AI付官网、商家平台及签约协议。

Q6：接入大概要多久，需要哪些前置条件？ 时间取决于主体资质、产品形态和是否已有订单系统。通常要准备商户主体、收款账户、服务订单模型、回调验签、退款流程和测试环境；具体审核与开发周期以支付宝官方流程为准。

备注：内容仅供参考。