外观
案例 8：支付与权益验收
约 1348 字大约 4 分钟
本案例适用于平台管理员在真实支付上线前进行验收。目标不是“让支付成功”，而是确认支付状态、商户回调、订单幂等和权益发放均正确，且机密不进入浏览器与日志。
前置条件
- 站点已通过 HTTPS 域名访问，用户端与回调路径可从公网抵达。
- 已准备支付渠道测试环境或经过批准的小额真实环境。
- Billing Service 环境中配置支付开关、商户参数、私钥/公钥与通知地址。
- 管理员可查看商品、订单中心、支付流水和服务日志。
- 使用独立测试用户，避免用管理员账号验证用户权益。
第一步：创建可验收商品
选择一个最小积分包或测试套餐，记录下面的期望值：
| 验收字段 | 示例 |
|---|---|
| 商品名称 | 测试积分包_100 |
| 用户支付金额 | 测试环境对应金额 |
| 应发权益 | 100 通用积分，或指定会员期。 |
| 订单分类 | credit 或 membership。 |
| 支付渠道 | 微信支付或支付宝测试通道。 |
| 测试账号初始余额 | 下单前记录，用于验收差值。 |
商品显示文案、后台价格配置、支付创建参数和最终订单金额必须完全一致。
第二步：核对部署配置
在服务端 .env 或密钥管理系统检查，不要把真实值贴入后台或工单：
BILLING_PAYMENT_ENABLED=true
BILLING_PAYMENT_CONFIG_ENCRYPT_KEY=***
BILLING_WECHAT_NOTIFY_URL=https://APP_DOMAIN/api/billing/payment/notify/wechat
BILLING_ALIPAY_NOTIFY_URL=https://APP_DOMAIN/api/billing/payment/notify/alipay相应商户配置包含 App ID、商户号、私钥/API v3 Key、证书序列号或支付宝公钥。它们只应由 Billing Service 使用。
路由预检
验证域名、TLS 与 Nginx 能把通知路径路由到 Gateway。部分通道用 GET 探测时可能返回 405，这不代表路由不可达；真正的验收以支付服务发送的签名 POST 回调、Billing Service 日志和订单状态为准。
第三步：创建并支付订单
- 以测试用户登录客户端，打开套餐或积分页面。
- 选择已记录的测试商品与目标支付渠道。
- 点击支付后，记录客户端显示的订单号；不要刷新页面重复创建订单。
- 在支付渠道完成测试支付，保存渠道交易号。
- 回到客户端订单页，等待状态从待支付变为已支付/已完成。
第四步：四层验收
A. 用户侧订单
- 订单号、商品、金额、支付渠道与操作前记录一致。
- 页面不会因刷新创建第二笔相同订单。
- 成功状态只在回调处理完成后显示。
B. 管理后台订单与流水
- 订单中心：订单状态、分类、用户、金额正确。
- 支付流水：能看到渠道流水号与支付状态。
- 同一个商户流水不会产生多条权益履约记录。
C. 权益/积分
- 测试用户余额或会员有效期与商品期望完全匹配。
- 再次刷新或模拟重复回调后，权益不重复增加。
- 若订单失败、取消或金额不符，权益不得发放。
D. 服务端日志
- Billing Service 收到通知后记录必要的订单标识与处理结果。
- 日志不出现私钥、完整签名原文、API Key 或银行卡/个人敏感信息。
- 验签失败、订单号不匹配、币种/金额不匹配会被拒绝，并有可定位的错误记录。
第五步：幂等测试
支付回调可能因网络重试而多次到达。验收人员不应通过“手动改订单状态”测试，而应在测试环境模拟或重复发送同一合法回调。预期：
- 首次回调完成支付状态更新与权益履约。
- 第二次同一订单回调被安全识别为已处理。
- 订单、支付流水和积分账本仍各自保持一条正确业务结果。
异常处置矩阵
| 症状 | 优先检查 | 处理方向 |
|---|---|---|
| 支付页无法打开 | 商品、支付开关、客户端请求 | 检查商品状态、Billing Service 与渠道配置。 |
| 支付成功但订单待支付 | 回调路径、TLS、Nginx、Gateway 日志 | 修复路由/证书后让渠道重试或按通道流程补发回调。 |
| 订单已支付但权益未到账 | Billing Service、账本、履约日志 | 检查履约事务与错误，不手工改余额。 |
| 金额不一致 | 商品价格、订单参数、商户回调 | 停止该商品，核对各层金额配置。 |
| 重复到账 | 回调幂等键、订单状态机 | 立即停止通道，修复后用账本和订单审计处理。 |