讲解PG/PP游戏钱包对接中异步回调（Webhook）的安全隐患。分享防重放攻击、防伪造通知、做幂等性校验的技术底线，保护游戏平台资金安全。
你在做转账钱包还是单一钱包对接？不管哪一种，都请先阅读总纲领防坑指南：《PG/PP/JILI开发全攻略：API对接防坑全记录与实战经验总结》。
等你在回调里跌倒，那就是几十万的真金白银
只要你的系统开始承接玩家，你最怕的不是游戏跑不进，而是被人“刷分”。所谓刷分，最常见的一种技术手段就是“伪造Webhook回调”。黑客扫到了你们用于接收游戏服务器派奖通知的后端 URL，写个脚本，每分钟给你发送几十条假冒的“玩家中奖大奖 $10,000”的数据请求，如果你的服务器没有设防，玩家余额就会狂飙，老板只能抱着服务器哭。
防弹级资金系统的三大铁律：
1. 严格校验签名机制 (Signature Validation)
游戏厂发给你系统的数据包里通常会带一个 Sign 字段。绝大部分外包技术因为偷懒，直接判断 if(status == 'success') 就给玩家加钱。这是找死。收到数据后，你必须用同样的算法，拿着你保存在服务器里的秘钥重新按规则运算一次哈希值，去比对传过来的 Sign 是否一致。如果不一致，直接丢弃该请求并拉黑 IP。
2. IP白名单不仅是摆设
很多开发者在测试通过后，为了方便随时随地调试，把回调网关设为“允许任何IP访问” (0.0.0.0/0)。正确的做法是，在你的 Nginx 或 WAF 防火墙层面，死死卡住只有官方接口文档上提供的少数几个固定IP网段，才能访问你的 /api/callback 路由。
3. 防重放与幂等性校验 (Idempotency)
网络卡顿的时候，游戏厂商会在10秒内针对【同一笔派奖订单号】向你重发两三次通知。如果代码是原样入库执行，同一个订单就会被加两次钱！务必在数据库层面将游戏厂商的 Transaction ID 设为唯一索引 (Unique Key)。在加钱之前先查询，如果这笔订单号已经处理过，直接给厂商返回 HTTP 200 OK 让它别再发了，但绝不执行二次加钱逻辑。