产品授权 · 产品费率设置 · 扣费流程说明

目录

• 1. 概述：谁配什么、影响谁
• 2. 角色与配置职责
• 3. 产品授权
• 4. 产品费率设置
• 5. 变更冷却期
• 6. 扣费逻辑：取价四步
• 7. 费项目录与叠加互斥规则
• 8. 扣费时机与扣费科目
• 9. 金额计算模型
• 10. 错误码速查
• 11. 排错速查
• 12. 变更记录

1. 概述：谁配什么、影响谁

平台上存在两条互相独立的费率链，它们不是同一个东西，配置入口、冷却规则、错误码都不同。初次接触最容易踩的坑就是把两者混为一谈。

本文档主线是实扣链：产品授权 → 产品费率设置（费项） → 扣费。价差链只在下层不得低于上层（§4.3）与冷却时长对照处提及。

一句话概括各层职责：

运营平台   产品目录 + 平台费项（成本侧/售价侧）   ← 唯一能新建/编辑/停用费项的角色
   ↓ 产品授权（授权哪些产品给哪个商户 + 开卡配额 + 交易限额）
商户       覆盖费项售价侧 + 给持卡人配实付费率    ← 不能新增/删除费项
   ↓ 商户覆盖（写即生效，无独立审批）
持卡人     不可自助改费率，只能看到自己账户上的实际发生额

2. 角色与配置职责

注意

说明：运营平台页面文件名为「商户产品费率配置」，但它是平台管理员在配置某个商户的授权与费率，不是商户自助页面。商户自助页面是只读 + 覆盖两类动作。

3. 产品授权

3.1 业务含义

产品授权回答的是：「这个商户能不能卖这个卡产品、能开多少张卡、单笔/单日/单月能刷多少」。它不涉及价格，只涉及「能不能做」和「做多少」。

授权是商户可售产品列表的唯一真源。商户在后台看到的可售产品 = 授权表中启用状态的记录 ∩ 平台产品目录中已上架且资料齐备的产品。商户端只读，不能自己维护这张表。

3.2 配置方式

请求体每项字段：

3.3 生效与状态

授权状态只有两态：1 启用 / 0 停用。授权变更没有审批流，运营平台提交即生效，并写入只读审计（记录动作、操作人、变更前后值）。

生效期字段在授权记录中存在，但当前平台接口不接受运营填写，一律按无界处理（启用即长期有效，停用即失效）。若业务上需要「某段时间内有效」，目前需要在产品目录侧用上下架来近似控制。

3.4 配额与限额的执行口径

• 交易限额三字段是真生效的：交易发起时校验单笔/单日/单月上限，超限直接拒绝该笔交易并返回参数校验类错误。

警告

警告：开卡配额不是硬性名额控制。 目前系统不按开卡张数拦截开卡动作，配额超限不会阻止开卡。请不要把「设置了开卡配额」当作硬性名额控制，需要硬控时应使用交易限额或产品目录侧的上下架。

4. 产品费率设置

4.1 两条链的分工

本节重点是实扣链（费项），层级约束部分会引用价差链。

4.2 费项字段字典

一个费项 = 「某个产品 + 某个收费项目 + 某个币种」下的一个定价版本。

警告

警告：区间与清单留空的口径是「全命中」，不是「不生效」。 这是运营最容易配错的一条：FEE_SPECIAL_REGION（特殊地区商户手续费）如果地区清单留空且处于启用状态，会对所有地区的每笔交易命中计费。上线前务必填入目标地区清单，或先保持停用。

4.3 层级约束：下层不得低于上层

实扣链与价差链共同遵守一条原则：任何一层对外收取的价格，都不得低于它上游给这一层的成本。

平台授权价  ≤  商户费率（价差链）
平台费项售价  ≤  商户覆盖后的售价（实扣链）
商户费率  ≤  持卡人实付费率（价差链）

• 商户把费率或覆盖价配得比上游成本低，会被服务端直接拒绝，错误码 3101 RATE_BELOW_FLOOR。
• 商户把费率配得高于平台上限，会被拒绝，错误码 3102 RATE_ABOVE_CEILING。平台上限目前是系统内置约束，不是可配置项。
• 覆盖成本侧的防倒挂校验已按 2026-09-20 的需求调整放开，商户可自定义售价，实扣时不再因倒挂被拒。因此定价合理性由商户自行负责，平台只保留下限与上限两道硬闸。
• 倒挂在费率中心「试算」页以数据形式呈现：每条命中的费项并排给出实扣售价与成本价，并标出该费项是否被商户覆盖，运营一眼可辨。试算不会为实扣链的倒挂单独弹告警——页面上唯一叫「费率倒挂」的告警属于价差链（商户费率费用低于授权成本费用），与本条不是一回事。实扣链倒挂只落服务端 WARN 日志，不阻断交易。

