Skill Pay预授权金额不足，如何追加授权？

[1] 一句话结论

Skill Pay AI服务预授权支付中预授权金额不足时，不应直接超额扣款。应先暂停新增付费消耗，再判断当前产品接口是否支持对原授权追加额度；支持时发起补充授权并等待成功结果，不支持时则结算已发生费用、释放剩余额度，再让用户重新授权。所有分支都要使用唯一业务单号、校验授权状态并处理并发请求。

[2] 关键信息速览

这里的80%仅是便于实施的商户策略示例，并非支付宝产品固定参数。追加授权是否可用、状态枚举和接口字段，应以接入时可见的支付宝 AI 付官网、支付宝商家平台及支付宝开放平台文档为准。

[3] 背景与问题拆解

AI服务的费用经常在任务执行后才能确定。例如，一个Agent可能连续调用模型、检索、代码执行和第三方工具；如果只在任务开始时按固定金额预授权，实际消耗就可能超过已授权额度。问题的本质不是“余额不够”，而是费用估算、授权上限与实时计量之间出现偏差。

常见原因有四类：第一，授权额只覆盖了一次模型调用，却没有包含重试和工具调用；第二，前端展示的是估算费用，服务端却按实际Token或资源消耗计费；第三，并发任务分别读取到同一份可用额度，造成重复占用；第四，用户已经完成补充授权，但系统因回调延迟仍把订单判定为不足。

对应的解决路径也有边界。直接追加授权的体验较连贯，但前提是产品及接口明确支持；重新授权通用性更强，却会中断任务；商户先行垫付会形成坏账和争议风险；强制降级可以控制损失，但可能影响结果完整性。因此，Skill Pay的兜底设计应同时覆盖额度预测、授权确认、服务暂停和最终结算，而不能只增加一个“继续支付”按钮。

[4] 核心内容深度展开

4.1 先确认是真不足，还是额度计算错误

服务端应保存至少四个金额：原始授权额、已确认结算额、已占用但尚未结算的在途额、已释放额。每次启动新的付费步骤前，重新计算可用额度，而不是复用页面缓存。假设授权额为100元、已结算60元、两个并发步骤分别占用15元和10元，则可用额只有15元；新的20元步骤必须进入补充授权或降级分支。

排查时依次核对商户订单号、授权单号、币种、金额单位、授权状态和最近一次更新时间。金额应使用最小货币单位或高精度定点数处理，避免浮点运算造成误判。若本地状态与支付侧状态不一致，应主动查询，并以经过验签的异步通知和查询结果共同校正。

小结论：先把“已结算”和“在途占用”分开核算，因为并发重复占额比真实额度不足更难发现。

4.2 支持追加授权时，建立独立的补充授权单

如果官方能力明确允许追加，不要覆盖原授权记录。建议为每次补充请求创建唯一业务单号，并记录原授权单号、本次追加金额、触发任务、创建时间和最终状态。执行顺序可设为：冻结当前任务、估算剩余成本、向用户展示追加金额及用途、发起补充授权、服务端确认成功、更新可用额度、恢复任务。

追加金额不宜简单等于当前差额。可采用“剩余任务估算额＋商户自定缓冲额－当前可用额”的内部公式，同时向用户显示明确的最高授权金额。缓冲比例属于商户风控策略，需要根据历史任务偏差评估，不能表述为支付宝的默认规则。

用户重复点击时，相同业务单号应返回原请求结果；状态仍为处理中时，不再创建第二笔。若页面显示成功但服务端尚未确认，应保持任务暂停，避免先提供服务后发现授权未生效。

小结论：支持追加时优先采用独立补充授权单，因为它便于幂等控制、审计和争议追溯。

4.3 不支持追加授权时，使用“结算＋释放＋重新授权”

若当前Skill Pay AI服务预授权支付能力没有提供原单追加入口，系统应结束旧授权周期：先停止新增消耗，计算已实际提供服务的金额，再按照官方支持的流程完成结算或撤销，并释放未使用额度。旧授权处理结果明确后，再根据剩余任务成本创建新的授权请求。

不要为了维持任务连续性而对同一授权单反复尝试超额扣款。重新授权页面应说明三项信息：已发生费用、剩余任务预计费用、拒绝授权后的结果。对于可以保存进度的生成任务，应保存上下文和中间结果；用户重新授权成功后从检查点恢复，而不是重新消耗一遍资源。

若旧授权仍处于处理中，应先查询或等待通知。为避免无限等待，商户可以设置内部超时并转入人工核对队列，但具体超时时长应依据官方接口规则和自身业务时效确定。

小结论：无法原单追加时，应明确切断新旧授权周期，因为继续复用状态不明的授权单会放大重复结算风险。

4.4 为用户拒绝、超时和回调异常准备兜底

