支付系统安全设计思维导图

安全和稳定是三方支付系统的两个关键要素，系统开发要时刻紧绷这两根弦。今天我来简单分享一下安全这一块。先上图。

按上面思维导图来说，

服务器安全和网络是运维层面的，比如 DDos 攻击和流量攻击，必要时要采购防攻击设备或软件。

程序安全方面，首先程序代码包要混淆处理，以防泄露。程序实现方面，对外 API 接口涉及到鉴权（数字签名，通常用 RSA 非对称算法实现）和加解密。尤其要强调的是，对于入金交易，比如用户支付完成后，当接收到上游渠道的支付结果通知时，除了做必要的校验外，应该只处理支付“支付完成”的状态，对于包括“支付失败”在内的状态，都可不予处理。同样，对于出金交易，上游渠道通知我们是出款完成，没问题。如果告诉我们是失败，则一定要好好验证。因为一旦我们程序有疏忽将交易改为出款失败，那么，就会给商户重新发起出款带来可能，这样，如果前一单实际上也是出款成功，那么，这就造成了所谓的重复出款。 另外，程序一定要做好幂等和防重控制，以保证付款终态的处理逻辑执行且仅执行一次！再一点，程序留痕（用户会话数据、操作流水表）也是有必要的，这样方便追查问题和补偿。

数据安全方面，登录密码、支付密码等口令要加密存储（加盐加密更安全），注意要采用不可逆的方式。用户手机号、银行卡号、身份证号等要素属于敏感数据，要使用掩码进行脱敏处理。同样，程序日志里是严禁打印私钥或密码等信息的。

资金安全方面，聚合支付/三方支付系统必然触碰资金。而资金的风险常常发生于出款交易。上面也提到了，将一笔交易误改为出款成功大不了做一些撤回处理，而将一笔出款交易误改成出款失败就不仅仅是交“学费”那么简单了。结算处理也会诱发资金损失，我们遇到过结算读从库改主库结果因为主从复制延迟导致重复结算 7 次的事故。令很多开发团队头痛的是批付，很多场景并不那么容易 cover 到，程序总是在不断的趟雷踩坑过程中不断的完善的。系统监控要跟上，否则等到商户投诉的时候，你还在睡觉，那就迟了。

墨菲定律：Anything that can go wrong will go wrong. 谁也不能保证系统无 bug。记住，出 bug 阔以，但要可控。