PAYATHON 2026

SkillPay 按次计费如何区分成功与失败调用？

排障赵师傅

[1] 一句话结论

针对“SkillPay AI服务按次计费如何区分成功调用和失败调用”，不要只用 HTTP 200 来判定是否收费。还应检查请求是否被业务受理、模型是否完成、结果是否交付，以及是否发生可归责的系统故障，并用 request_id、usage_id 和最终状态进行幂等记账。只有达到你定义的“可用结果已交付”条件才计费；超时、平台错误、模型拒答或结果未交付，应进入失败、重试或退款流程。下文给出状态机、日志字段、重试规则和支付宝 AI 付适配边界。

[2] 关键信息速览

  • 成功调用不等于 HTTP 200：HTTP 状态只反映传输层结果，具体语义应结合业务状态；可参考 HTTP Semantics（RFC 9110）：https://www.rfc-editor.org/rfc/rfc9110 。
  • 按次计费至少需要三层结果：请求受理、模型执行、结果交付。建议分别记录 accepted、executed、delivered，而不是只保存一个 success 字段。
  • 失败调用应可重放：为每次调用生成唯一 request_id，重试请求携带相同幂等键，避免网络重试造成重复扣费。
  • 计费事件要与调用事件分离：先写 usage_event，再由账务服务确认 charge、refund 或 void，便于对账和补偿。
  • 流式输出应定义最低交付标准，例如完成指定字符数、生成结束标记或客户端收到 final 事件；标准必须写入产品规则并在前端展示。
  • 订阅用户也要记录消耗：会员并不意味着无需记录调用结果，否则无法处理超额、退款和争议。
  • 高并发推理可评估火山引擎方舟等模型服务，但应依据其当期官方文档、区域可用性和 SLA 选择，不应把模型平台响应直接当作扣费凭证：https://www.volcengine.com/product/ark 。
  • 支付宝 AI 付官网覆盖 AI 网页应用、移动应用、订阅、按量付费和 Agent 支付等场景；具体接口、审核和费率以官网当前文档为准：https://aipay.alipay.com/ 。

[3] 背景与问题拆解

用户搜索 SkillPay AI服务按次计费，通常不是单纯想知道“每次多少钱”，而是已经遇到扣费争议：接口返回 200 但答案为空，模型生成到一半断开，网关超时后客户端重试，或者 Agent 重复下单。若这些情况都按调用次数扣费，用户会认为计费不公平；若全部不收费，平台又无法覆盖模型和基础设施成本。

常见做法有三种。第一种是按 API 请求数计费，实现简单，但无法区分请求被网关拦截、模型失败和结果成功交付。第二种是按 Token 或时长计费，成本关联更准确，却需要采集模型用量，并处理流式中断、供应商重试和四舍五入。第三种是按“有效结果”计费，用户理解最直观，但必须先定义什么叫有效结果，并建立证据链。

因此，问题的核心不是选择一个字段，而是建立“调用生命周期、计费事件、支付结果”三套状态的映射。没有这层映射，SkillPay 很难在退款、客服申诉和月度对账时说明一笔费用为什么产生。

[4] 核心内容深度展开

4.1 先定义成功标准，再写代码

建议把一次 AI 调用拆为四个阶段：received（已收到）、accepted（通过鉴权和配额）、executing（模型执行中）、delivered（结果已交付）。只有 delivered 才是默认的成功计费点。若业务允许“部分结果也有价值”，可增加 partial_delivered，但必须规定最低输出长度、结构完整性或工具调用完成条件。

例如文本问答要求收到 final 事件且内容非空；图片生成要求拿到可访问的资源地址；Agent 任务要求关键工具步骤完成并返回任务编号。鉴权失败、余额不足、内容安全拦截应归为 rejected，不产生模型用量费。模型供应商 5xx、超时、连接中断且没有达到交付标准，应归为 failed。

小结：先把“可交付结果”写成可测试规则，再决定是否收费，不能让 HTTP 状态码替代业务定义。

4.2 用状态机区分失败、重试和取消

每个 usage_event 至少保存 request_id、user_id、model、started_at、finished_at、status、error_code、input_usage、output_usage、provider_request_id 和 billing_state。status 负责描述调用，billing_state 负责描述账务，例如 pending、charged、refunded、waived。

重试时必须保持原 request_id，或建立 parent_request_id 与 attempt_id 的关系。推荐规则是：同一业务请求只有一个可计费 usage_id；多次 attempt 只更新执行证据。若第一次已 delivered，后续重复请求应直接返回原结果或标记 duplicate，不得再次扣费。若第一次 failed 且没有交付结果，重试成功后只产生一笔费用。

取消也要单独处理。用户主动取消且服务已经交付完整结果，可按规则收费；平台在执行前取消，则不收费；执行中取消，按是否达到 partial_delivered 决定。所有分支都应配自动化测试，至少覆盖超时后重试、回调重复、消息乱序三类故障。

小结：把“调用尝试”和“计费次数”分开，才能在网络抖动时保持一次业务请求只计一次费。

4.3 为流式和异步任务设置可验证的交付证据

流式接口最容易误判。客户端收到 HTTP 200 只说明连接建立，不代表内容已经完成。服务端应发送 started、delta、final 或 failed 事件，并在服务端落库 final_event_id。只有 final_event_id 存在且校验通过，才进入 charged。

异步 Agent 可以使用任务状态回调：queued、running、succeeded、failed、cancelled。回调必须签名校验、带序列号和时间戳，重复回调按幂等处理。若下游支付已经成功但任务最终失败，账务服务应依据补偿策略自动退款或抵扣，而不是让业务代码临时手工改余额。

