junhong_cmp_fiber/openspec/specs/order-payment/spec.md

ADDED Requirements

Requirement: 线下支付方式

系统 SHALL 支持线下支付方式（offline），仅用于代购订单。线下支付的订单创建后直接标记为已支付，跳过支付流程。

Scenario: 创建线下支付订单

• WHEN 平台账号创建订单时选择支付方式为 offline
• THEN 系统创建订单，payment_status 直接设为 2（已支付），payment_method = "offline"

Scenario: 线下支付权限限制

• WHEN 非平台账号（代理/个人客户）尝试使用线下支付
• THEN 系统返回错误 "只有平台账号可以使用线下支付"

Scenario: 线下支付订单自动激活套餐

• WHEN 创建线下支付订单成功
• THEN 系统自动激活套餐，创建 PackageUsage 记录

Scenario: 线下支付不扣钱包

• WHEN 订单使用线下支付
• THEN 系统不扣减任何钱包余额

---

Requirement: 钱包支付

系统 SHALL 支持使用钱包余额支付订单。支付成功后 MUST 扣减钱包余额并激活套餐。

Scenario: 钱包余额充足

• WHEN 买家使用钱包支付，余额充足
• THEN 系统扣减钱包余额，更新订单状态为已支付，创建套餐使用记录

Scenario: 钱包余额不足

• WHEN 买家使用钱包支付，余额不足
• THEN 系统返回错误 "钱包余额不足"

Scenario: 订单已支付

• WHEN 买家尝试支付已支付的订单
• THEN 系统返回错误 "订单已支付"

Scenario: 订单已取消

• WHEN 买家尝试支付已取消的订单
• THEN 系统返回错误 "订单已取消"

---

Requirement: 第三方支付回调

系统 SHALL 处理微信支付和支付宝的支付回调，支持订单支付和钱包充值两种场景。回调处理 MUST 幂等。

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

• WHEN 收到微信支付成功回调，订单号格式为 ORD 开头
• THEN 系统验证签名，更新订单状态，激活套餐，返回成功响应

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

• WHEN 收到微信支付成功回调，订单号格式为 RCH 开头
• THEN 系统验证签名，更新充值订单状态，增加钱包余额，更新累计充值，触发佣金判断，返回成功响应

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

• WHEN 收到支付宝支付成功回调，订单号格式为 ORD 开头
• THEN 系统验证签名，更新订单状态，激活套餐，返回成功响应

Scenario: 支付宝成功回调（充值）

• WHEN 收到支付宝支付成功回调，订单号格式为 RCH 开头
• THEN 系统验证签名，更新充值订单状态，增加钱包余额，更新累计充值，触发佣金判断，返回成功响应

Scenario: 重复回调

• WHEN 收到已处理订单的重复回调
• THEN 系统返回成功响应，不重复处理

Scenario: 签名验证失败

• WHEN 回调签名验证失败
• THEN 系统拒绝处理，返回失败响应

---

Requirement: 套餐激活

支付成功后系统 MUST 激活套餐，创建 PackageUsage 记录。代购订单也需激活套餐，但不更新累计充值。

Scenario: 单卡套餐激活

• WHEN 单卡订单支付成功
• THEN 系统创建 PackageUsage，usage_type 为 single_card，关联 iot_card_id

Scenario: 设备套餐激活

• WHEN 设备订单支付成功
• THEN 系统创建 PackageUsage，usage_type 为 device，关联 device_id

Scenario: 套餐有效期计算

• WHEN 套餐激活
• THEN 有效期 = 激活时间 + 套餐时长（月）

Scenario: 代购订单激活套餐

• WHEN 代购订单（is_purchase_on_behalf = true）创建成功
• THEN 系统激活套餐，但不更新卡/设备的 accumulated_recharge

---

Requirement: 支付事务保证

钱包支付 MUST 在事务中完成：余额扣减、订单状态更新、套餐激活。任一步骤失败则全部回滚。

Scenario: 事务成功

• WHEN 所有步骤成功
• THEN 事务提交，支付完成