4.4 商户覆盖规则

商户对平台费项只能做「售价侧覆盖」，且必须满足：

平台对商户的覆盖关系有约束：同一费项存在有效覆盖时，平台侧不允许停用该费项，会返回 4003 FEE_ITEM_IN_USE，防止平台操作直接打断商户已生效的定价。

5. 变更冷却期

5.1 为什么有冷却期

费项配错价是直接的资损：改错一个售价或误停用一个费项，影响会在下一笔交易立刻显现，且往往已经无法挽回。变更冷却期给运营留出一个「发现误操作、来不及扩散」的拦截窗口。

此前只有价差链有冷却，实扣链完全没有，认知上不一致。2026-09-30 起，实扣链补齐同构语义。

5.2 规则

冷却期间再次提交同类写操作，服务端返回 FEE_423，并在提示中带上冷却截止时刻，前端据此展示剩余时间。

5.3 紧急变更（绕过冷却）

平台保留了绕过开关，用于确有紧急理由的场景（例如上游突发故障必须立刻停用一个费项）。

使用绕过开关必须同时满足：

1. 请求显式声明「紧急变更」；
2. 强制填写变更原因（缺失或只填空格一律拒绝，服务端校验，不依赖前端提示）；
3. 经过 2FA 动态验证码；
4. 绕过标记与变更原因写入只读审计，事后不可修改、不可清除。

变更原因是三类写操作（新建 / 编辑 / 停用）共用的审计字段：

• 勾选了绕过时必填，留空直接被服务端拒绝；
• 没勾选时选填，留空不会报错，系统会按动作落一条兜底文案（「管理后台新建费项 / 管理后台费项编辑 / 管理后台停用费项」）；
• 落库到费项版本链的 change_reason 列，与描述字段是两回事——描述是给人看的业务备注，变更原因是审计口径，一经写入不可修改。

2026-09-30 修正：此前管理后台根本没把变更原因传给服务端，落库的一直是硬编码文案，所有变更（含全部紧急绕过）在审计里长得一模一样，停用记录看上去还像是「新建」。现已打通新建 / 编辑 / 停用三条写路径，停用弹窗也补上了原因输入框。

绕过不是常规操作。每次绕过都会在审计留痕，请把它当成需要事后复盘的例外，而不是「嫌麻烦就勾一下」的开关。

5.4 误操作的止损顺序

警告

警告：止损动作本身也要冷静确认。停用一个「本来就没人用」的费项不会造成损失，但停用一个正在被大量交易命中的费项会立刻引发大面积异常。 停用前先看该费项近期的实际扣费笔数，确认影响面之后再动手。

发现配错了，按这个顺序处理：

1. 先停用有问题的费项（紧急绕过），让错误定价立即退出取价；
2. 核对是否有 legacy 全局费项会接管扣费（见 §11.1，停用不等于停止收费）；
3. 再用正确值重新配置（新费项或新版本行）；
4. 核对商户覆盖是否也需要同步调整——商户覆盖优先级高于平台费项；
5. 复盘这次绕过的原因，补齐配置规范。

6. 扣费逻辑：取价四步

一笔交易真正产生扣费时，系统按固定四步选出最终生效的费项版本。四步是顺序依赖的，任一步不命中就顺延到下一步。

① 由卡反查产品        卡 → 卡所属产品（拿不到产品 = 无产品上下文）
        ↓
② 取产品费项          产品 + 费项码 + 币种 + 交易时刻，命中该产品下的当前生效版本
        ↓ 未命中
③ 回退全局费项        未挂产品的全局费项（来源标记 LEGACY）
        ↓ 未命中
④ 套商户覆盖          在②③命中的基础上，套该商户的售价侧覆盖（来源标记 OVERRIDE）

6.1 四步详解

第 ① 步：由卡反查产品。 扣费以卡为入口，先由卡找到它所属的产品。卡上没有产品上下文时，后续的产品费项查询无法进行。

第 ② 步：取产品费项。 按「产品 + 费项码 + 币种 + 交易发生时刻」查该产品下的费项，并且必须处于生效状态：启用中，且交易时刻落在生效窗口内（生效窗口左闭右开）。同一链有多个版本行时，取生效时刻最晚的那一版。

