XD-OP-07 · DOC
费率与限额
费率与限额不写死在文档里：每一单响应里的 `feeProjection`（带 `ruleVersion`）才是那一单的准确口径；限额按本单实际到账账号的主体类型判定。
小豆支付开放平台是面向已有自有系统的商家的支付接入服务：通过服务器对服务器的接口，把支付宝与微信收款接进商家自己的系统，并以签名事件通知回传支付状态；资金由持牌支付公司收付结算。个人也能申请：主体类型选「个人」，身份证 + 本人银行卡即可完成商户进件。央行持牌机构清算，安全可靠的个人和企业支付接口。
1. 三个口径，只认两个
| 口径 | 从哪来 | 用途 |
|---|---|---|
| 生效配置 | 门户「费率说明」页展示的全局公开档位（带版本标识） | 了解平台公开口径；不含平台为你单独调过的档位（单商家调整不进该投影） |
每单投影（feeProjection） | 每一笔订单响应里返回 | 入账与对账的唯一依据 |
| ~~从文档抄数字~~ | —— | ❌ 本资料正文不列数字：对外统一费率见 README.md 公开档；限额与时效不写死 |
入账必须用 feeProjection：同一笔订单在创建时冻结口径，后续平台配置变更不会改变已创建订单的费率——所以历史订单永远能对得上。
2. feeProjection 字段
| 字段 | 说明 |
|---|---|
ruleVersion | 该笔适用的配置版本标识（对账时用它比对）。注意它是全局配置版本：平台对单个商家调价不会改变它，逐笔核对请以 merchantRateBps 为准 |
thresholdFen | 配置中的中性分档字段（可能不适用于你的档位；不要用它自己算费率） |
tier | 该笔命中的档位标识。当前平台为统一费率，取值恒为 STANDARD——它不参与金额计算，别用它做分支判费率 |
merchantRateBps | 你的结算比例（万分比） |
companyServiceFeeRateBps | 公司服务费比例（万分比） |
merchantSettlementFen | 该笔结算金额（整数分） |
companyServiceFeeFen | 该笔公司服务费（整数分） |
约定：
- 对外只出「你的结算比例 + 公司服务费」这两个口径。服务费内部如何分配是平台内部事项，不对商家展示、也不影响你的入账金额。
merchantSettlementFen + companyServiceFeeFen与实付金额闭环（差额分配规则由服务端处理，商家不需要自己算）。- 不要在代码里维护一份「费率表」并对账，那一定会在某次配置变更后错账。
3. 限额
限额有两个实际生效的层级，越靠前的越优先：
- 单商家调整（平台为你单独设置过、且仍在生效窗内）；
- 平台默认档（平台全局口径）。
结构上还存在第三层「应用档位」，但它当前没有任何写入面（平台不为单个应用调档），因此不必为它设计分支。
平台默认档按主体类型分档（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 的只读接口，设置与逐笔结算在门户——详见到账账号与收款分配。 - 自动结算周期、到账时间、是否支持手动提现都属于会变更的口径：以门户「资金 / 结算」页展示的生效配置为准，不要写进你的对外文案里。
- 你可以在门户「资金 / 结算」页看到按渠道的结算状态与逐笔订单的结算情况（逐笔清单支持翻页，页面底部「加载更多」按时间倒序继续取；更早的订单也可以直接用你自己库里的记录 +
feeProjection对账）；订单维度看feeProjection。
5. 常见误区
- 把文档/门户截图里的数字写进代码 → 配置变更后错账。
- 用
thresholdFen自己推算费率 → 该字段是中性字段，不代表你的实际档位。 - 按「本金 × 比例」自己算服务费 → 分配与取整由服务端计算，自己算会差分。
- 在对外文案承诺具体到账时效 → 到账周期会随渠道与结算规则变化。
open-platform/docs/07-fees-and-limits.md · 最后更新 2026-10-17
下载本文 .md
在 GitHub 查看