fix: 修复代理钱包订单创建逻辑,拆分后台/H5端下单方法并归档变更
All checks were successful
构建并部署到测试环境(无 SSH) / build-and-deploy (push) Successful in 6m54s
All checks were successful
构建并部署到测试环境(无 SSH) / build-and-deploy (push) Successful in 6m54s
- 拆分订单创建为 CreateAdminOrder(后台一步支付)和 CreateH5Order(H5 两步支付) - 新增 CreateAdminOrderRequest DTO,后台仅允许 wallet/offline 支付方式 - 同步 delta specs 到主规格(order-payment 更新 + admin-order-creation 新增) - 归档 fix-agent-wallet-order-creation 变更 - 新增 implement-order-expiration 变更提案
This commit is contained in:
@@ -107,45 +107,80 @@
|
||||
#### Scenario: 余额扣减后套餐激活失败
|
||||
- **WHEN** 余额扣减成功但套餐激活失败
|
||||
- **THEN** 事务回滚,余额恢复,订单状态不变
|
||||
## ADDED Requirements
|
||||
|
||||
---
|
||||
|
||||
### Requirement: 后台钱包一步支付
|
||||
|
||||
系统 SHALL 支持后台订单创建时使用钱包支付立即完成订单,无需后续调用支付接口。
|
||||
系统 SHALL 支持后台订单创建时使用钱包支付立即完成订单,无需后续调用支付接口。后台订单创建使用独立的 Service 方法(`CreateAdminOrder()`),与 H5 端的 `CreateH5Order()` 方法隔离,避免逻辑混淆。
|
||||
|
||||
**后台钱包支付流程**(一步到位):
|
||||
1. 检查钱包余额是否充足(事务外快速失败)
|
||||
2. 在事务中:扣减钱包余额 → 创建已支付订单(`payment_status` = 2)→ 激活套餐
|
||||
3. 返回已支付的订单信息
|
||||
|
||||
**与 H5 端的区别**:
|
||||
- 后台:立即扣款,订单创建后即为已支付状态(`payment_status` = 2)
|
||||
- H5 端:冻结余额,创建待支付订单(`payment_status` = 1),需用户调用支付接口
|
||||
|
||||
#### Scenario: 后台订单创建时钱包支付
|
||||
|
||||
- **WHEN** 代理在后台创建订单,支付方式为 wallet,钱包余额充足
|
||||
- **THEN** 系统创建订单,立即扣减钱包余额,订单状态为已支付(`payment_status` = 2),激活套餐
|
||||
- **THEN** 系统调用 `CreateAdminOrder()` 方法,创建订单,立即扣减钱包余额,订单状态为已支付(`payment_status` = 2),激活套餐
|
||||
|
||||
#### Scenario: 后台钱包支付余额不足
|
||||
|
||||
- **WHEN** 代理在后台创建订单,支付方式为 wallet,钱包余额不足
|
||||
- **THEN** 系统返回错误"余额不足",订单创建失败
|
||||
- **THEN** 系统调用 `CreateAdminOrder()` 方法,在事务外检查余额,返回错误"余额不足",订单创建失败
|
||||
|
||||
#### Scenario: 后台钱包支付订单响应
|
||||
|
||||
- **WHEN** 后台钱包支付订单创建成功
|
||||
- **THEN** API 响应包含已支付的订单信息,`payment_status` = 2,`payment_method` = "wallet",`paid_at` 为当前时间
|
||||
|
||||
#### Scenario: 后台钱包支付不创建待支付订单
|
||||
|
||||
- **WHEN** 代理在后台创建 wallet 订单
|
||||
- **THEN** 系统不创建待支付订单(`payment_status` != 1),直接完成支付
|
||||
- **THEN** 系统不创建待支付订单(`payment_status` != 1),直接完成支付和套餐激活
|
||||
|
||||
#### Scenario: 后台钱包支付使用独立方法
|
||||
|
||||
- **WHEN** 代理在后台创建 wallet 订单
|
||||
- **THEN** Handler 层调用 `OrderService.CreateAdminOrder()` 方法,不调用通用的 `Create()` 或 `CreateH5Order()` 方法
|
||||
|
||||
---
|
||||
|
||||
### Requirement: H5 钱包两步支付保持不变
|
||||
|
||||
系统 SHALL 保持 H5 端钱包支付的两步流程(创建待支付订单 → 调用支付接口)。
|
||||
系统 SHALL 保持 H5 端钱包支付的两步流程(创建待支付订单 → 调用支付接口)。H5 端订单创建使用独立的 Service 方法(`CreateH5Order()`),与后台的 `CreateAdminOrder()` 方法隔离。
|
||||
|
||||
**H5 钱包支付流程**(两步流程):
|
||||
1. 创建订单:冻结钱包余额 → 创建待支付订单(`payment_status` = 1)
|
||||
2. 用户调用支付接口:扣减钱包余额 → 更新订单状态为已支付 → 激活套餐
|
||||
|
||||
**与后台的区别**:
|
||||
- H5 端:创建待支付订单,用户需调用支付接口完成支付
|
||||
- 后台:立即扣款,订单创建后即为已支付状态
|
||||
|
||||
#### Scenario: H5 创建待支付订单
|
||||
|
||||
- **WHEN** 个人客户在 H5 端创建订单,支付方式为 wallet
|
||||
- **THEN** 系统创建订单,`payment_status` = 1(待支付),不扣减钱包余额
|
||||
- **THEN** 系统调用 `CreateH5Order()` 方法,创建订单,`payment_status` = 1(待支付),冻结钱包余额,不立即扣款
|
||||
|
||||
#### Scenario: H5 调用 WalletPay 接口支付
|
||||
|
||||
- **WHEN** 个人客户调用 WalletPay 接口支付待支付订单
|
||||
- **THEN** 系统扣减钱包余额,更新订单状态为已支付,激活套餐
|
||||
|
||||
#### Scenario: H5 和后台钱包支付流程独立
|
||||
|
||||
- **WHEN** H5 端创建 wallet 订单
|
||||
- **THEN** 不影响后台 wallet 订单的一步支付逻辑
|
||||
- **THEN** 系统调用 `CreateH5Order()` 方法,不影响后台 wallet 订单的一步支付逻辑
|
||||
|
||||
#### Scenario: H5 钱包支付使用独立方法
|
||||
|
||||
- **WHEN** 个人客户在 H5 端创建 wallet 订单
|
||||
- **THEN** Handler 层调用 `OrderService.CreateH5Order()` 方法,不调用 `CreateAdminOrder()` 方法
|
||||
|
||||
---
|
||||
|
||||
@@ -253,16 +288,38 @@
|
||||
|
||||
### Requirement: 钱包支付与第三方支付的区别
|
||||
|
||||
系统 SHALL 区分后台钱包支付和第三方支付的业务逻辑。
|
||||
系统 SHALL 区分后台钱包支付和第三方支付的业务逻辑。后台订单创建 MUST 在 Handler 层强制验证支付方式,拒绝 `wechat` 和 `alipay` 支付方式。
|
||||
|
||||
#### Scenario: 后台不支持第三方支付
|
||||
- **WHEN** 代理在后台创建订单时选择 wechat 或 alipay
|
||||
- **THEN** 系统返回错误"后台只支持 wallet 和 offline 支付方式"
|
||||
**后台支付方式限制**:
|
||||
- 允许:`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** 系统创建待支付订单,返回支付参数(prepay_id 或 h5_url)
|
||||
- **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)
|
||||
|
||||
Reference in New Issue
Block a user