Scenario: 余额扣减后套餐激活失败

• WHEN 余额扣减成功但套餐激活失败
• THEN 事务回滚，余额恢复，订单状态不变

---

Requirement: 后台钱包一步支付

系统 SHALL 支持后台订单创建时使用钱包支付立即完成订单，无需后续调用支付接口。后台订单创建使用独立的 Service 方法（CreateAdminOrder()），与 H5 端的 CreateH5Order() 方法隔离，避免逻辑混淆。

后台钱包支付流程（一步到位）：

1. 检查钱包余额是否充足（事务外快速失败）
2. 在事务中：扣减钱包余额 → 创建已支付订单（payment_status = 2）→ 激活套餐
3. 返回已支付的订单信息

与 H5 端的区别：

• 后台：立即扣款，订单创建后即为已支付状态（payment_status = 2）
• H5 端：冻结余额，创建待支付订单（payment_status = 1），需用户调用支付接口

Scenario: 后台订单创建时钱包支付

• WHEN 代理在后台创建订单，支付方式为 wallet，钱包余额充足
• THEN 系统调用 CreateAdminOrder() 方法，创建订单，立即扣减钱包余额，订单状态为已支付（payment_status = 2），激活套餐

Scenario: 后台钱包支付余额不足

• WHEN 代理在后台创建订单，支付方式为 wallet，钱包余额不足
• THEN 系统调用 CreateAdminOrder() 方法，在事务外检查余额，返回错误"余额不足"，订单创建失败

Scenario: 后台钱包支付订单响应

• WHEN 后台钱包支付订单创建成功
• THEN API 响应包含已支付的订单信息，payment_status = 2，payment_method = "wallet"，paid_at 为当前时间

Scenario: 后台钱包支付不创建待支付订单

• WHEN 代理在后台创建 wallet 订单
• THEN 系统不创建待支付订单（payment_status != 1），直接完成支付和套餐激活

Scenario: 后台钱包支付使用独立方法

• WHEN 代理在后台创建 wallet 订单
• THEN Handler 层调用 OrderService.CreateAdminOrder() 方法，不调用通用的 Create() 或 CreateH5Order() 方法

---

Requirement: H5 钱包两步支付保持不变

系统 SHALL 保持 H5 端钱包支付的两步流程（创建待支付订单 → 调用支付接口）。H5 端订单创建使用独立的 Service 方法（CreateH5Order()），与后台的 CreateAdminOrder() 方法隔离。

H5 钱包支付流程（两步流程）：

1. 创建订单：冻结钱包余额 → 创建待支付订单（payment_status = 1）
2. 用户调用支付接口：扣减钱包余额 → 更新订单状态为已支付 → 激活套餐

与后台的区别：

• H5 端：创建待支付订单，用户需调用支付接口完成支付
• 后台：立即扣款，订单创建后即为已支付状态

Scenario: H5 创建待支付订单

• WHEN 个人客户在 H5 端创建订单，支付方式为 wallet
• THEN 系统调用 CreateH5Order() 方法，创建订单，payment_status = 1（待支付），冻结钱包余额，不立即扣款

Scenario: H5 调用 WalletPay 接口支付

• WHEN 个人客户调用 WalletPay 接口支付待支付订单
• THEN 系统扣减钱包余额，更新订单状态为已支付，激活套餐

Scenario: H5 和后台钱包支付流程独立

• WHEN H5 端创建 wallet 订单
• THEN 系统调用 CreateH5Order() 方法，不影响后台 wallet 订单的一步支付逻辑

Scenario: H5 钱包支付使用独立方法

• WHEN 个人客户在 H5 端创建 wallet 订单
• THEN Handler 层调用 OrderService.CreateH5Order() 方法，不调用 CreateAdminOrder() 方法

---

Requirement: 钱包流水记录扩展

系统 SHALL 在钱包流水中记录交易子类型和关联店铺，支持按场景筛选。

Scenario: 自购钱包流水

• WHEN 代理为自己的资源购买套餐，使用 wallet
• THEN 钱包流水的 transaction_subtype = "self_purchase"，related_shop_id 为 NULL，remark = "购买套餐"

