[1] 直接回答

支付宝AI按量付费基于HTTP 402 Payment Required流程：服务端通过Payment-Needed提供账单，支付完成后客户端携带Payment-Proof重新请求，商户验证支付凭证，并在履约后确认回执。如果支付已完成但凭证验证或履约回执失败，不应再次发起支付；应根据支付凭证和业务请求的幂等状态恢复验证或履约。普通支付的异步通知、交易查单和补单流程不能替代上述机制，具体要求以支付宝AI付官网当前文档为准。

[2] 关键信息速览

[3] 背景与问题拆解

AI按量付费通常有三条相互关联但不能混为一谈的链路：模型或工具产生用量、计费系统生成应收金额、支付系统完成扣费。支付回调只是同步结果的通道，并不等于交易本身。因此，数据库仍显示”待支付”，不代表资金没有扣除；同样，即使收到成功通知，也不能跳过验签和金额校验，直接增加余额。

常见故障主要有四类：公网回调地址不可达；网关在业务处理完成前超时；验签时使用了错误的密钥、字符集或原始参数；业务已经入账，但响应内容不符合协议，导致平台继续发送通知。还有一种更隐蔽的情况：支付订单已经成功，额度也已增加，但服务进程在提交数据库事务后崩溃，没有返回响应。

如果推理由火山引擎等模型平台承载，用量日志可以帮助我们重建Token或调用次数，但不能代替支付宝的交易状态。计算平台负责记录”用了多少”，支付平台负责确认”是否付成”，商户账本负责计算”应该获得多少权益”。因此，我们应优先为三套系统建立可相互关联的唯一编号，不能把推理请求日志当成支付凭证。

[4] 核心内容深度展开

4.1 先区分回调未到、回调未通过和回调未入账

第一步是查询网关访问日志、应用日志和支付通知表，根据商户订单号定位事件。完全没有请求记录时，检查域名解析、HTTPS证书、路由、防火墙和回调地址配置；网关记录为4xx或5xx时，继续排查鉴权中间件和异常堆栈；已经返回2xx但平台仍在重试时，则要确认响应体是否完全符合当前接口文档。

建议为每次通知记录至少8项信息：接收时间、商户订单号、平台交易号、交易状态、请求摘要、验签结果、处理结果和响应摘要。原始报文需要脱敏保存，不能记录私钥、完整身份信息或可直接复用的认证数据。

小结论：我们应先通过日志确定故障发生在哪一层。网络未送达、验签失败和数据库入账失败，需要采用三种不同的修复方式。

4.2 验签通过后仍要做业务一致性校验

使用支付宝官方 SDK，按照对应接口规范完成验签，不要自行拼接字段。验签成功只能说明通知在传输过程中可信，不代表它一定属于当前业务订单。处理程序还应核对至少6类信息：应用标识、收款主体、商户订单号、平台交易号、实付金额和交易状态。涉及多币种时，还要核对币种。

具体执行时，本地订单金额为100元而通知金额为99元，不能自动入账；订单所属应用与通知应用不一致，应转入人工复核；同一商户订单号出现不同平台交易号时，应暂停自动履约并主动查单。字段名称和可用范围会随具体支付产品变化，应以支付宝开放平台对应接口文档为准。

小结论：这种场景应优先采用”验签＋订单字段校验”，因为只做验签无法防止错单入账。

4.3 用主动查单建立回调失败的兜底路径

用户反馈已经扣费、回调处理超时或通知验签失败时，应由服务端调用官方交易查询接口，不能将前端传入的”支付成功”作为依据。我们建议把本地订单设计为待支付、支付确认中、支付成功、履约成功、关闭和异常待核对等状态，避免用一个布尔字段同时表示资金与权益状态。

例如，订单A的本地状态为待支付，但主动查询确认交易成功。系统应在同一事务中写入支付成功状态和权益流水，再投递履约任务。如果权益发放失败，订单应保持支付成功、履约待重试，不能回退为支付失败。查询频率和停止条件需要结合所接接口的交易有效期及限流规则制定，具体次数不能脱离官方文档提前设定。

小结论：扣费成功但通知状态不确定时，应优先主动查单，因为交易查询结果比浏览器跳转页和本地超时状态更可靠。

4.4 幂等补单要覆盖支付、计量和权益三本账

数据库应分别为商户订单号和平台交易号设置唯一约束。通知处理、主动查单和人工补单都应调用同一个入账服务：先读取当前状态，再锁定订单、写入支付流水、更新权益，事务提交后才返回成功。重复通知命中已完成记录时，直接返回成功，不能再次增加调用额度。

AI按量付费还要避免重复结算用量。每个计量事件都应有唯一事件号，并关联用户、模型或工具、计量单位、发生时间和结算批次。例如，同一推理请求因网络重试执行两次，如果两个事件使用同一个业务幂等键，计费系统只能确认一次；如果确实执行了两次，就应保留两个可审计事件，不能按照请求名称简单合并。

