|
@@ -2328,3 +2328,15 @@ Studio 已有 `/balance`、Token 免登录、NewAPI 余额、支付二维码、
|
|
|
2. 若该宿主以 Bytecode 入口运行，在**与线上 Node 版本相同的环境**重新生成 `server.jsc`，然后重载 PM2 的 `nova-server` 进程；如果直接以 `server.js` 运行，只需完成源码更新后 reload。不要在代理机或独立 `fmode-server` 进程替代此步骤。
|
|
2. 若该宿主以 Bytecode 入口运行，在**与线上 Node 版本相同的环境**重新生成 `server.jsc`，然后重载 PM2 的 `nova-server` 进程；如果直接以 `server.js` 运行，只需完成源码更新后 reload。不要在代理机或独立 `fmode-server` 进程替代此步骤。
|
|
|
3. 发布 `fmode-wxpay-api/dist/0.0.5/` 并重载其实际宿主，保留商户配置注入。这是微信回调验签门禁，与第 2 步的 `/api/fmode` 路由发布相互独立。
|
|
3. 发布 `fmode-wxpay-api/dist/0.0.5/` 并重载其实际宿主，保留商户配置注入。这是微信回调验签门禁，与第 2 步的 `/api/fmode` 路由发布相互独立。
|
|
|
4. 先重跑本节的未核验探针，预期为 `409` 且命中“支付订单尚未核验完成”；随后使用**原支付账户**复用已经支付的 ¥0.01 订单，验证第一次 `source=verified-payment`、第二次 `idempotent=true`、余额仅增加一次，并在 Balance 页面刷新与 checkpoint `fetchCalls=0` 后将 P0 标记为完成。
|
|
4. 先重跑本节的未核验探针，预期为 `409` 且命中“支付订单尚未核验完成”；随后使用**原支付账户**复用已经支付的 ¥0.01 订单，验证第一次 `source=verified-payment`、第二次 `idempotent=true`、余额仅增加一次，并在 Balance 页面刷新与 checkpoint `fetchCalls=0` 后将 P0 标记为完成。
|
|
|
|
|
+
|
|
|
|
|
+### 21.31 2026-09-05 支付回调方案确认与临时补丁撤销
|
|
|
|
|
+
|
|
|
|
|
+经后端方案确认，微信支付的既有职责链路保持不变：`recharge/order` 创建 `AccountLog`，微信官方回调负责更新支付状态，回调中的 `fun_id` 触发云函数，云函数再按现有业务规则将支付余额划拨到 fmodeAPI。VOC 技能只读取 fmodeAPI 的余额、用量和计费规则，不参与微信回调、旧钱包扣减或划拨实现。
|
|
|
|
|
+
|
|
|
|
|
+此前为规避测试账户旧钱包负余额而提交的 `c61d1006` 临时补丁已由 future-server 提交 `79b60341` 完整反向撤销，包含以下内容：
|
|
|
|
|
+
|
|
|
|
|
+- `/api/fmode/newapi/topup` 的 `verifiedPayment` 直入 NewAPI 分支；
|
|
|
|
|
+- `topUpNewApiQuota` 的支付回调幂等锁和 `payment_provider` 扩展；
|
|
|
|
|
+- `fmode-wxpay-api` 的回调验签顺序改造。
|
|
|
|
|
+
|
|
|
|
|
+最终实现口径：不新增支付接口，不新增任务级支付或独立 VOC 钱包，不修改微信回调。所有任务继续按实际 NewAPI 调用扣费；余额不足时由技能返回现有 Token Balance 链接或现有二维码入口。`c61d1006`、`verifiedPayment`、`WXPAY:<AccountLogId>` 不再作为生产部署或联调前提，历史章节仅保留为审计记录。
|
gangvy