Scenario: 代购钱包流水

• WHEN 代理为下级代理购买套餐，使用 wallet
• THEN 钱包流水的 transaction_subtype = "purchase_for_subordinate"，related_shop_id = 下级代理店铺 ID，remark = "为下级代理【XX】购买套餐"

Scenario: 钱包流水查询店铺名称

• WHEN 创建代购钱包流水
• THEN 系统查询下级店铺名称，填充到 remark 字段

Scenario: 钱包流水筛选

• WHEN 代理查询钱包流水，筛选 transaction_subtype = "purchase_for_subordinate"
• THEN 系统返回所有为下级代理购买的流水记录

---

Requirement: 钱包支付乐观锁

系统 SHALL 使用乐观锁防止钱包并发扣款导致余额不一致。

Scenario: 钱包扣款使用 version 字段

• WHEN 扣减钱包余额
• THEN SQL 语句包含 WHERE balance >= ? AND version = ?，更新时 version + 1

Scenario: 钱包并发扣款失败

• WHEN 两个请求同时扣减同一钱包
• THEN 只有一个请求成功，另一个返回"余额不足或并发冲突"

Scenario: 乐观锁重试逻辑

• WHEN 钱包扣款因 version 冲突失败
• THEN 系统不自动重试，返回错误（由客户端决定是否重试）

---

Requirement: 钱包支付幂等性

系统 SHALL 防止同一订单重复创建和重复扣款。

Scenario: 订单创建幂等性检查

• WHEN 同一买家对同一载体的同一套餐组合在短时间内重复创建订单
• THEN 系统返回已创建的订单，不重复扣款

Scenario: 幂等性使用 Redis 业务键

• WHEN 检查订单幂等性
• THEN 系统使用 Redis key order:idempotency:{buyer_type}:{buyer_id}:{order_type}:{carrier_type}:{carrier_id}:{sorted_package_ids}

Scenario: 幂等性 TTL

• WHEN 订单创建成功后标记幂等性
• THEN Redis key 的 TTL 为 3 分钟

Scenario: 分布式锁防止并发

• WHEN 订单创建前检查幂等性
• THEN 系统使用分布式锁 order:create:lock:{carrier_type}:{carrier_id}，TTL 10 秒

---

Requirement: 后台订单 API 响应扩展

系统 SHALL 在后台订单创建和查询 API 响应中包含钱包支付相关字段。

Scenario: 订单响应包含实际支付金额

• WHEN 查询钱包支付的订单
• THEN 响应包含 actual_paid_amount 字段

Scenario: 订单响应包含操作者信息

• WHEN 查询代购订单
• THEN 响应包含 operator_id、operator_type、operator_name 字段

Scenario: 订单响应包含购买备注

• WHEN 查询上级代理购买的订单
• THEN 响应包含 purchase_remark 字段，如"由上级代理【XX】购买"

---

Requirement: 钱包支付错误处理

系统 SHALL 在钱包支付失败时返回明确的错误信息。

Scenario: 钱包不存在

• WHEN 钱包支付时钱包不存在
• THEN 系统返回错误"钱包不存在"（CodeWalletNotFound）

Scenario: 余额不足

• WHEN 钱包支付时余额不足
• THEN 系统返回错误"余额不足"（CodeInsufficientBalance）

Scenario: 并发冲突

• WHEN 钱包扣款因 version 冲突失败
• THEN 系统返回错误"余额不足或并发冲突"（CodeInsufficientBalance）

Scenario: 套餐激活失败

• WHEN 钱包扣款成功但套餐激活失败
• THEN 事务回滚，钱包余额恢复，返回激活失败错误

---

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

系统 SHALL 区分后台钱包支付和第三方支付的业务逻辑。后台订单创建 MUST 在 Handler 层强制验证支付方式，拒绝 wechat 和 alipay 支付方式。

后台支付方式限制：

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

实现层级：

