# 积分、账本、支付与对账

## 1. 商业规则基线

用户购买积分后，按明确批准的操作或批次消耗。**积分与法币分开，供应商成本与用户售价分开**。本版不引入订阅池、过期赠送池和复杂优惠叠加，以免首版账务失控；以后需要时以独立资金来源扩展。

正式充值币种、支付商、套餐、积分兑换比与税务政策尚未确定。下文金额仅演示计算和不变量，不是定价建议或盈利承诺。

## 2. 精度与统一计价

- 1 积分 = 1,000,000 microcredits，数据库使用 BigInt，外部 JSON 使用字符串。
- 法币保存 `amountMinor + currency`，例如最小货币单位；不能假设所有货币都是两位小数。
- 上游成本使用 Decimal 和原始币种；汇率、更新时间与换算来源另存快照。
- 价格规则明确单位：每次、每张、每秒、每字符、每百万输入／输出 token、每渲染分钟等，不能将“每百万 token 价格”当成整次价格。
- 规范化参数、数量和已冻结资源决定档位；不能从浏览器给出的“5 秒”直接收钱而不验证实际计价规则。
- 精确十进制计算后仅在规定的业务结算边界量化到 microcredit。展示可四舍五入，但显示位数不能改变实际账本。

## 3. 零售规则与成本规则

| 数据 | 用途 | 谁能看到 |
| --- | --- | --- |
| 供应商用量 | 证明实际消耗，核对供应商账单 | 受限后台 |
| 上游成本价 | 毛利、调度和风控 | 财务／渠道权限 |
| 零售价版本 | 决定对用户的报价与结算 | 用户看见对应零售价 |
| 计划上限 | 用户批准的最大积分风险 | 用户与后台 |
| 真实结算 | 用户最终消费与释放 | 用户与后台 |

禁止用上游返回“cost”不经平台零售政策直接扣用户。不同渠道提供同一个产品模型时，默认保持相同用户价格，渠道成本差额是平台经营问题；不同服务质量应作为不同产品档位明确售卖。

未定价、单位不明、无法给出可执行上限的能力不能上架。新价格只影响新报价，已有报价与执行绑定旧版本。

## 4. 报价与预留

### 固定价媒体

图片按明确数量、档位；视频按协议规定的时长／输出单位；TTS 按确定文本与规则；渲染按经探测的范围或固定档位。先计算上限，用户确认，再冻结。

### 用量型文本／媒体

P0 优先提供可计算保守上界的能力：冻结输入版本，设置输出 token／时长／数量上限，用经过验证的 tokenizer 或保守估算规则给出预留上限。无法证明上界、网关不遵守限制或用量不可解释时，先不上架，不能无上限后扣。

LLM 流式中断也可能已经消耗 token。能持久化交付的部分结果、实际 usage 与合同需分别记录；没有最终 usage 时进入核对，不能凭前端显示字符数猜精确费用，不能自动把所有费用退掉再悄悄二次调用。

### 报价有效性

报价有有效期与输入 hash；用户批准确切 Quote。确认时余额不足、输入改变、模型能力改变或价格快照无效都必须拒绝并重新确认。预留上限不是“估计可能花这些但以后随意加价”。实际应收超出上限时暂停后续付费步骤；已发生的异常上游超支由平台处理，不越权扣用户。

## 5. 账本模型：可用与冻结是不同账户

使用双分录逻辑，每一笔积分交易的分录总和为零。平台发行与消费账户用于保持守恒，不代表法定会计账替代品。

| 动作 | 借记／减少 | 贷记／增加 | 业务含义 |
| --- | --- | --- | --- |
| 已验证充值发放 | 平台发行账户 | 用户可用账户 | 仅在支付事实确认后发放 |
| 冻结 | 用户可用 | 用户冻结 | 没有实际消费，只锁定额度 |
| 结算 | 用户冻结 | 平台已消费 | 成功交付或合同约定的实际消费 |
| 释放差额 | 用户冻结 | 用户可用 | 未消费部分归还 |
| 消费补偿 | 平台已消费／补偿账户 | 用户可用 | 新反向交易，不删除原消费 |
| 撤回未消费充值 | 用户可用 | 平台发行／退款清算 | 与现金退款流程协调 |

Wallet 的显示余额是账本账户余额的事务性投影。禁止 Redis 单独减余额，禁止管理员 SQL 改用户余额，禁止每个 Task handler 各自实现扣费。

### 示例：120 积分预留，实际 108 积分

初始可用 1,000、冻结 0；批准后可用 880、冻结 120；结算后冻结减少 108，消费增加 108；释放剩余 12 后可用 892、冻结 0。用户只消费了 108，不是先扣 120 再另收 108。

若重复完成通知，业务唯一 key 命中同一 Settlement，所有账户不再变化。历史账单保留预留、结算和释放三条事实，并能折叠为一项操作明细。

## 6. 原子性、幂等与并发

- 创建执行时，Quote 验证、资金锁、Reservation、Task 与 Outbox 同事务。
- LedgerTransaction 的 businessKey 唯一，必须校验相同 key 的业务 hash，不仅忽略冲突。
- 所有相关账户按稳定顺序加行锁；用户可用账户不得透支。
- 两个并发请求合计超过余额时，只能满足合法额度，不能各自读到旧余额后同时成功。
- 结算和释放可以安全重试，但每个业务效果只能发生一次。
- 账本交易只追加。纠错产生反向交易与原因、审批人，不能删旧记录。
- 财务异常不触发新的 AI 生成；资金和媒体恢复完全分开。