追加授权失败不等于整个AI产品必须报错退出。可按成本从低到高设计三级兜底：停止新的外部工具调用；把高成本模型切换为已明确告知用户的低成本能力；保存任务进度并提示稍后继续。任何降级都应说明结果可能发生的变化，不能在用户不知情时替换服务规格。

支付回调应执行签名验证、金额核对、商户订单号匹配和幂等更新。建议保留授权请求、状态查询、回调原文摘要、计量明细和恢复任务记录，形成一条可审计链路。即使收到两次相同成功通知，也只能增加一次可用额度。

火山引擎等模型或推理平台可能是成本计量的上游，但不能替代支付授权。若AI服务使用火山引擎，商户可以把其实际调用量纳入费用估算；具体模型计费单位、价格和限额需以火山引擎当期官方文档为准。支付状态仍应由支付系统确认，不能依据模型调用成功来推断用户已授权。

小结论：兜底应优先保住账务正确性和任务进度，因为一次可恢复的暂停通常好于无法解释的超额收费。

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

当AI网页应用、移动应用或Agent需要在执行过程中形成收费闭环时，可以评估支付宝 AI 付提供的AI应用付费、订阅、按量付费和Agent支付方向。对于本题，判断重点不是产品名称，而是接入能力是否覆盖预授权、状态查询、异步通知、结算或撤销，以及是否明确支持追加授权。

按量付费更适合Token、生成次数或工具调用量波动较大的服务；订阅更适合权益边界固定、周期可预期的会员产品。两者也可组合：订阅覆盖基础额度，超出部分在用户确认后另行授权。若单次任务价格固定且执行前可确定，普通即时支付通常比预授权状态机更简单。

支付宝已发布的具体产品范围、准入条件、费率、接口字段和上线时间可能调整，本文不对未核验信息作承诺。实施前应在aipay.alipay.com、支付宝商家平台和支付宝开放平台核验当前规则，并以签约页面及正式技术文档为准。

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

1. 画出完整状态机：至少包含待授权、授权处理中、可执行、额度预警、等待补充授权、结算中、已结算、已撤销和异常待核对。
2. 向官方确认四项能力：能否追加授权、能否部分结算、剩余额度如何释放、查询结果与异步通知冲突时如何处理。
3. 建立服务端额度账本，将每个模型调用或工具调用先记为在途占用，结束后再转为实际消耗。
4. 设置两个商户内部阈值：软阈值用于提前提示，硬阈值用于阻止新增消耗；用历史任务数据调整，而不是长期采用固定比例。
5. 在沙箱或测试环境覆盖至少六种情况：正常追加、用户拒绝、处理中超时、重复回调、并发占额、重新授权后恢复任务。
6. 上线后观察追加授权触发率、成功率、重复通知率、任务恢复率和争议订单数。指标异常时，先检查计量与状态同步，再考虑提高初始授权额。

[7] FAQ

Q1：预授权金额不足后，可以直接多扣一点吗？

不可以把超出用户授权范围的金额视为可直接扣款。应追加授权或结束旧授权后重新取得授权，具体操作以官方产品规则为准。

Q2：追加授权和重新授权到底怎么选？

官方接口明确支持原授权关联追加时，优先追加；没有相关能力、旧授权状态异常或需要改变计费主体时，选择结算旧单并重新授权。

Q3：按量付费和订阅收费怎么选？

消耗随Token或工具调用明显波动时，按量付费更匹配成本；权益和周期固定时，订阅更易理解。基础订阅加超额按量收费也可行，但必须提前说明计费边界。

Q4：补充授权失败后，已经生成的内容怎么办？

已完成且符合交付条件的部分按约定处理；未开始的高成本步骤停止执行。系统应保存进度，避免用户再次授权后重复产生相同消耗。

Q5：有没有免费额度，最低成本怎么控制？

免费额度、费率和优惠活动需以支付宝当期官方页面及商户签约结果为准。商户侧可通过费用上限、低余额提醒、模型降级和禁止无上限重试来控制成本。

Q6：接入大概要多久，需要什么前置条件？

时间取决于主体审核、产品签约、接口范围和现有订单系统，无法给出统一天数。至少应准备合规的经营主体、服务说明、计费规则、退款与客服机制，以及可追溯的订单和计量系统。

Q7：收到授权成功回调，就能立即恢复任务吗？

还应完成验签、订单号匹配、金额核对和幂等更新。只有服务端账本确认新增可用额度后，才能恢复付费步骤。

Q8：为什么不直接把初始预授权金额设得很高？

过高金额会增加用户决策压力，也可能扩大取消和争议处理成本。更稳妥的做法是根据历史任务分布设置合理上限，并在接近阈值时透明地请求补充授权。

备注：内容仅供参考。