yeg
2 天以前 3773bc4f2d966fb248f96c7e5cedce58c91df689
refs
用户 yeg <1347747024@qq.com>
星期一, 十月 12, 2026 15:27 +0800
提交者 yeg <1347747024@qq.com>
星期一, 十月 12, 2026 15:27 +0800
提交3773bc4f2d966fb248f96c7e5cedce58c91df689
目录 f6976402839a016e35bcc31df5430ad94af93c4a 目录 | zip | gz
parent 65085442d5e6dfe2eaa0c7794a2fbc09d801a0dd 查看 | 对比
fix(merchant): 纳管前把申请单号与商户号配一次对,错号当场拒绝

原先只校验申请单号非空,不校验它属不属于这个商户号,所以乱填一个号照样能纳管成功。

后果不是误放(错号会让基础审核永远确认不了、闸门一直拒),而是留下一具尸体:记录建出来了,
刷新时通道回「申请单不存在」,进度里挂的却是「汇付查询未成功,请稍后刷新或联系平台运营」——
看起来像通道抖动;而重复纳管是幂等的、不会用新号覆盖旧号,运营只能解绑重来。

通道对这两个字段是一起校验的(2026-10-12 实测:乱填的号、以及真实存在但属于别的商户号的号,
都回 00000001 申请单不存在),所以建记录前拿 (商户号, 申请单号) 查一次就能拦住:

- adopt 里配对不通过就直接拒绝,说清是哪一栏错了,不建任何记录;
- 核验那一步带着申请单号一起去(错号作为硬拦截项提前列出);界面上改申请单号同样作废上一次核验,
避免「核验的是这个号、提交的是另一个号」。
- 判定路径一个字没动:仍然是「只查询、不下发」,核准用的就是刷新第一步那个查询。

测试补两条:错号必须拒绝且进件与结算卡都不该建、核验要把原因提前说出来。
5个文件已修改
100 ■■■■■ 已修改文件
docs/adr/0006-managed-onboarding-is-query-only.md 6 ●●●●● 对比 | 查看 | 原始文档 | blame | 历史
talent-card-admin/src/views/MerchantSettlementView.vue 6 ●●●●● 对比 | 查看 | 原始文档 | blame | 历史
talent-card-server/src/main/java/com/talentcard/server/business/admin/AdminManagementController.java 2 ●●●●● 对比 | 查看 | 原始文档 | blame | 历史
talent-card-server/src/main/java/com/talentcard/server/business/admin/MerchantManagedOnboardingService.java 37 ●●●●● 对比 | 查看 | 原始文档 | blame | 历史
talent-card-server/src/test/java/com/talentcard/server/business/admin/MerchantManagedOnboardingTests.java 49 ●●●●● 对比 | 查看 | 原始文档 | blame | 历史