## 7. 不同失败的计费处理

| 情况 | 用户资金 | 平台动作 |
| --- | --- | --- |
| 本地输入／权限不通过 | 不冻结 | 修正输入 |
| 排队未开始就取消 | 释放对应预留 | 取消下游 queued 项 |
| 能证明未向上游发送 | 释放或安全保留至重新确认 | 不算生成消费 |
| 提交结果未知 | 暂保留关联预留，并明确核对期限 | 查证原身份，不自动重发 |
| 上游明确生成失败 | P0 默认不收该媒体生成费，释放预留 | 平台核对自己的上游损失；不能保证供应商也退款 |
| 内容拒绝 | 按事先公示政策；P0 媒体无交付默认不收费 | 反滥用不靠隐藏收费，违规账户可限流／封禁 |
| 上游完成但平台交付失败 | 不直接结算成功交付价 | 先只恢复交付，超过公示期限补偿／释放 |
| 结果已交付，用户审美不满意 | 依合同结算 | 重做是新报价，不自动免费无限生成 |
| 文本已交付部分且 usage 可证 | 按已公示用量政策结算，上限不变 | 保留部分内容和证据 |
| 对账／结算暂时失败 | 不重复扣、不重复生成 | settlementPending 告警与幂等补处理 |

P0 建议媒体按可交付产物计价；用量型文本按已发生且可核验的用量计价。两者差异必须在用户条款和报价卡上明确，而不是一律承诺“失败绝对不扣任何费用”。

## 8. 冻结不是可以永远占用

未开始执行的预留有排队期限，到期可在证明未跨提交边界后取消并释放。已受理／未知副作用的预留不能仅凭本地 TTL 自动释放然后继续处理收费。

需要公示核对期限与平台兜底：在证据不足且超过服务交付期限时，通过受审计决议释放／补偿；平台承担不确定上游成本。后续迟到成功不得未经新授权从用户可用余额再扣钱，处置记录必须可追踪。具体小时数需运营与供应商合同确认，不能随意硬编码进上线规则。

## 9. 充值与支付订单

1. 用户选择已发布充值产品；服务端从数据库读取法币金额、币种、积分数量与规则版本。
2. 创建唯一 merchantOrderNo，记录套餐快照，幂等调用支付商。
3. 前端跳转／二维码只是支付入口，回跳页只读订单状态。
4. 官方通知验证签名、商户／应用身份、订单、金额、币种和支付状态，必要时向官方核对。
5. 同一事务记录已验证 PaymentEvent、更新 PaymentOrder、发放积分与审计／Outbox。
6. 重复通知或主动查询不得重复发放；伪造回跳和前端“成功”字段不产生资金效果。

支付调用本身超时也有未知接受问题：用稳定商户订单查询，不重新创建新收费订单。订单过期后收到真实成功付款不能忽略，应核对后发放或正式退款，不“吃掉”用户付款。

## 10. 现金退款与拒付

积分消费退款与法币退款不是同一操作。法币退款需验证订单可退额度、未消费积分、活动预留、优惠／税费规则和支付商能力。先锁定待撤回额度，发起有幂等身份的退款，核对支付商结果，再完成积分清算；中途未知不能既释放额度又退款。

已消费额度原则上按公示政策与客服审批处理，不承诺任意兑换提现。发生拒付／欺诈时冻结新消费、记录风险与债务／损失，不能为了追回费用随意把账本改成负余额或泄露私有素材。

大额补偿、人工发放、退款建议实行双人审批；P0 若团队人数不足，也至少有二次认证、权限隔离与完整审计，不提供无理由调账入口。

## 11. 四类对账

| 对账 | 比较对象 | 发现差异后的动作 |
| --- | --- | --- |
| 账本守恒 | 交易分录和、账户余额投影 | 告警，禁止自动修改历史 |
| 执行资金 | Quote/Reservation/Settlement/Task | 补结算、补释放或人工核对 |
| 支付充值 | 支付官方成功／退款事实与本地发放 | 主动查询核实，幂等补账 |
| 上游成本 | UsageFact、远程任务与供应商账单 | 进价差异、异常收费、网关重试事故 |

日报不能掩盖实时错误；资金待结、未知受理、大量预留超期需即时告警。报表可重建，账本不可被报表程序“修正”。

## 12. 毛利与预算

以一集的镜头数、平均时长、候选数、重做率、图片和音频用量估算成本：总成本是各阶段实际调用之和，加存储、带宽、渲染、支付手续费、失败损失和客服成本。

不能用“最终成片 60 秒 × 视频秒价”估全部成本；如果生成 20 个候选但只选 12 个，另外 8 个仍有真实成本。预算卡必须展示候选数量与批次上限，用户拒绝后不发生后续调用。

技术方案不承诺固定利润率。定价发布前应做真实网关样本、不同参数档位、故障与重做率评估。运营能设置渠道日预算、单用户日风险上限和全局紧急停止新提交，不影响已有任务的合法查询／交付。

## 13. 财务验收清单

重复支付回调、并发消费、价格变更、部分成功批次、超时未知、结算服务中断、退款重放、支付超时、晚到付款、恢复备份、管理员误操作、上游 usage 缺失与超出预留。所有情形要同时验证账户守恒、用户显示、审计和外部请求次数，不能只验证某个计算函数返回预期数字。