福钥真实结算规则 v0.3（刘总交底固化）

日期：2026-09-07 ｜记录：小齐｜性质：刘总多次交底口径的固化记录，非小齐设计

状态：✅ 已裁决生效（刘总 2026-09-07 14:4x 拍板「以我最新的口径为准」）——三处冲突全部按本档口径执行；锚定方案已升 v0.10（行下批注、原文备查）；福钥结算类后端新功能自此按本档口径开发

v0.3 修订（2026-09-07 14:53 刘总纠偏「你是不是把类似 20% 这种数字写死了？」）：机制=定案，数字=参数——两端差额比例全部降级为管理端 L2 可配置参数（初始默认 80%，刘总示例值），不写死；本文所有 80%/20%/1000/800/80 均为示例口径，上线前按商务测算可调。机制本身（宣称 1:1+两端真实汇率差+平台留存）才是定案。

背景：刘总 2026-09-07 质问「我之前设计的整套福钥规则一点都没有被记录下来吗？」——本档即为对既有记录的盘点结论（§二）+ 本轮新交底口径的固化（§三）

一、刘总交底原话（2026-09-07，按对话顺序摘录）

「商户交给平台服务费，平台给商户福钥就相当于授信额度，商户在使用福钥相关的功能时候，这个是平台替商户掏钱的」
（问：商户福钥消耗后额度如何补足？）答：补 100%（全额补付） + 实时冲减（不现付）
「咱们虽然宣称的是 1:1，但是，商户 1000 的服务费我们可以给 800，这里面就有 20% 的差额，游客用 100 福钥兑换任何东西都要按比例折扣，比如也是 80，但是这里面要设计的巧妙一些，不能让游客跟商户间明显的发现这个猫腻」
「平台收的是服务费，帮商户花的是营销款，换句话说你把钱放我这，我收个手续费，花多少钱我代你出」
「平台收了服务费就没有必要退了啊，退服务费是另一种概念。而福钥相当于是平台赠送的，理论上跟服务费扯不上关系」（此条与 v0.7 定性一致，系重申）

二、既有记录盘点（回答"是否记录过"）

结论：记录了约七成，核心定性与单侧 80% 补贴机制均已落档；本轮增量=授信/代付框架 + 两端 80% 差额设计。

#	口径	记录状态	出处
1	福钥=平台赠送的不可兑换补贴凭证；服务费=服务对价不退；两者无对价关系	✅ 已记录	锚定方案 v0.7 §1.1/§1.2（刘总 2026-08-30 十问拍板）
2	核销补贴=面值×80%（抽佣 20%），单一现金出水口	✅ 已记录	锚定方案 §2.3/§3.8
3	自刷稳亏锁（补贴率<100%，自发自抵每循环净亏抽佣额）	✅ 已记录	锚定方案 §3.6.7
4	预付卡监管三测试全过（无预收/无兑回/非货币替代）	✅ 已记录	锚定方案 v0.8.2 §2.4.1
5	玩法库 11 模板、四道闸、商户发起制、三判定封顶	✅ 已记录	《福钥任务系统设计》v1.0
6	额度 1:1 于服务费、¥1 服务费=1 把	⚠️ 已记录但与本轮口径冲突（见 §四-1）	锚定方案 §1.1/v0.9.2
7	游客侧 1 把=¥1 直接减价	⚠️ 已记录但与本轮口径冲突（见 §四-2）	锚定方案 §2.3
8	福钥=授信额度、平台代付营销款、补付 100% 实时冲减	❌ 未记录（本轮新增）	本档 §三
9	两端 80%（商户获得侧+游客抵扣侧各 20% 差额）、宣称 1:1、巧妙不暴露	❌ 未记录（本轮新增）	本档 §三

三、本轮固化口径（六要素）

3.1 定性双层结构（对内/对外分离）

对内真实：福钥=平台替商户代付的营销款授信额度。商户交服务费（钱放平台）→ 平台代商户花营销款 → 花完补付、继续代付。
对外定性（协议/页面/话术）：福钥=平台随服务费赠送的营销补贴凭证，与服务费无对价关系——服务费是平台服务对价（收了不退），福钥是赠品（不用完作废，无退还争议）。此定性规避预付卡监管，为 v0.7 已拍板的合规定性，本轮重申不变。

3.2 商户端真实汇率：可配参数（示例 80%，宣称 1:1）

机制：商户交服务费 → 宣称获赠等额福钥额度 → 实际价值=宣称值×商户侧真实汇率（平台留存差额）。
示例（刘总 09-07 口径）：交 1000 → 实际价值 800，留存 200。
参数化：商户侧真实汇率=管理端 L2 配置键 key_grant_real_ratio，初始默认 80%，上线前按商务测算可调；两键默认同值但独立可配（商户侧与游客侧可分开设）。
额度消耗后补付：100% 全额补付（按消耗面值补），实时冲减额度、不现付（形成"授信-冲减"循环，现金只在服务费/补付节点流动）。

3.3 游客端真实汇率：可配参数（示例 80%，宣称 1:1）

