# 费率与限额

> docId：`XD-OP-07` ｜ version：`1.0.0` ｜ status：`PUBLISHED`

> **对外统一费率不在这篇重复列出**（全平台统一一档，见仓库 `README.md`「资金与结算」节与商户后台「费率说明」页）；**限额与时效数字本篇不写死**。生效值随平台配置变更，取「**生效配置**」或「**每单投影**」才是正确做法；把它们抄进代码或文案是上线事故的常见起点。

## 1. 三个口径，只认两个

| 口径 | 从哪来 | 用途 |
| --- | --- | --- |
| **生效配置** | 门户「费率说明」页展示的**全局公开档位**（带版本标识） | 了解平台公开口径；**不含**平台为你单独调过的档位（单商家调整不进该投影） |
| **每单投影**（`feeProjection`） | 每一笔订单响应里返回 | **入账与对账的唯一依据** |
| ~~从文档抄数字~~ | —— | ❌ 本资料正文不列数字：对外统一费率见 `README.md` 公开档；限额与时效不写死 |

**入账必须用 `feeProjection`**：同一笔订单在创建时冻结口径，后续平台配置变更**不会**改变已创建订单的费率——所以历史订单永远能对得上。

## 2. `feeProjection` 字段

| 字段 | 说明 |
| --- | --- |
| `ruleVersion` | 该笔适用的配置版本标识（对账时用它比对）。**注意它是全局配置版本**：平台对**单个商家**调价不会改变它，逐笔核对请以 `merchantRateBps` 为准 |
| `thresholdFen` | 配置中的中性分档字段（可能不适用于你的档位；**不要**用它自己算费率） |
| `tier` | 该笔命中的档位标识。当前平台为**统一费率**，取值恒为 `STANDARD`——**它不参与金额计算**，别用它做分支判费率 |
| `merchantRateBps` | 你的**结算比例**（万分比） |
| `companyServiceFeeRateBps` | **公司服务费比例**（万分比） |
| `merchantSettlementFen` | 该笔结算金额（整数分） |
| `companyServiceFeeFen` | 该笔公司服务费（整数分） |

约定：

- **对外只出「你的结算比例 + 公司服务费」这两个口径**。服务费内部如何分配是平台内部事项，不对商家展示、也不影响你的入账金额。
- `merchantSettlementFen + companyServiceFeeFen` 与实付金额闭环（差额分配规则由服务端处理，商家不需要自己算）。
- **不要**在代码里维护一份「费率表」并对账，那一定会在某次配置变更后错账。

## 3. 限额

限额有两个**实际生效**的层级，越靠前的越优先：

1. **单商家调整**（平台为你单独设置过、且仍在生效窗内）；
2. **平台默认档**（平台全局口径）。

> 结构上还存在第三层「应用档位」，但它**当前没有任何写入面**（平台不为单个应用调档），因此不必为它设计分支。

**平台默认档按主体类型分档**（2026-10-14 起）：

| 本单实际到账账号的主体类型 | 平台默认金额限额 |
| --- | --- |
| 个人 | 平台默认档：单笔与当日累计都设上限 |
| 对公（个体工商户 / 企业） | 不设平台业务金额上限，实际以支付服务方额度为准 |

判定口径是**本单实际到账账号**的主体类型（多账号收款时逐单判定），不是「你名下有一个对公账号就全部放行」。对公主体不设平台业务金额上限，实际以支付服务方额度为准——但**这不等于没有防线**：`待支付订单数`、`未关闭支付尝试数`（只创建不支付的敞口）与主体类型无关，两档都照常生效；任何金额仍受平台的**异常值形状上界**约束（防误传超大数）。

> **限额值不在本资料、也不在门户展示**（门户只展示全局公开费率档位；单商家限额与调整申请暂无自助面）。被拒时信封会指出是**哪一类**触发面（订单/尝试腿=`details.scopes` 数组；**退款累计腿**=`details.scope` 单值 `REFUND_CUMULATIVE` + `outRefundNo`），按它自查；需要调整就通过官网反馈渠道提（附 `requestId`），以平台答复的生效值为准。**不要**用试探下单的方式去摸限额边界。

