# 商户端可见的收款状态以能力快照为准

进件申请的六项阶段只回答「进件办到哪一步」，而通道侧的商户可用性（`merchant_stat`、取现与结算开关）会随汇付控台的操作随时变化，两者不能互相代表。因此商户端凡是回答「我现在能不能收款」的地方，一律以**收款能力快照**为准——与下单闸门 `MerchantPaymentReadinessService.requireCollectingMerchant` 读同一份数据、给出同一句文案；进件页只补出此前不可见的另外两项完成条件（结算银行卡核实、通道商户状态），**不把通道状态混进六项阶段**。

时效由既有的能力定时核实（30 分钟一轮、只扫超过 6 小时未核实的申请）与商户端「立即核实」的手动刷新共同保证。手动刷新带冷却（`capability_sync_until`，冷却期内直接回当前快照），**不新增任何定时任务**；进件进度仍只由回调与手动刷新推进。页面必须显示最近核实时间，因为它是这份快照对外唯一的时效证据。

商户端只看到派生结果（能否收款 + 原因 + 最近核实时间），不返回 `merchant_stat`、`cash_switch_status` 等通道原始值；原因文案与下单被拒时逐字一致，避免同一个事实出现两套口径。

## 与 ADR-0001 的关系

本条不改动 ADR-0001 的判定：进件与微信支付开通仍分阶段判定，「不增加定时查询」的取舍继续有效，本次不新增任何轮询。需要写明的是边界——能力快照的定时核实比 ADR-0001 更早存在（2026-09-12 落地），ADR-0001 约束的是**进件进度**，不是能力核实。写下这条边界，后来者才不会以为商户端展示收款状态是在绕开 ADR-0001。

另一处需要标注的是术语：本条把「收款能力」收窄成通道侧的事实之后，ADR-0001 里两处旧用词与它不再一致。已在 [ADR 0001](0001-merchant-onboarding-and-wechat-provisioning.md) 里以「2026-09-17 术语修订」一节显式标出并改读，判定未动。

## 考虑过但没选的

- **把 `bank`／`merchantNormal` 加进 `LABELS` 当第七、第八项阶段。** `complete()` 正是拿 `LABELS` 的键集做完成判定，且这两项是布尔值、其余六项是字符串 `confirmed`，加进去会两次破坏完成判定，进件将永远无法 approved。
- **商户端每次进页面实时查通道。** 违反 ADR-0001 由用户明确选择的取舍，并把通道查询量交给页面打开次数。
- **用 `capability_verified_at` 充当冷却。** 查询失败时该列不推进，通道查不通时按钮可被连点，等于没有节流。
- **复用进件进度表的 `sync_owner`／`sync_until`。** 会把进件与能力两条本该独立的链路绑在一起。