第 ③ 步：回退全局费项。 第 ② 步没命中（例如该产品下这个收费项目压根没配），系统会去查未挂产品的全局费项。命中则使用，并在扣费流水上把取价来源标记为 LEGACY。

这一步是「停用 ≠ 停止收费」的根源。 停用一个产品费项，只是让第 ② 步不命中，第 ③ 步会立刻顶上，只要全局费项还在启用，交易照样扣费，而且扣的还是全局那一档价格。要真正停止某项收费，必须确认第 ③ 步也不命中。

第 ④ 步：套商户覆盖。 前两步命中任意一个之后，才查这个商户对该费项的售价侧覆盖。覆盖必须同时满足「已生效」与「在生效区间内」才会套用。套用后取价来源标记为 OVERRIDE，只改售价侧，成本侧、适用区间、扣费科目仍取平台费项。

6.2 三种取价来源

排错时先看扣费流水上的取价来源，就知道钱是被哪一档价格扣走的。

6.3 找不到可用费项时

系统存在两条扣费入口，行为不同：

• 主扣费入口：找不到可用费项时拒绝并报错（FEE_404），不会静默放过；
• 可选扣费入口（开卡费、月管理费等）：找不到可用费项时跳过不扣。

也就是说，「费项没配」在不同场景下的结果不同。周期类与账户类费项属于后者，未配置就是不扣，不会阻断业务。

6.4 币种红线

取价币种恒等于卡余额币种，系统不做任何币种折算，也不会回退到其他币种的费项。为某币种配费项时，必须用该币种建行；只配了美元而卡片余额是欧元，该笔交易取不到美元费项，也不会自动去取美元价格。

7. 费项目录与叠加互斥规则

7.1 官方目录

以下为可配置的收费项目。实际启用哪些、按什么模式、适用区间是什么，全部由运营平台按产品与币种逐条配置，本表只说明每个项目「什么时候会被触发」。

7.2 「配置了但不扣费」的费项码

以下费项码在目录中保留展示名，但扣费引擎未实现：配上去不会产生任何实际扣费。运营平台的新建下拉中已剔除，后端写入口也会直接拒绝，历史存量数据保留仅供查看。

警告

警告：给上表中的费项码配了价，系统不会报错，但也不会产生任何实际扣费——钱不会被扣，但业务上以为扣了。 FEE_INACTIVE（休眠卡费）特别说明：它此前一直混在上节的可配目录里，是本名单中唯一一个「需求文档明确写着商户可开启、默认关闭只差运营点一下」的码——运营会把它当正常业务项配上去，配完不扣费即静默少收。2026-09-30 起已并入本名单，新建下拉与后端写入口一并拒绝。 另有历史兼容码 FEE_SIGN（开卡费旧名），同样不参与扣费，新配置统一使用 FEE_OPEN_CARD。

7.3 叠加与互斥

多费项命中时的规则：

警告

警告：小额手续费不设区间 = 消费笔费被全线取代。 小额区间的判定是左闭右开：min ≤ 交易额 < max。上下限都留空表示任意金额都命中，会变成「所有交易都取代消费笔费」——这是一个高危配置，务必显式设置上下限。

系统不会在配置期拒绝「同时配了小额和消费笔费」，因为这本身是合法配置（区间不重叠时各按各的）。真正的互斥是在取价时按金额区间动态判定的。

8. 扣费时机与扣费科目

8.1 扣费时机

关于月管理费批处理的三点说明：

• 批处理有总开关，开关缺失时按关闭处理（fail-close），不会在无人确认的情况下自动扣钱；
• 批处理带分布式锁，多实例部署不会重复执行；
• 逐卡独立事务，单卡失败只影响该卡，不会中断整批。

8.2 扣费科目

开卡费的扣费科目按提交方路由：由商户后台提交的开卡，从商户通道头寸扣；由平台侧发起的开卡，从卡余额/账户可用扣。配置开卡费前请确认走的是哪条路径。

8.3 幂等与回滚

• 所有扣费都有幂等键，同一笔业务的重放不会重复扣费，只会返回既有流水；
• 同一笔交易内的多项扣费在同一个事务内执行，任一项失败则整体回滚（该笔授权相应转为拒绝）；
• 已产生的扣费流水不受后续费率变更影响。改费率只改未来，不改历史——这是账务可追溯的基本要求。

9. 金额计算模型

9.1 计费模式三态

费率的单位是万分比，不是百分比。 "250" 表示 2.5%，不是 250%，也不是 2.5。这是配置时最高频的错误来源。

