junhong_cmp_fiber/openspec/changes/add-payment-config-management/specs/order-payment/spec.md

MODIFIED Requirements

Requirement: 订单关联支付配置

系统 SHALL 在创建订单时记录当前生效的支付配置 ID，用于回调处理时加载正确的配置验签。

Scenario: 创建订单时记录支付配置 ID

• WHEN 用户创建订单（H5 或后台）
• THEN 系统查询当前生效的微信参数配置（is_active=true）
• THEN 将 payment_config_id 写入订单记录

订单模型变更

tb_order 新增字段：

字段	类型	必填	说明
payment_config_id	bigint	❌	下单时使用的微信参数配置 ID（钱包/线下支付时为 NULL）

OrderResponse 新增返回字段

{
  "code": 0,
  "data": {
    "id": 1,
    "order_no": "ORD20260316100000123456",
    "payment_config_id": 1,
    "...": "（现有字段不变）"
  },
  "msg": "success",
  "timestamp": "2026-03-16T10:00:00+08:00"
}

Scenario: 钱包/线下支付不记录配置 ID

• WHEN 用户创建订单，支付方式为 wallet 或 offline
• THEN 订单的 payment_config_id 为 NULL

Scenario: 无生效配置时拒绝第三方支付

• WHEN 用户创建订单时选择第三方支付（wechat/fuiou），但当前无生效的微信参数配置
• THEN 系统返回错误

{
  "code": 1175,
  "data": null,
  "msg": "暂无可用的第三方支付渠道，请使用钱包支付",
  "timestamp": "2026-03-16T10:00:00+08:00"
}

Scenario: 无生效配置时允许钱包支付

• WHEN 当前无生效支付配置，用户选择钱包支付
• THEN 系统正常创建订单，payment_config_id 为 NULL

---

Requirement: 第三方支付回调

系统 SHALL 处理微信支付和富友支付的支付回调。回调验签 MUST 使用订单关联的 payment_config_id 加载对应配置，而非当前生效配置。系统新增富友支付回调端点和代理充值回调分发。

Scenario: 微信支付成功回调（订单）

POST /api/callback/wechat-pay
Content-Type: 由微信服务器决定
无需认证

• WHEN 收到微信支付成功回调，订单号格式为 ORD 开头
• THEN 系统查询订单，通过 order.payment_config_id 加载对应支付配置
• THEN 系统使用该配置的凭证验证签名，更新订单状态，激活套餐

成功响应

{
  "code": 0,
  "data": {
    "return_code": "SUCCESS"
  },
  "msg": "success",
  "timestamp": "2026-03-16T10:00:00+08:00"
}

Scenario: 微信支付成功回调（资产充值）

• WHEN 收到微信支付成功回调，订单号格式为 CRCH 开头（修复：当前代码误用废弃的 RCH 前缀）
• THEN 系统查询 tb_asset_recharge_record，通过 payment_config_id 加载配置验签
• THEN 系统更新充值订单状态，增加钱包余额，触发佣金判断

Scenario: 微信支付成功回调（代理充值）

• WHEN 收到微信支付成功回调，订单号格式为 ARCH 开头（全新支持）
• THEN 系统查询 tb_agent_recharge_record，通过 payment_config_id 加载配置验签
• THEN 系统更新充值订单状态，增加代理余额钱包余额

Scenario: 富友支付成功回调

POST /api/callback/fuiou-pay
Content-Type: application/x-www-form-urlencoded
无需认证

• WHEN 收到富友支付回调，result_code=000000
• THEN 系统解析 XML（GBK → UTF-8），通过 mchnt_order_no 判断订单类型（ORD/CRCH/ARCH）
• THEN 查询对应表，通过 payment_config_id 加载富友配置，使用富友公钥验签
• THEN 验证金额匹配后，调用对应 Service 的 HandlePaymentCallback

成功响应（XML，GBK 编码）

<?xml version="1.0" encoding="GBK"?>
<xml>
  <result_code>000000</result_code>
  <result_msg>success</result_msg>
</xml>

Scenario: 重复回调

• WHEN 收到已处理订单/充值的重复回调（微信或富友）
• THEN 系统返回成功响应，不重复处理

Scenario: 签名验证失败

• WHEN 回调签名验证失败（微信或富友）
• THEN 系统拒绝处理，记录 ERROR 日志，返回失败响应

Scenario: 订单号不存在

• WHEN 回调中的订单号在系统中不存在
• THEN 系统记录 ERROR 日志，返回失败响应

---

Requirement: 钱包支付与第三方支付的区别

系统 SHALL 区分后台钱包支付和第三方支付的业务逻辑。第三方支付方式对前端统一显示为"微信支付"，后端根据生效配置自动路由。

后台支付方式限制（CreateAdminOrderRequest）：

• 允许：wallet、offline
• 拒绝：wechat、alipay、fuiou、其他任何值

H5/小程序支付方式（两步走）：

• 步骤 1 创建订单：payment_method 为 wallet
• 步骤 2 发起第三方支付：通过独立端点 /orders/:id/wechat-pay/jsapi 等

Scenario: 后台参数验证拒绝第三方支付

• WHEN 代理在后台创建订单时 payment_method 为 wechat 或 fuiou
• THEN DTO 验证阶段拒绝请求

{
  "code": 1001,
  "data": null,
  "msg": "请求参数解析失败",
  "timestamp": "2026-03-16T10:00:00+08:00"
}

Scenario: H5 两步走支付

• WHEN 个人客户在 H5 创建订单（步骤 1）
• THEN 订单创建为待支付状态，记录 payment_config_id
• WHEN 客户调用 POST /orders/:id/wechat-pay/jsapi（步骤 2）
• THEN 系统按 payment_config_id 加载配置，根据 provider_type 发起对应渠道支付（本次留桩）

---

Requirement: 配置切换不取消在途订单

• WHEN 管理员激活新配置时，系统中存在使用旧配置创建的待支付订单
• THEN 系统不取消这些订单
• THEN 旧订单若支付成功，回调按 payment_config_id 加载旧配置验签
• THEN 旧订单若未支付，由 30 分钟超时机制自动取消