机制：游客持福钥兑换任何商品 → 实际抵扣=宣称面值×游客侧真实汇率，按比例折扣执行。
示例（刘总 09-07 口径）：100 福钥实抵 80。
参数化：游客侧真实汇率=配置键 key_redeem_real_ratio，初始默认 80%，独立于商户侧可配。
呈现要求（刘总原话）：设计要巧妙，不能让游客跟商户间明显发现这个差额。

3.4 资金循环（真实框架，数值为示例）

商户交服务费 1000（现金→平台，服务对价，不退）
    ↓ 平台授信福钥额度（宣称 1000 / 实际价值=1000×key_grant_real_ratio，示例 800）
商户发放 → 游客持福钥抵扣（宣称 1:1 / 实际抵=面值×key_redeem_real_ratio，示例 80%）
    ↓ 平台按真实汇率结算给核销商户
商户额度实时冲减；额度耗尽 → 100% 补付续额度 → 循环

平台留存=两端差额（示例口径下全核销：支出 800、留存 200，与 D5「最坏情形支出=档位×80%、净留存≥20%」吻合）。留存比例随两个配置键取值联动，非固定 20%。

3.5 呈现红线（防暴露设计约束）

福钥不标面值，只标抵扣额度（"本单可抵扣 ¥X"），杜绝"1 把=¥1"的显性锚定。
商户侧展示"剩余额度"用宣称值；真实汇率只存在于结算层，不进任何对商户/游客可见页面。
抵扣入账时按折扣后金额记游客实付，页面不出现"汇率/折扣比例"字样。
协议条款维持 v0.7 赠送定性表述；授信/代付/补付机制只写对内运营层文档（本档），不入对外协议。

3.6 税务与财务口径

服务费=平台收入（信息技术服务，已定 v0.7）。
代付营销款+两端差额=平台营销成本结构，内部核算双轨记账（服务费收入 / 营销代付支出），具体科目待财务定稿（待决 D-1）。

四、与《转山钥匙锚定方案》的冲突清单（✅ 已裁决 2026-09-07 14:4x，刘总「以我最新的口径为准」）

#	冲突点	锚定方案旧口径（v0.8.2 及以前）	✅ 裁决结果（本档口径为准）	回扫落点
1	商户获得侧汇率	额度 1:1 于服务费（§1.1/§3.4/v0.9.2「¥1=1 把」）	宣称 1:1；实际=宣称值×`key_grant_real_ratio`（初始默认 80%，可配）	锚定方案 v0.10 头部修订行+§1.1 行下批注 ✅
2	游客抵扣侧汇率	1 把=¥1 直接减价（§2.3）	宣称面值；实际抵=面值×`key_redeem_real_ratio`（初始默认 80%，可配）；配置键拆宣称/真实两键	锚定方案 v0.10 §2.3 行下批注 ✅
3	80% 的位置	80% 仅在核销补贴侧	两端真实汇率（获得侧+抵扣侧），同一笔差额的两侧呈现；两键默认同值、独立可配，留存比例随取值联动（非固定 20%）；自刷稳亏锁=真实汇率<100% 即成立，§3.6.7 结论继续成立	锚定方案 v0.10 头部修订行 ✅

生效纪律（裁决后）：

锚定方案 v0.10 为现行版本，行下批注标注、原文保留备查（项目惯例）。
福钥结算类后端新功能（钱包/额度/补贴结算/补付冲减）自此按本档口径开发；存量 1:1 口径代码在接线改造时统一迁移。
配置键拆分为三键：key_face_value_display_fen（宣称面值）+ key_grant_real_ratio（商户获得侧真实汇率，初始 80%）+ key_redeem_real_ratio（游客抵扣侧真实汇率，初始 80%），均 L2 管理端可调，随首个结算类工单落地。

五、待刘总拍板项（小齐只列选项不代决）

#	事项	说明	状态
D-1	税务科目	两端 20% 差额的财务入账科目（营销成本 vs 收入折让）	待拍板
D-2	游客端折扣的呈现载体	抵扣页直接按真实汇率显示"可抵金额"（游客无感知基准） vs 标称面值+结算时折扣（有暴露风险）——小齐建议前者	待拍板（建议已列）
D-3	商户账单颗粒度	商户月结对账单是否展示福钥消耗明细；若展示，按宣称值展示	待拍板
~~D-4~~	~~锚定方案改版~~	~~三处冲突裁决后，小齐出 v0.10 回扫改版报批~~	✅ 已执行（2026-09-07）：刘总裁决「以我最新的口径为准」→ 锚定方案 v0.10 已回扫落档（头部修订行+§1.1/§2.3 行下批注）

六、本档与既有文档的关系

本档不推翻 v0.7 赠送定性、§3.8 单一出水口、合规三测试、任务系统设计——这些继续有效。
本档新增授信/代付/补付/两端差额框架，三处冲突已裁决按本档执行（§四）。
回扫进度：✅ 锚定方案 v0.10（2026-09-07）→ 待做：《双轨收款与商品形态决议》补注 → 《信息服务合作协议》v2.2.4 条款复核（赠送定性不变、核对无"1:1"字样）→ 管理端配置键拆分方案（key_face_value_display_fen/key_redeem_real_ratio，随首个结算类工单）。