如何解决第三方的支付安全问题

去年一家做跨境电商的何解客户找到我们，说他们的决第支付接口被人刷了。不是支付那种大规模的数据泄露，就是安全有人拿着几百张盗来的信用卡，在他们的问题收银台上反复测试小额交易。每笔就几美元，何解但架不住量大，决第三天时间损失了近两万美金，支付还搭进去一笔不小的安全拒付罚款。他们的问题技术负责人跟我说了一句话：“我们自己的代码没问题，但支付网关那边……谁知道呢。何解”

这话点到了要害。决第第三方支付的支付安全问题，从来不只是安全“第三方”的事。你接入了别人的问题服务，但风险是双方共担的。很多时候，问题出在衔接处——那些你以为对方会处理、对方以为你会处理的地方。

先搞清楚你接的到底是什么

市面上常见的第三方支付接入方式有好几种：跳转收银台、iframe嵌入、API直连、SDK集成。每种的安全边界完全不一样。跳转收银台最省事，卡号密码都在人家页面上输，你碰不到敏感数据，PCI DSS合规压力小。但问题是，用户信任的是你的品牌，跳出去那一下如果体验割裂，转化率掉得厉害。API直连最灵活，但卡号要经过你的服务器，哪怕只是转发一下，合规要求立刻上一个台阶。

我见过不少团队为了省事选了API直连，结果服务器日志里明文记着卡号后四位和过期时间。问起来就说“我们没存完整卡号”。但PCI DSS的要求是，只要你的系统接触过卡数据，哪怕只是内存里过一遍，就得按标准来。这不是第三方能替你兜底的。

令牌化不是万能药，但没它万万不能

令牌化（Tokenization）现在基本是标配了。支付网关把卡号换成一串无意义的令牌，你的系统只存令牌，后续扣款、退款都用令牌去换。这样即使你的数据库被拖了，拿到的也是一堆废字符串。但令牌化有个坑：不同网关的令牌不互通。你换了支付服务商，老令牌可能就废了，用户得重新绑卡。有些团队为了“平滑迁移”，自己搞了一套映射表，把老令牌和新令牌对应起来存——这等于把令牌化的好处又还回去了。

我的建议是，如果业务允许，尽量用支付网关提供的“网络令牌”或“跨网关令牌”方案。Visa和Mastercard都有类似的互通标准。虽然接入麻烦点，但长远看省事。

Webhook是攻击面，不是通知栏

第三方支付的回调通知，很多开发者只当成“支付成功了，改一下订单状态”的信号。但Webhook本身就是一个公开的HTTP端点，谁都能往里发请求。如果你不验证签名，攻击者伪造一个“支付成功”的回调，你的系统就发货了。这种事我亲眼见过，一家做SaaS的，被人用伪造回调白嫖了半年服务，直到对账才发现。

验证签名是最基本的。但签名算法也有讲究，有些网关用的是HMAC-SHA256，有些还在用MD5。MD5不是不能用，但得确保密钥够长、够随机，而且绝对不能硬编码在客户端代码里。另外，回调处理最好做成幂等的——同一个通知可能被重复发送，你的逻辑得能扛住。

对账不是财务的事，是安全的事

很多团队把对账完全交给财务部门，技术侧只负责“支付成功”和“退款成功”两个状态。但支付安全里，对账是最早发现异常的手段。比如你发现某天凌晨三点到四点之间，有大量金额相同、卡bin相同的交易，每笔都成功，但对应的用户账号都是新注册的——这基本就是盗卡测试。如果技术侧不参与对账，这种模式根本不会进入开发者的视野。

我习惯建议客户做一个简单的实时监控：同一IP短时间内的支付尝试次数、同一卡bin的失败率、新账号首单金额分布。不用多复杂，几个阈值告警就能拦住大部分低级攻击。

别把鸡蛋放在一个篮子里，但篮子多了也麻烦

有些公司为了分散风险，同时接了三四个支付网关。想法是好的，但实现起来容易出问题。我见过一个系统，主网关失败就自动切备用网关，结果因为重试逻辑没写好，同一笔订单在两个网关都扣了款。用户被扣了两次，客服那边还查不到原因——因为两个网关的订单号体系不一样。

多网关的核心不是“多”，而是“路由和状态同步”。你得有一个统一的支付状态机，所有网关的回调都映射到同一套状态里。切换网关的时候，先查状态，再决定要不要发起新请求。这事说起来简单，做起来全是细节。

第三方支付的安全，说到底是在“信任别人”和“控制自己”之间找平衡。你不可能审查支付网关的每一行代码，但你可以控制自己怎么接、怎么验、怎么记、怎么对。那些出事的案例，十有八九不是网关被攻破了，而是接入方在某个环节上想当然了。