# 01 — 外部进件商户的纳管（含解绑） **What to build:** 平台运营在后台把一个**已在汇付侧完成进件**的商户接到我方某个商家上，使它能在我们商户端直接使用并收款；绑定错了能解绑重来。 后台入口：在「财务管理 → 结算记录 → 商户进件」页签的筛选栏放一个纳管按钮，点开是对话框——选我方商家 + 填入汇付商户号 + 入驻申请单号（结算卡号不用填，从通道查回来）。提交后该商家立刻出现在进件列表里，进度收敛后即可收款。 同一个汇付商户号可以被多个商家分别纳管（连锁各门店共用一个收款主体），入口只提示已绑的商家、不拦截。 解绑入口在「商户进件详情」页，与既有的刷新进度 / 重试失败步骤 / 查询通道状态 / 发起微信实名并列，作为危险操作。 **Blocked by:** None — can start immediately **Status:** ready-for-agent ## 交付内容 **纳管入口（后台）** - [ ] 「商户进件」页签出现纳管按钮，点开对话框可选我方商家、填汇付商户号与入驻申请单号；提交后列表可见该进件记录，并可直接进入详情。 - [ ] 纳管前用我们自己的签名身份只读查询一次；**查不到该商户时明确拒绝**并给出原因。 - [ ] 对话框展示通道返回的**商户注册名称**与**商户简称**（以及主体类型：企业/个人），由运营与所选商家核对并**显式勾选确认**后才能提交。 - [ ] **不用字符串比较判定名称是否「对得上」**：我们这边只有一个商家名，通道那边是工商全称加简称，形态不对应，规则化匹配必然误判——误拒会把运营卡死且无路可绕，误放等于没设防。 - [ ] 通道侧的两个名称与所选商家名**连一个字符都不重叠**时给出醒目警示，但**不硬拒**（可能是简称、别名或服务点名）。 - [ ] 把通道侧的主体名写进件记录，使进件列表能同时看到我方商家名与通道主体名，便于事后核对与追责。 - [ ] 该汇付商户号已经被其他商家绑定时**只提示不拦截**，提示里列出已绑的商家。 - [ ] 该商家/门店**已经有一条进行中或已通过的进件**时拒绝并说明（避免同一门店出现两个收款主体）。 - [ ] 重复纳管同一个商家是幂等的，不会产生第二条进件记录。 - [ ] 纳管同时为该商家建立结算卡记录；卡号与绑卡序列号从通道的商户详细信息查询取回，沿用现有的字段级加密与卡号哈希，不新造一套。 - [ ] 进件记录的非空字段（主体类型、主体名、联系人、联系电话等）由通道查询反填，拿不到的从我们的商家记录取，不留空。 - [ ] 进件记录上标明来源为「纳管」，与自助进件区分。 - [ ] 纳管**全程只查询、不下发**：不调用任何补开、绑定、改口径类的下发接口。 - [ ] 纳管入口不创建商户端登录账号；若该商家还没有登录账号或未开启商户端登录，给出提示。 **纳管之后的收敛** - [ ] 纳管触发一次进度刷新，分阶段进度与收款能力快照在**既有模型**内落库，不新造并行链路。 - [ ] 进度刷新在只有汇付侧入驻申请单号（没有我方发起的申请单号）时仍能推进，不会永远停在未确认。 - [ ] 收敛后该商家能通过下单闸门收款（与自助进件走完全相同的收款就绪口径）。 - [ ] 不新增任何进件定时任务或页面自动轮询。 - [ ] 商户端登录后能看到与下单闸门一致的「能否收款 + 原因 + 最近核实时间」，以及待办理项（含实名二维码）。 - [ ] 通道查询失败时保留上一次的进度，不显示为失败。 **解绑** - [ ] 进件详情页出现解绑（危险操作，二次确认）。 - [ ] 该商户号上还有在途订单或待结算资金时拒绝解绑并说明原因。 - [ ] 解绑清理进件记录与结算卡记录，结算卡同时从「银行卡申请」页签消失；解绑后页面回到列表。 - [ ] 解绑只解除我方绑定，界面明确说明通道侧的改动不会被回退。 - [ ] 解绑不动商户端登录账号；解绑后可以重新纳管。 **边界与兼容** - [ ] 迁移只新增一列（来源标记），编号取 `V157`，可重复执行。（落地时与远端撞号，已让号改为 `V158`） - [ ] 纳管与解绑的接口放在既有的进件查改前缀之下，沿用现有的商户结算权限码，不新增权限码、不改共享的权限映射。 - [ ] 不新增前端路由。 - [ ] 自助进件的既有流程与存量商户行为不受影响。 **测试与验收** - [ ] 接口级测试覆盖：纳管成功、通道查不到、主体名不符、已被其他商家绑定（提示但放行）、重复纳管幂等、该门店已有进行中/已通过进件的冲突、解绑、解绑的在途资金拦截；使用真实测试库与模拟汇付响应，**不创建真实汇付商户**。 - [ ] 支付链路全量测试通过（仓库既有基线失败除外）。 - [ ] 拿**一个**真实的外部进件商户端到端走通：后台纳管 → 进度收敛到收款就绪 → 商户端能登录并看到已就绪 → 真实收一笔。 ## Further Notes - 本票对应规格 [spec.md](../spec.md)。规格里 31 条用户故事与本票的交付内容一一对应，实现细节以规格的 Implementation Decisions 为准。 - 接口级测试沿用现有进件链路的同一条接缝（接口 + 真实测试库 + 模拟汇付响应），不需要新接缝。 - 关于二清：能共用一个汇付商户号本身就意味着只有一个主体，共用不引入资金二次清算；真正的风险是**绑错主体**，靠纳管时的**主体名人工核对 + 显式确认 + 留痕 + 可解绑**拦截，而不是一个字符串比较。 - 纳管的第一步是只读核验通道权限：查不到说明该商户不在我们**渠道商**的管辖范围内。按领域上下文，数据权限由签名身份决定，**把商户改成挂在平台自己名下既解决不了权限失败、还会平白多出材料要求**，不要把它当成「迁一下归属就能解决」的事。 - 交付顺序上建议先做纳管、再做解绑（解绑依赖纳管产生的记录），但同属一张票。