开发指南
Webhook 简介
Webhook 是平台主动发到你的 HTTPS 端点的交易通知。一条 URL 接收全部事件；调用方向是“支付平台 → 你的业务后端”，不是你调用 {baseUrl}/notify。
每次 POST 只带一条通知：一个 type 配一个 status。原 14 种 type 与新增 withdrawal_rejected 按对应场景发出，但不会同时出现在一条正文里。phase 只有 progress，而且只出现在进度通知；充值确认和提现终态不返回 phase，也不存在 phase: terminal。查询状态不能套到通知上。进度只展示和记录，不入账、不确认扣款、不释放预扣。平台没有提现前的审批回调，也不会用充值失效通知代替查询。完整对照见事件类型。
重复、顺序和补偿
同一事件可能重复到达，多个事件可能乱序，部分中间状态可能没有通知。后到的旧进度不能覆盖已确认的终态。发送重试保留 eventId 和正文，刷新时间戳及签名；正确应答后仍可能再次收到，始终需要幂等处理。
| 通知类别 | 自动重试 | 接入方补偿 |
|---|---|---|
提现终态（含 withdrawal_rejected） | 已持久记录的事件累计 3 次确定投递失败后停止自动重试；前两次退避约 1 秒、2 秒 | 已受理订单用查询补偿；当前每日上限拒单查不到完整正文，须请平台核对拒绝及投递记录 |
| 充值通知、提现进度 | 已持久记录的事件持续尝试，没有相同的 3 次上限，待投递记录跨服务重启保留 | 使用充值对账、单笔复核和提现查询恢复状态 |
HTTP 发送尝试开始后的网络失败、发送超时、非 2xx、错误或缺失回签等确定失败消耗失败次数；DNS 解析失败或超时、发送前检查失败、配置暂停、缺少地址或凭据等发送阻塞，以及进程取消或尝试结果尚未确认而记录为“结果未知”的情况，不消耗该次数，条件恢复后仍需核实和重试。HTTP 发送尝试开始后的发送超时不能自行当作“结果未知”而免计失败；DNS 解析超时仍属于发送前阻塞。已持久记录的通知由独立发送任务处理，重启不会仅因源记录不再变化而丢失待投递事件；首次历史观察、升级前记录或源数据尚未同步仍可能有覆盖缺口，不承诺无限可靠投递。预期重复消息不会重复改账；长期未收到或反复收到时，先查你的端点日志、通知配置、回签和业务提交记录，再请平台查同步与投递情况，并通过查询补偿。