| | |
|---|
| | | **企业与个人主体都要交**：通道在进件这一步就按 F-code 逐张核对，缺一张整笔驳回。 |
|---|
| | | 基本资料审核通过后，微信支付仍可能处于开通中或开通失败。 |
|---|
| | | |
|---|
| | | **自助进件**：商户在我们商户端自己提交上一条**商户进件**的路径。相对的是**外部进件**。 |
|---|
| | | _Avoid_: 线上进件（那是「进件场景」，与谁发起无关） |
|---|
| | | |
|---|
| | | **外部进件**：商户**已在汇付侧完成进件**，我们把它接进某个商家。两条路径收敛到同一套进件记录、 |
|---|
| | | 分阶段进度与**收款就绪**判定，只有来源不同（进件记录的 `source`：`self` 自助进件 / `managed` 纳管）。 |
|---|
| | | 接进来的动作叫**纳管**：后台选定我方商家 + 填汇付商户号与入驻申请单号，先只读核验通道，再建结算卡与 |
|---|
| | | 进件记录并跑一次进度刷新。**纳管全程只查询、不下发**——外部商户的口径已由业务要求与自助进件保持一致， |
|---|
| | | 只需核实；而补开微信、绑人才端 AppID、改支付场景、开启延迟入账都不幂等（改支付场景会重建微信子商户号）， |
|---|
| | | 连锁多店共用一个汇付商户号时各自下发还会重复下发。防绑错靠**主体名人工核对 + 显式确认 + 留痕 + 可解绑**， |
|---|
| | | 不做「名称对不对得上」的字符串判定（我们只有一个商家名，通道那边是工商全称加简称，形态不对应）。 |
|---|
| | | 一个汇付商户号可以被多个商家分别纳管（连锁各门店共用一个收款主体）。 |
|---|
| | | _Avoid_: 迁管、挂靠（会让人以为是一份收款主体 + N 个引用的模型） |
|---|
| | | |
|---|
| | | **渠道商**：汇付里位于我们平台之上、**直属**管辖我们名下商户的那一层主体。平台的每一次通道调用都以它（或它的下级身份） |
|---|
| | | 签名，因此「谁能查到哪个商户」由**签名身份本身的数据权限**决定，与商户在通道里挂在谁下面无关—— |
|---|
| | | 把商户改成挂在平台自己名下既解除不了数据权限失败，还会平白多出材料要求。 |
|---|