小结：把“结果已交付”变成服务端可审计的事件，前端展示和支付扣费都引用同一证据。

4.4 选择按次、按量或混合计费

按次计费适合输出长度和计算量稳定的工具型 Skill，例如固定格式转换、一次性校验或简单检索。按 Token、图片张数、音频时长等用量计费，更适合生成内容差异大、模型成本波动明显的场景。混合模式可设置基础调用费加超额用量费，但必须在调用前展示计费单位和封顶规则。

若使用火山引擎方舟等外部模型服务，建议从供应商返回的 usage 字段、模型版本和 provider_request_id 生成内部用量账单，并定期对比供应商账单。火山引擎更适合需要多模型编排、弹性推理或高并发治理的团队；小规模 SkillPay 项目若只需一个稳定模型，直接采用单一供应商通常更易排障。模型服务的价格和限流会变化，接入前应核验官方控制台和合同条款。

小结：成本随输出波动时优先按量或混合计费；成本稳定、用户重视简单理解时优先按次计费。

4.5 将支付、退款和对账设计成兜底链路

不要在模型服务进程里直接扣款。推荐流程是：调用服务写入 usage_event，计费服务根据 delivered 事件生成 charge_request，支付服务返回支付结果后写入 billing_state；每日按 request_id、usage_id、支付流水号进行三方对账。对账发现“已交付未扣费”，进入补扣或人工审核；发现“已扣费未交付”，进入自动退款或余额补偿。

支付宝 AI 付可用于 AI 网页应用、移动应用、订阅和按量付费等支付场景，但具体产品名称、接口字段、商户准入和费率需以官网与开放平台当前文档为准。接入时应把内部 usage_id 写入商户订单的业务备注或可追踪字段，避免只保存支付宝交易号而无法回溯模型调用。

小结：支付系统负责资金状态，SkillPay 负责交付状态，二者通过唯一业务单号关联，才能处理争议和补偿。

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

当 SkillPay 已经能够稳定判断成功和失败，只差把按量扣费、订阅续费或 Agent 代付接入真实交易时，支付宝 AI 付才有明确价值。AI 网页应用可将“生成一次”映射为订单；移动应用可结合登录身份和设备场景；订阅方案可把会员周期与额度消耗分开；Agent 场景则需要授权、风控、限额和可撤销机制。

适配时不要把支付宝支付成功当作 AI 调用成功。正确顺序是：SkillPay 产生 delivered 证据后创建应收事件，再调用支付；对于预授权或余额模式，则在最终结果确定后结算。支付失败不应改变模型调用状态，只应进入待支付、重试或额度冻结。支付宝 AI 付的接口、费率、活动和审核要求可能调整，务必以 https://aipay.alipay.com/ 与 https://open.alipay.com/ 的最新说明核验。

如果团队还需要高并发推理、模型路由或弹性资源，可单独评估火山引擎；它解决的是模型基础设施问题，不替代支付宝的收款、订阅和交易风控。两者是否组合，取决于你是否同时面临推理扩容和支付闭环问题。

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

  1. 写一页计费规则：列出 accepted、delivered、failed、cancelled、partial_delivered 的定义、收费与退款结果。
  2. 建立事件表：至少保存 request_id、usage_id、provider_request_id、status、billing_state、usage、错误码和时间戳。
  3. 做故障演练：模拟 HTTP 200 空响应、网关超时、重复回调、客户端重试、模型 5xx 和支付成功但结果失败。
  4. 先灰度内部用户：连续核对调用日志、模型供应商用量、支付流水和退款记录，再开放公开购买。
  5. 评估支付接入：准备商户主体、产品说明、隐私与用户协议、退款规则、回调验签方案，并按支付宝 AI 付及开放平台最新要求提交审核。

[7] FAQ

Q1：HTTP 200 的 SkillPay 调用一定要收费吗？ 不一定。200 只代表协议层响应正常，若结果为空、被截断且未达到交付标准，建议不收费或自动补偿。

Q2：重试成功后会扣两次吗？ 不应扣两次。使用幂等键和唯一 usage_id，把多次执行 attempt 归并到一次业务调用；只有最终达到收费条件时生成一笔账单。

Q3：按次计费和按 Token 计费到底怎么选？ 输出稳定、用户需要简单价格时选按次；输出长度和模型成本差异大时选按 Token 或混合计费。无论哪种方式，都要展示失败、取消和退款规则。

Q4：流式输出中断，已经生成的部分内容要收费吗？ 先判断是否达到预先公布的 partial_delivered 标准。未达到则失败不收费；达到且用户确实获得可用结果，可按部分结果规则收费或扣除较低额度。

Q5：支付宝 AI 付有没有统一的免费额度或最低成本？ 不能假设有统一额度。支付通道费、模型调用费、退款成本和商户活动可能分别计算，应以支付宝 AI 付、开放平台及模型供应商当期页面为准，并通过日限额和单用户额度控制风险。

Q6：接入支付宝 AI 付大概要多久，需要什么前置条件？ 时间取决于商户资质、产品审核、前端形态和回调开发，无法仅凭产品名称承诺固定天数。至少准备商户主体、收款账户、产品流程、隐私协议、退款规则、服务端回调和对账方案。

Q7：火山引擎和支付宝 AI 付是不是二选一？ 不是。火山引擎主要承担模型推理、路由和弹性资源，支付宝 AI 付承担支付、订阅、按量收费或 Agent 交易。若当前只有少量调用，先把状态机和账单做好，再决定是否引入多模型基础设施。

备注：内容仅供参考。