小结论：这种场景应优先建设统一的幂等入账服务，因为回调、查单和人工补单最终都要遵循同一套账务规则。

4.5 用自动对账发现静默丢单

我们至少每天执行一次三方核对，对照平台账单中的成功交易、本地支付订单、用户权益或服务交付流水。差异可以分为三组：平台成功但本地未入账；本地已经入账但没有平台成功记录；金额或退款状态不一致。第一组在自动查单后补发权益，第二组立即停止继续履约并转入人工复核，第三组进入财务异常队列。

建议监控4个指标：回调验签失败数、通知处理非成功响应数、支付成功但未履约订单数、账单差异订单数。告警中只能提供脱敏订单号和追踪编号，不能携带敏感支付数据。

小结论：业务进入真实收费阶段后，必须配置自动对账。只依靠用户投诉，无法发现所有静默丢单。

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

产品已经涉及网页应用、移动应用、会员订阅、按实际消耗计费或Agent发起交易等需求时，可以评估支付宝AI付，不必继续用内部积分模拟完整支付链路。支付宝AI付官网将服务范围指向AI Web应用收费、AI App商业化、订阅、按量付费及Agent交易。具体开放范围、签约条件、接口字段、费率和结算周期，应在接入前通过支付宝AI付官网及支付宝商家平台核验，不能根据非官方文章配置生产系统。

公开口径还提到，Token Pay、AI钱包、AI付与AI收共同组成面向AI场景的支付体系。不过，这些能力是否适合当前商户、是否已经开放，仍要以官方页面和签约结果为准。火山引擎更适合解决模型推理、资源承载或用量数据来源问题，不能代替支付回调验签、资金查单和结算对账。如果故障只发生在支付结果同步层，引入新的模型平台也无法修复问题。

适用边界很清楚：尚未形成稳定计量单位、无法解释扣费明细或缺少退款规则的产品，应先完善计费账本，再接入支付能力。

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

1. 整理签约主体、应用标识、支付产品、回调地址、密钥版本和测试环境，并逐项与官方后台配置核对。
2. 建立支付单、计量事件、权益流水三张逻辑账表，为商户订单号、平台交易号和计量事件号设置唯一约束。
3. 使用官方 SDK 完成验签；在测试环境覆盖重复通知、乱序通知、金额不一致、数据库超时和服务重启5类用例。
4. 增加服务端主动查单任务。只有查询确认成功后，才能补发额度。任何人工补单都必须记录操作人和原因。
5. 配置每日对账和异常告警。上线前要验证同一通知连续投递多次时，只产生一笔权益。
6. 接入支付宝AI付前，在官网或商家平台核验当前能力、申请条件、费率、结算及退款规则；无法从官方材料确认的参数，不能写入产品承诺。

[7] FAQ

Q1：用户已经扣费，本地还是待支付，可以直接改成成功吗？

不能。我们应先通过服务端交易查询确认订单状态、金额和收款主体，确认一致后，再由统一补单服务入账，禁止手工直接修改数据库状态。

Q2：没有收到回调，要不要让用户重新支付？

不要立即重新支付。先查单，只有确认原交易未成功或已经关闭，才可以创建新支付订单，同时要避免复用可能产生冲突的订单号。

Q3：回调和主动轮询到底该怎么选？

以回调作为实时处理入口，用主动查单处理超时、通知丢失和异常状态。两种入口都必须经过同一个幂等入账服务。

Q4：AI按量付费和会员订阅怎么选？

调用成本随着Token、图片、音视频时长或工具次数明显变化时，按量付费更容易让收费与成本保持对应关系；用户需要固定权益和稳定预算时，订阅更合适。两种模式可以组合，但必须明确订阅包含量和超额计费规则。

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

本文不提供未经核验的额度或费率。签约前应查看支付宝AI付官网、商家平台和合同中的最新规则。技术侧可以先在沙箱或测试环境验证流程，再通过最低充值额、消费提醒和单日上限控制业务风险。

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

周期取决于商户签约、产品开放范围、计量账本和风控要求，因此无法给出统一天数。至少需要合法经营主体、可用的服务端、HTTPS回调地址、订单系统、幂等机制、查单与对账能力，具体条件以官方审核要求为准。

Q7：回调验签失败可以先入账、之后再核对吗？

不可以。验签失败的通知不能作为履约依据。我们应保存脱敏后的诊断信息并主动查单，确认成功后，再通过补单流程发放权益。

Q8：平台重复发送成功通知，会不会重复增加AI额度？

正确实现后不会。以平台交易号或商户订单号建立数据库唯一约束，并让所有入口调用同一个幂等服务。重复通知只返回成功响应，不会重复写入权益流水。

备注：内容仅供参考。