1. DTO 验证（第一道防线）：CreateAdminOrderRequest 的 payment_method 字段使用 validate:"oneof=wallet offline" 规则
2. Handler 验证（第二道防线）：调用 middleware.ValidateStruct(&req) 验证 DTO
3. Handler 兜底检查（第三道防线）：对所有支付方式进行权限检查，包括非法值

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

• WHEN 代理在后台创建订单时 payment_method 为 wechat 或 alipay
• THEN 系统在 Handler 层的 DTO 验证阶段拒绝请求，返回错误"请求参数解析失败"（CodeInvalidParam），订单创建失败

Scenario: 后台兜底检查拒绝其他支付方式

• WHEN 代理在后台创建订单时 payment_method 为未知值（防御性编程）
• THEN 系统在 Handler 层的兜底检查阶段拒绝请求，返回错误"后台仅支持钱包支付或线下支付"（CodeInvalidParam）

Scenario: H5 支持第三方支付

• WHEN 个人客户在 H5 端创建订单时选择 wechat 或 alipay
• THEN 系统调用 CreateH5Order() 方法，创建待支付订单，返回支付参数（prepay_id 或 h5_url）

Scenario: 钱包支付不需要支付参数

• WHEN 后台钱包支付订单创建成功
• THEN 响应不包含 prepay_id、h5_url 等第三方支付参数

Scenario: 后台使用独立的 DTO

• WHEN 后台创建订单
• THEN Handler 层使用 CreateAdminOrderRequest DTO（仅允许 wallet/offline），H5 端使用 CreateOrderRequest DTO（允许 wallet/wechat/alipay）

---

Requirement: 订单取消与钱包余额解冻

系统 SHALL 根据支付方式正确处理订单支付，包括钱包扣款、在线支付、混合支付等。新增订单取消（手动或自动）时的钱包余额解冻逻辑。

钱包支付流程：

1. 检查钱包可用余额是否充足
2. 冻结钱包余额（frozen_balance 增加）
3. 创建订单，状态为"待支付"
4. 订单完成后，扣减钱包余额（balance 减少，frozen_balance 减少），创建钱包明细记录
5. 订单取消时（手动或自动），解冻钱包余额（frozen_balance 减少）

在线支付流程：

1. 创建订单，状态为"待支付"
2. 调用第三方支付接口
3. 用户完成支付后，订单状态变更为"已支付"
4. 订单完成后，订单状态变更为"已完成"

混合支付流程：

1. 检查钱包可用余额是否充足（钱包支付部分）
2. 冻结钱包余额
3. 创建订单，状态为"待支付"
4. 调用第三方支付接口（在线支付部分）
5. 用户完成在线支付后，扣减钱包余额，订单状态变更为"已支付"
6. 订单完成后，订单状态变更为"已完成"
7. 订单取消时（手动或自动），解冻钱包余额

Scenario: 订单手动取消，解冻钱包余额

• WHEN 用户使用钱包支付创建订单，订单金额为 3000 分，然后手动取消订单
• THEN 系统解冻钱包余额 3000 分（frozen_balance 减少 3000），订单状态变更为"已取消"

Scenario: 订单超时自动取消，解冻钱包余额

• WHEN 用户使用混合支付创建订单，钱包预扣 2000 分，30 分钟后订单超时
• THEN 系统自动取消订单，解冻钱包余额 2000 分（frozen_balance 减少 2000），订单状态变更为"已取消"

Scenario: 订单取消（纯在线支付），无需解冻

• WHEN 用户使用纯在线支付创建订单，30 分钟后订单超时
• THEN 系统自动取消订单，不执行钱包解冻操作（因为没有钱包预扣）

Scenario: 钱包解冻事务保证

• WHEN 订单取消涉及钱包解冻
• THEN 订单状态更新（payment_status = 3、expires_at = NULL）和钱包余额解冻在同一事务中完成，任一失败则全部回滚

Scenario: 钱包解冻失败回滚

• WHEN 订单取消时，钱包解冻失败（如钱包不存在、冻结余额不足）
• THEN 事务回滚，订单状态不变，返回错误信息"订单取消失败"