一期方案调整：采用线下支付

版本：v0.1　日期：2026-10-15　性质：架构决策记录

一、结论

一期不接微信支付，全流程走线下收款；系统只做订单记录与记账。 凡是无法用现有条件直接实现的能力，一律留空位（接口与数据结构预留），二期再填。

二、这个决定一次解决了四个问题

最关键的一条：钱不经平台，平台就不是资金清算方。二清问题从架构上消失了。

三、一期收款流程（改造后）

四、订单状态机（改造后）

改动点：原来的「待支付」变成「待确认收款」；原来「已完成 → 触发分账」改成「已完成 → 只记本地流水」。

五、占位清单：无法直接实现的，先空着

每一处都留了接口定义与数据结构，二期只填实现体，不动调用方。

占位写法约定

// 云函数 pay/index.js
exports.notify = async (event) => {
  // TODO【二期】微信支付结果回调
  //   1. 验签
  //   2. 更新 orders.status
  //   3. 写 payments 记录
  //   4. 记录失败进入重试队列
  return { ok: true, stub: true };
};

规则：占位函数必须能正常返回、不报错，这样调用方代码可以按最终形态写好，二期只删 stub 分支。

六、数据结构需要调整的地方

新的订单状态枚举

0   待确认收款      ← 新
1   待派单
2   待服务
3   进行中
4   待确认
5   已完成
6   已取消
7   退款中          ← 一期为线下退款登记
8   已退款
9   售后中

七、对排期的影响

释放出来的约 1 天，建议加到 D21 做全流程回归测试。

八、这个方案需要甲方确认的三件事

第 3 条要特别说清楚：一期若平台真的向陪练者收佣金，属于「有偿提供信息服务」，合规上会多一层要求；如果一期只做内部试运营、不收费，这个问题不存在。 建议一期先不抽成。

九、必须提醒的一条：这个方案没有绕开所有问题

线下支付解决了资金链路的合规问题，但没解决：

但好消息是：这五条全都是「上线前」的要求，不再阻塞开发。 开发可以在个人主体测试号上完整跑通。

十、二期恢复清单

接微信支付时，按这个顺序填：