# 微信直购订单按部署环境分流

本次代码仅准备在本地，下次版本发布时再部署生产环境。覆盖 Android 和 iOS 的 `requestMidasPaymentGameItem` 直购；旧 iOS 客服商户支付走另一套接口，不属于本次分流范围。

## 配置和部署顺序

| 云应用 | PAYMENT_APP_ENV | WX_MIDAS_PAY_SIGN_KEY |
| --- | --- | --- |
| 正式服 q6rvwvtnga | production（未配置时默认值） | 微信后台对应小游戏的正式虚拟支付 AppKey |
| 测试服 sor779u2w8 | test（必须明确设置） | 同一个小游戏的正式虚拟支付 AppKey |

AppKey 是虚拟支付签名密钥，不是 AppSecret，也不是商户 API v3 密钥。密钥只配置在云应用环境变量，不能放到客户端。配置错误时测试下单或回调将失败；生产转发也必须配置正确密钥。

两边替换并发布以下完整函数，无新增云函数依赖：

- `wx/orderPaySig.ts`
- `wx/iosorderPaySig.ts`
- `wx/payCallBack.ts`

先准备测试服函数和环境变量，再部署生产服回调及配置，最后验证新的测试直购订单。生产回调未上线前，不进行测试服真实支付。微信后台回调仍指向 `https://q6rvwvtnga.sealoshzh.site/wx/payCallBack`。

## 分流行为

1. 服务端用部署环境生成订单号：正式为 `wcx_`，测试为 `wct_`；订单记录 `paymentAppEnv`。客户端参数不能指定分流方向。订单号长度仍小于 32 字符。
2. 正式回调遇到 `wct_`，先校验原始 `Event & Payload` 的 HMAC-SHA256 `PayEventSig`，再转发完整请求体到固定测试服回调地址。原始 Payload 字符串不重新序列化，签名内容保持不变。
3. 测试服重复验签，并比对本地订单的环境、用户、商品、数量、原价，成功后执行原来的订单确认逻辑。两端仅接受 Env=0 的真实支付事件；mock 通知不能充当成功支付。
4. 转发最多等待 3 秒，不跟随重定向。只有测试服 HTTP 200 且 ErrCode=0 才向微信确认成功；错误或超时返回非零，不落到生产数据库处理。不转发原始用户请求头；防循环标记只用于拒绝再次转发，不能替代验签。
5. 生产旧订单继续原有处理；本次没有追溯改写历史订单，也没有扩大到生产旧回调的全量验签改造。测试新订单领取仍使用现有查单与领取接口。

此处的“测试服”是业务数据库环境。直购参数 `env=0` 没有改变，实际调用支付仍会扣款，不是微信沙箱。新手礼包当前在开发版/体验版改用客户端免费测试发货，因此不会创建此类测试支付订单；分流可用于其他直购商品以及后续恢复真实支付联调。

改动前已经创建的测试单仍为 `wcx_`，无法据此前缀自动分流。本次未修复之前已付但 state=0 的历史订单，需核实真实支付凭据后单独处理，不能直接根据客户端成功日志改为已支付。

## 验证

`node --test laf-cloud/tests/payment-routing.test.mjs laf-cloud/tests/jungle-treasure.test.mjs laf-cloud/tests/starter-pack.test.mjs laf-cloud/tests/monthly-card-renewal.test.mjs`

自动测试使用合成签名与模拟数据库/网络，覆盖环境前缀、签名、转发隔离、错误传播、订单匹配与重复回调。尚需部署后用微信真实回调验证 AppKey、签名和网络连通性；本地测试不能代替此项验收。

本次验证：分流、新手礼包、月卡共 23 项通过。额外 Jungle 旧测试 13 项中 7 项通过、6 项失败；将三个支付函数替换为 HEAD 的修改前版本在内存中重跑后，仍出现相同 6 项失败（奖励规划表、活动资格、回调完成状态及 usersAd 断言），没有为本任务修改这些旧测试。