9.2 精度与舍入

• 所有金额与费率的运算使用高精度十进制，中间过程不做截断；
• 最终结果保留 8 位小数，四舍五入；
• 金额一律以字符串在接口之间传输（"2.50"），禁止使用数字类型，避免浮点误差在链路上被放大。

9.3 示意算例

以下数字仅为计算过程示意，不代表任何真实费率配置。

设某笔交易额为 "100.00"，某产品费项为「固定额 + 费率」模式，固定额配 "1.00"、费率配 "250"（万分比，即 2.5%）：

费率部分 = 100.00 × 250 ÷ 10000 = 2.50000000
固定部分 = 1.00
本项扣费 = 1.00 + 2.50 = 3.50

若同一笔交易还命中了授权手续费（纯费率模式，费率配 "50"，即 0.5%）：

授权手续费 = 100.00 × 50 ÷ 10000 = 0.50000000
两项叠加，本笔合计 = 3.50 + 0.50 = 4.00

如果商户对授权手续费做了售价侧覆盖，则用覆盖后的费率代入同一公式，其余（固定额、科目、适用区间）仍取平台配置。

9.4 适用区间的判定

区间判定发生在取价阶段，用于决定某个费项本次是否命中：

命中条件：minAmount ≤ 交易额 < maxAmount
其中 minAmount 留空视为不设下限，maxAmount 留空视为不设上限

10. 错误码速查

10.1 费率链（价差链）

10.2 费项链（实扣链）

10.3 敏感写通用

11. 排错速查

11.1 停用产品费项 ≠ 停止收费（资损警示）

这是本系统最容易造成资损的一个认知误区。

警告

危险：这是本系统最容易造成资损的认知误区。 停用一个产品费项，只是让取价第 ② 步不命中；取价第 ③ 步会立刻回退到未挂产品的全局费项继续扣费，扣费流水上的取价来源会显示为 LEGACY。

要真正停止某项收费，必须做到：

1. 停用该产品下的费项；
2. 确认同名费项的全局版本也已停用（否则会继续按全局那一档扣）；
3. 核对商户是否已有覆盖（覆盖优先级最高，需商户侧撤销）；
4. 用一笔小额真实交易验证扣费流水上不再出现该项。

11.2 商户改了费率，平台侧看不到变化

商户覆盖的优先级高于平台费项。平台看到的仍是平台自己配的价，实际扣的是商户覆盖价。核对商户后台的覆盖记录与生效区间。

11.3 商户配的费率被拒

按错误码定位：3101 是配低了（低于上游成本），3102 是配高了（超过平台上限），3105 是这个产品还没做授权，先做授权。

11.4 某笔交易没有扣某项费

按这个顺序查：

1. 该笔交易的金额是否落在费项的适用区间（小额手续费这类尤其容易漏）；
2. 费项的地区清单 / 商户类别清单是否为空——为空是「全命中」而非「不生效」，这一条如果为空反而会全量命中；
3. 费项是否处于生效窗口内（版本链有生效起止），或已被停用；
4. 币种是否与卡余额币种一致（不做折算，见 §6.4）；
5. 该收费项目是否本就在「引擎未实现」清单里（§7.2），配了也不扣；
6. 商户是否已经撤销了覆盖。

11.5 扣费金额算出来不对

多半是费率单位搞错。费率是万分比："250" = 2.5%，不是 250%，也不是 2.5。另一个常见原因是把 RATE 模式配成了固定额语义，或反过来。

11.6 提交变更被拒，提示冷却中

等冷却结束，或在确有紧急理由时使用紧急变更（绕过冷却）——必须填变更原因，经 2FA 验证，绕过标记落只读审计。详见 §5.3。

提示文案形如：

费项链 [30/FEE_TX_FLAT/EUR] 编辑冷却中，剩余 6 小时 12 分钟，冷却时长 24 小时

方括号里是费项链标识 [产品ID/费项码/币种]，冷却挂在链上、链与链互不影响——同一个费项码在不同产品或不同币种下是彼此独立的多条链，只看费项码会误判成「整条目录都在冷却」。请按括号里的产品与币种确认你等的确实是自己刚才改的那一条。

11.7 提示版本已变化

有其他人（或另一个会话）先改过这条配置。刷新页面拿到最新版本号再提交，不要盲目重试覆盖。

12. 变更记录

文档定位：本文是规则说明，不替代接口契约文档。字段级契约以接口文档与数据库 schema 为准；如出现冲突，以 docs/DOC-SSOT.md 的裁决为准。