商户端一次提交进件资料与微信支付开通意图，平台在基本进件审核通过后继续开通微信支付。两阶段分别记录结果；基本进件成功而微信开通失败时，保留已通过的商户身份，仅重试失败的开通步骤，避免因支付配置失败重复进件。商户端展示审核、待实名、开通中及失败等阶段，不能用一个整体失败状态抹掉已完成的进件结果。
本地开发环境无法接收汇付回调，由商户端“刷新进度”和管理后台刷新主动查询审核及业务结果，并继续已满足前置条件的开通步骤。保留回调处理，不增加定时查询；没有回调且无人刷新时，进度会保持最后已知状态。这一取舍由用户明确选择，不能将它擅自改为后台自动轮询。
三处由用户明确选择。它们修订上文执行方式，不改变“进件与微信支付开通分别判定”这一根本判定。
不做“一次进件即完成收款能力”。 微信侧是多段异步外部流程：实名审核要等微信处理，中途可能有账户验证与签约，最后还有必须由人**扫描微信小程序码**完成的授权（qrcode_data／“授权二维码”，汇付在实名查询与业务开通异步通知里都会回传）。平台无法在提交那一刻把这些走完，硬做只会做出一个看起来完成、实际没生效的状态。因此收敛为：**进件一次收齐资料**，之后进件、微信业务开通、微信实名认证、延迟入账与自动结算按阶段推进；两端页面刷新查看，商户按阶段执行“下一步”。上文“由商户端刷新进度和管理后台刷新主动查询并继续开通步骤”的执行方式不变。
微信实名认证走法人（contact_type=LEGAL）。 实名申请使用法人信息发起，进件表单一次收齐所需材料，因此要新增**法人手机号**一项。不选经办人（SUPER）：它额外要求经办人身份证件正反面与**加盖公章的《微信业务办理授权函》**，盖章件无法自助提交。
未完成微信实名认证与授权前，商户不允许收款。 “收款就绪”必须把微信支付业务开通与实名／授权纳入前提，不能只凭进件审核通过、结算银行卡与取现能力判定。这也意味着“等待实名”是收款能力的真实缺项，不是可以忽略的合规补课。
二维码展示不需要新做：商户端与后台详情页已经在渲染 qrcode_data。
