break
98c145fe70
Some checks failed
构建并部署到测试环境（无 SSH） / build-and-deploy (push) Failing after 3m55s
新增收款商户、商户池轮询、微信授权配置独立管理；三类新支付 （C端套餐购买、C端资产钱包充值、代理在线预存款充值）无条件 经商户池选择并冻结路由，无旧综合配置回退。merchant_id 为空 历史支付继续按 payment_config_id 双读。凭证版本化加载与 ID+版本缓存保证轮换一致性。删除商户池新支付创建开关及全部 引用。
28 lines
3.0 KiB
Markdown
28 lines
3.0 KiB
Markdown
## Why
|
||
|
||
当前所有线上支付依赖一份综合支付配置，无法按支付方式在多个实际收款商户之间受控轮询；已存在且可达的回调、查单和原路退款路径也缺少冻结商户事实，无法在商户停用后继续安全加载对应凭证。
|
||
|
||
本 Change 落实 AUG26-002：将收款商户、支付路由和 C 端微信授权分离，并以商户池快照取代新业务对旧综合支付配置的依赖。
|
||
|
||
## What Changes
|
||
|
||
- 新增独立商户管理：微信商户与支付宝商户分别建档；商户保存支付能力和敏感凭证，但历史支付单仅保存非敏感身份快照。
|
||
- 新增每种支付方式至多一个启用商户池，支持按成功收款金额、成功笔数或时间周期轮询；新支付仅从命中池选择实际商户。
|
||
- 新增全局唯一启用的微信授权配置，专供 C 端公众号 H5/JSSDK、小程序登录、OpenID 和支付 AppID；它不是微信收款商户。
|
||
- 新建 C 端套餐购买、资产钱包充值、代理在线预存款充值按商户池路由；后台线下/钱包支付不经过商户池。代理全局允许范围、其与商户池方式的交集及对外方式查询仍由对应代理自充 Change 负责；本 Change 只在方式已获准后选择实际商户。无可用商户时失败，不得回退旧配置或自动换商户重试。
|
||
- 迁移完成后部署支持按 merchant ID 或旧 `payment_config_id` 双读的 API/Worker；三类后续新支付立即只走商户池并冻结路由，无可用池、成员或停用池时明确失败且不回退旧综合支付配置。merchant ID 为空的仅为历史订单，继续处理其自身回调、查单和已有可达的原路退款，直到独立 Change 按数据留存期删除旧读取路径。
|
||
- 零条当前生效综合支付配置时仅创建新 Schema 和管理入口，不插入空商户、空商户池或空微信授权配置；新线上支付明确失败，微信授权功能明确返回未配置。富友 `CommonQuery` 保持现有请求、签名、验签、状态和恢复兼容基线，只实现本地双读凭证与商户加载，不改协议或退款；未第三方实测可记录但不构成本 Change 实施或归档阻塞。验证在本地工作区以明确 `DB_*` 指向维护者指定的 `junhong_cmp_test` PostgreSQL、Redis DB6 执行；完成后才提交推送 Iteration/8-11，由 Gitea 构建/部署 `cmp-test` 测试镜像并检查迁移版本，日志位于 `/opt/junhong_cmp/logs`，不重置整库。
|
||
|
||
## Capabilities
|
||
|
||
### New Capabilities
|
||
|
||
- `merchant-payment-routing`: 商户、商户池、微信授权配置、轮询、历史商户快照和迁移切换行为。
|
||
|
||
### Modified Capabilities
|
||
|
||
- 无。该能力向既有支付创建、回调、查单和已有原路退款调用链提供已选商户事实，不改变既有资金幂等不变量，也不新增渠道退款能力。
|
||
|
||
## Impact
|
||
|
||
影响支付配置模型和后台接口、`tb_payment`/订单/充值支付关联、微信/支付宝/富友支付加载和回调、支付与退款审计、敏感信息访问及新增成对迁移。 |