顽兔支付

联调与上线

验证方式

顽兔不设独立联调环境，接入验证直接在生产完成。开发阶段用正式凭据随意下单调试， 不产生任何费用——不支付的订单超时自动关闭；到验证支付链路这一步，真实付 0.01 元， 验完调退款把钱收回。

base_url 与凭据放环境变量或配置中心，不要写死在代码里：

Node.js
Python
Go
Java
const pay = new WantuPayClient({
  base_url: process.env.WANTU_PAY_BASE_URL!,     // https://pay-api.wantutech.com
  merchant_id: process.env.WANTU_MERCHANT_ID!,
  api_secret: process.env.WANTU_API_SECRET!,
})

本地调试回调

回调地址需要公网可达。本地开发时用内网穿透工具，把生成的公网地址填到商户后台「接入配置 → 支付回调」，点「保存配置」：网关会先向这个地址发一条 webhook.ping 测试回调，收到 2xx 才生效，没通的话页面会说明原因（解析不了、连不上、返回了什么状态码）。穿透地址变了自己改，想单独验一下，点地址旁边的「测试地址」，只发测试、不改配置。

收不到回调时的排查顺序：先调查单接口确认支付状态。状态是 paid 说明支付正常， 问题出在回调链路，再检查穿透工具和本地服务；状态不是 paid 说明支付本身没完成。

上线前用例

至少走一遍以下用例再上线：

  1. 下单，扫码支付，收到 order.paid 回调，订单入账
  2. 同一回调重复送达（可以重启本地服务触发重试），确认不会重复入账
  3. 下单后不支付，等待超时，查单确认状态为 closed
  4. 下单后不支付，调关闭订单接口，查单确认状态为 closed；再关一次仍返回 closed
  5. 退款：受理应答是 processing（退款需在商户后台审批），到商户后台批准后确认收到 refund.succeeded 回调
  6. 停掉本地服务下单支付，恢复后确认回调补达或查单兜底生效
  7. 用「按单指定」回调的：每个站各下一单付掉，确认 order.paid 发到了各自的 notify_url； 再故意漏传一次 notify_url，确认下单直接被拒（40004），而不是发到别的地方

上线检查

项说明
回调地址在商户后台「接入配置 → 支付回调」把开发用的内网穿透地址换成生产服务的公网 HTTPS 地址，点「保存配置」，测试回调通了才生效
回调方式用「按单指定」的，把生产地址填进白名单再保存。保存时那条测试回调只说明地址通了，业务链路还得自己用小额真金走一遍；顽兔运营不会替你切换，也不会替你改白名单
密钥保管api_secret 在服务端配置或密钥管理服务中，不在代码仓库
幂等约束入账表对 out_trade_no 有数据库层面的唯一约束
金额核对入账前核对回调金额与订单金额
真实验证生产支付 0.01 元各验证一次：下单、支付、回调入账、退款。开了两条渠道的每条都验