Files
device-voice-h5/openspec/changes/update-payment-routing-policy/proposal.md
luo e82b0ab5da
All checks were successful
构建并部署前端到生产环境 / build-and-deploy (push) Successful in 4m41s
fix:微信支付
2026-09-23 09:32:48 +08:00

30 lines
2.2 KiB
Markdown

# Change: Align C端 payment flows with merchant-pool routing policy
## Why
The August payment iteration keeps the existing C端 payment creation endpoints, but changes how the backend routes payment creation through its merchant pool. The client must stop assuming that a failed or unknown payment-creation result can be retried against another merchant, otherwise one user action can create duplicate payment attempts and consume payment limits unexpectedly.
## What Changes
- Keep `POST /api/c/v1/orders/create` and `POST /api/c/v1/wallet/recharge` as the payment creation endpoints; do not add a merchant ID to client requests.
- Treat merchant selection as backend-owned and preserve the selected payment method and existing request fields (`identifier`, package IDs or amount, and WeChat-only `app_type`).
- Treat an explicit payment pre-order failure as the terminal result for the current attempt; surface the API error without automatically switching merchants or creating another payment.
- Treat timeout, connection interruption, and other unknown payment-creation results as indeterminate; do not automatically switch merchants or repeat payment creation. Any retry must be a deliberate, user-visible action after the applicable order/payment status is reconciled.
- Ensure payment-limit and attempt-count behavior is modeled as “every payment creation attempt counts”, rather than “only successful payments count”; client polling/status refresh must never create another payment.
- Continue to use the API-defined error codes and messages as the source of truth.
## Capabilities
### New Capabilities
- `payment-routing-policy`: Apply merchant-pool routing, terminal-failure, unknown-result, and payment-attempt accounting rules to C端 payment creation.
### Modified Capabilities
## Impact
- Affected API adapters: `api/modules/order.js`, `api/modules/wallet.js`.
- Affected payment callers: package order, wallet recharge, order-list payment, and shared payment-result/status refresh flows.
- No endpoint path or client merchant-selection configuration changes.
- Existing WeChat `pay_config`, Alipay `payment_link`, wallet payment, submit guards, and backend status reconciliation remain compatible.