在整笔交易里，卡号通常是暴露得最少的那样东西。现代支付流程就是专门设计成让商户根本看不到卡号的——在遵循这套模式的平台上，就算整个站被脱库，也拿不出一份能用的卡号库。

商户手里真正握着的是其余的一切：你注册用的邮箱、跟卡绑在一起的姓名和邮编、你连上来的 IP 地址，以及一份你看了什么、买了什么的逐项记录。对多数读到这里的人来说，第二类才是真正的风险，而它恰恰是被讨论得最少的。

到底有谁碰得到你的卡号？

三到五方，其中只有一方是你正在看的这个网站。

参与方 角色 看得到完整卡号吗？
商户（网站本身） 卖订阅、定价格 流程搭得对的话看不到
支付服务商 渲染卡片表单、把卡号令牌化 看得到——这就是它的职能
收单行 持有商户的账户、路由交易 传输途中经手
卡组织 在收单行与发卡行之间路由授权 传输途中经手
发卡行 你的银行，批准或拒绝 看得到——卡是它发的

整套安排的设计目标，就是把商户排除在这份名单之外。由支付服务商托管的表单，回给商户的是一个令牌——一个可以再次扣款、但对别人一文不值的凭据，因为它只在那家商户配那家支付服务商时才管用。

有两个能观察到的迹象说明事情正是这样在走：卡号字段位于一个来自与页面不同域名的 iframe 里，或者点「订阅」之后你被整个带到一个支付域名上。这两点都不能证明做法就一定好，但它们的缺席——卡片表单直接提交到网站自己的域名——是个有分量的负面信号。

从外部你到底能验证什么？

比你希望的要少，这一点值得直说，而不是暗示有个清单就能盖棺定论。

平台的存储做法、留存期限、内部访问控制，你在外面都审不了。你能观察到的是：

  • 卡片表单是从哪儿加载的。 查看页面源码或用开发者工具，看那些输入框是不是属于一个第三方框架。
  • 有没有出现加强验证。 被跳转到你银行自己的验证页面，说明这笔交易走了 3-D Secure，这会转移欺诈责任，也说明商户走在主流的收单路径上。
  • 有没有点名一个真实的法律实体。 条款页和账务页上写明公司、司法辖区和地址，是个弱的正面信号；账务页上谁都没写，则是个强的负面信号。
  • 隐私政策有没有写出留存期限。 政策写得含糊很常见；什么都不写的政策，本身就是一个关于数据被怎么对待的信号。
  • 取消是不是自助的。 要求发邮件才能取消的平台，往往也就是那些账务卫生整体很差的。

实际的风险类别有哪些？

把它们分开很要紧，因为对应的防守不同，而且最糟的风险并不是那个显而易见的。

风险 它长什么样 什么能降低它
卡号被盗 卡上出现欺诈扣款 支付服务商托管的表单；给订阅专用一个卡号
商户数据泄露 邮箱、姓名、消费记录被曝光 一个专用的邮箱别名；把资料填到最少
描述符曝光 共用的账单上冒出一行意料之外的记录 订阅前先知道描述符是什么；用一个单独的账户
不想要的周期扣款 你以为已经取消了，扣款还在继续 设消费上限；把取消确认留存下来
聚合商再扣款 一笔来自你不认识的名字的扣款 看清条款里写的收款方是哪个实体
注册之后的钓鱼 模仿平台账务通知的邮件 绝不从邮件链接里重新输入卡片信息

大家会漏掉的一个相关性：支付卫生最差的站点，通常也是数据卫生最差的，因为这两者反映的是同一件事——这家运营方是被主流支付服务商接纳了，还是只能绕着它搭。

为什么出问题最多的偏偏是周期扣款？

因为订阅和银行卡是两个各自独立的对象，取消其中一个不会取消另一个。

一个存起来的令牌，只要商户不停扣，就能一直扣下去。如果你只是关掉账号页面就当作取消了，而订阅记录还活着，扣款就会继续。反过来，如果你把卡废掉、订阅却留着不动，扣款是失败了，但合同义务可能还在，而有些商户会把欠款转给催收。

可靠的顺序是：先在账号内部取消，把确认页面或确认邮件留好，然后再考虑弃用那个卡号。到下一个计费日去核实，而不是想当然。

泄露事件公布之后，你该做什么？

卡片被暴露和数据被暴露需要不同的应对，而通常需要留神的是后者。

对卡片：联系发卡行，申请换一个新卡号。有争议的扣款一般是可以申诉的，不过时限和具体规则要看你的发卡行、你的卡组织和你所在的国家——去问他们，别想当然。

对数据：改掉这个账号的密码，以及任何复用过这个密码的地方；预期会收到点名这家平台的定向钓鱼；对之后任何一封「安全通知」邮件都要比平时更怀疑，因为泄露公告之后，跟着来的就是仿冒公告。如果你用的那个邮箱在别处跟你的真实身份绑着，这层关联现在就存在于一份你控制不了的数据集里了，而且没有任何操作能撤销它——这正是「在你需要之前就先用一个专用别名」的理由。

相关问题