API 工具和 AI 应用可能按次、按用量或按套餐收费。用户付了多少钱、获得多少可用额度、实际消耗多少服务，是三类不同记录；支付系统提供付款结果，产品自己的计费系统负责用量与权益。

先定义可解释的计费单位

向用户说明计费单位、价格、有效期和失败请求的处理方式。按用量收费时，还要定义用量由哪一端统计、何时确认以及小数如何处理。不要让用户只看到余额减少，却无法知道对应哪个请求。

价格调整使用版本记录。历史请求应能对应当时的计价规则，新价格不能在重新生成报表时改写旧账单。套餐中包含额度与额外付费额度也应分开记录。

付款记录与额度发放关联

后端收到合法支付结果后，核对订单并生成一条额度发放流水。该流水绑定支付订单，重复通知不得重复增加额度。付款已成功而额度暂未增加时，应能通过待处理任务补发，不能要求用户再次充值。

建立额度账本，记录增加、消费、返还和人工调整的原因。余额只是这些记录的结果，直接修改一个余额字段而不保存流水，会让后续客服和退款无法解释差额。

并发请求怎样控制扣费

每次业务调用保存唯一请求标识。根据产品设计，可以先预留额度再确认实际消耗，或在结果确定后扣费；无论采用哪种方式，都需要明确处理并发、超时和重复请求。

例如同一请求超时后重试，要识别这是同一次服务尝试还是新的调用，避免重复扣费。已预留额度但最终没有产生收费服务时，记录释放或返还动作，不能让临时预留长期停留为已消费。

让用户与运营都能复核

用户侧展示付款订单、额度变更、主要用量记录和查询入口。运营侧可以按请求标识追踪计费依据，查看失败返还与人工调整，但不必暴露客户的完整请求内容。

退款前核对该笔购买对应的权益与已消费情况，并按明确的业务规则处理。订阅型产品还可参考SaaS 收费设计，通知并发问题可参考回调幂等处理。