通知地址差异化处理,
- 每笔交易发给渠道方的通知地址都不一样
- url不能包含敏感数据,如自增id,而且通过加密混淆来保证URL不容易被模仿
接收到通知请求后,
api层:
- 验证IP白名单
- 验证请求url的合法性
渠道层:
- 严格对请求参数做非空校验(比如,某渠道文档说明了在通知时传递支付金额,那么,当某次通知的参数里没有支付金额时,就认定是非法通知;某渠道文档说明了在通知时传递支付账号,那么,当某次通知的参数里没有支付账号时,就认定是非法通知)
- 数据的合法性校验,如金额必须为数值
Service层:
- 支付单是否存在
- 验证当前支付状态,如果是终态,则终止处理
- 如果渠道有如下请求参数:
-
- 验证支付金额是否一致
- 支付账号是否匹配
- 验证请求url的合法性(如果某渠道定义了特定的url规则)
- 对于扫码支付:验证通知时间 如果在支付时间的24小时之后,则认定为非法通知(如果是其他支付方式,需另做相关控制)
- 验证支付完成时间 如果早于支付时间,则认定为非法通知
————————————————————–我是萌萌哒分界线————————————————————
【PDCA】
程序上线后,经过监控,在时间验证方面数次发现,渠道方的通知报文里的支付完成时间早于我方的支付发起时间!经进一步分析得知,两组时间的差异均在5秒之内,不难推断出,这是双方服务器时间不一致导致的,事实上也往往无法保证两台服务器的时间完全一致。 所以,需要对时间验证做完善,设置一个阈值,比如2分钟,支付完成时间不能早于支付时间减去这个阈值。这样,就可以兼容这种实际情况下的不一致。