支付结果通知的安全控制

通知地址差异化处理，

1. 每笔交易发给渠道方的通知地址都不一样
2. url不能包含敏感数据，如自增id，而且通过加密混淆来保证URL不容易被模仿

 

 

接收到通知请求后，

api层：

1. 验证IP白名单
2. 验证请求url的合法性

渠道层：

1. 严格对请求参数做非空校验（比如，某渠道文档说明了在通知时传递支付金额，那么，当某次通知的参数里没有支付金额时，就认定是非法通知；某渠道文档说明了在通知时传递支付账号，那么，当某次通知的参数里没有支付账号时，就认定是非法通知）
2. 数据的合法性校验，如金额必须为数值

Service层：

1. 支付单是否存在
2. 验证当前支付状态，如果是终态，则终止处理
3. 如果渠道有如下请求参数：

• • 　　验证支付金额是否一致
  • 　　支付账号是否匹配
  • 　　验证请求url的合法性（如果某渠道定义了特定的url规则）
  • 　　对于扫码支付：验证通知时间 如果在支付时间的24小时之后，则认定为非法通知（如果是其他支付方式，需另做相关控制）
  • 　　验证支付完成时间 如果早于支付时间，则认定为非法通知

 

————————————————————–我是萌萌哒分界线————————————————————

【PDCA】

程序上线后，经过监控，在时间验证方面数次发现，渠道方的通知报文里的支付完成时间早于我方的支付发起时间！经进一步分析得知，两组时间的差异均在5秒之内，不难推断出，这是双方服务器时间不一致导致的，事实上也往往无法保证两台服务器的时间完全一致。 所以，需要对时间验证做完善，设置一个阈值，比如2分钟，支付完成时间不能早于支付时间减去这个阈值。这样，就可以兼容这种实际情况下的不一致。

转载于:https://www.cnblogs.com/buguge/p/8480431.html