**被拒时先看 `details`**（指名触发面；为兼容老版本也可按下面的清单逐条自查）：

| 触发面（`details.scopes` 取值） | 自查动作 |
| --- | --- |
| **单笔金额**超过平台限额（`SINGLE_ORDER_MAX`） | 拆分或改用别的收款方式；平台侧调整走反馈渠道 |
| **当日累计**超过限额（`DAILY_AMOUNT`） | 日累计口径 = **当日支付成功金额之和**，**退款不释放额度**，按**北京时间自然日**重置。当天退款后再下单仍可能被拒，属正常 |
| **待支付订单数**超过上限（`PENDING_ORDER_COUNT`） | **先关掉不再支付的订单**（关单释放待支付额度），再创建新单 |
| **待支付金额**超过上限（`PENDING_AMOUNT`；「在途未支付金额」同样计入限额） | 在途未付金额占用敞口：先关掉不再支付的订单，收敛敞口后再创建新单。**本行只对个人主体生效**——对公主体不设平台金额上限，实际以支付服务方额度为准 |
| **未关闭支付尝试数**超过上限（`UNCLOSED_ATTEMPT_COUNT`） | 不要对**已终态**的旧尝试反复「重拉起」——每次重拉起都会新增一条尝试；先让在途单收敛（支付或关单） |

- **单笔金额超出你当前生效的单笔上限**（按主体类型与单独约定判定，`details.field=amountFen`）走的是**合同层校验**，返回 `400 OPEN_API_BODY_INVALID`——它与 `422` 的判定次序里，合同层在前。其余触发面（当日累计、待支付订单数/金额、未关闭尝试数）越界返回 `422 OPEN_API_LIMIT_EXCEEDED`。两者别混：`400` 是「这一笔的金额本身不合规」，`422` 是「平台业务限额/敞口触发」。
- **限额是「拒绝」不是「排队」**：被拒的订单不会稍后自动成功，请在业务侧给买家明确提示。
- **退款累计腿**（`details.scope=REFUND_CUMULATIVE`）含义：该笔退款会使**累计退款额超过实付**——按 `outRefundNo` 核对退款金额，不要换号重试。

## 4. 结算与到账

- 支付成功后资金按平台与支付机构的结算规则结算到你的结算账户。**收款先去哪、怎么分**由「收款分配」决定：你可以绑定多个到账账号，选择**单账号全额**、**按顺序轮流**或**比例分账**（2–4 个参与账号，配置面每项 `0 < shareBps < 10000`、合计 10000bps）；分配在**下单时冻结、一单一结**，退款按原订单冻结的分配快照发起回退（实际到账路径以支付服务方原交易与分账合同为准）。查当前分配用 §2.7 的只读接口，设置与逐笔结算在门户——详见[到账账号与收款分配](./14-settlement-accounts.md)。
- **自动结算周期、到账时间、是否支持手动提现**都属于会变更的口径：**以门户「资金 / 结算」页展示的生效配置为准**，不要写进你的对外文案里。
- 你可以在门户「资金 / 结算」页看到按渠道的结算状态与逐笔订单的结算情况（**逐笔清单支持翻页**，页面底部「加载更多」按时间倒序继续取；更早的订单也可以直接用你自己库里的记录 + `feeProjection` 对账）；订单维度看 `feeProjection`。

## 5. 常见误区

1. **把文档/门户截图里的数字写进代码** → 配置变更后错账。
2. **用 `thresholdFen` 自己推算费率** → 该字段是中性字段，不代表你的实际档位。
3. **按「本金 × 比例」自己算服务费** → 分配与取整由服务端计算，自己算会差分。
4. **在对外文案承诺具体到账时效** → 到账周期会随渠道与结算规则变化。