成人分类广告网站的PCI DSS合规:真正决定合规工作量的是什么

让支付服务商接受一个成人分类广告网站,本身就是一场硬仗,一旦打赢,几乎所有运营者都会以为最难的部分已经过去。事实并非如此。最终点头的账户,附带着一项持续的义务,这项义务与年龄验证、内容审核,或任何州法律、搜索引擎可能施加的规则都没有关系。这是一项由卡组织自己制定的安全标准,只要银行卡号触碰到业务的任何一个环节,不论业务规模多小,它就适用。

以下内容不是法律建议,真正接触到实际持卡人数据的一方,应当请Qualified Security Assessor审查具体情况。这是一个几乎没有运营者意识到自己正在做出的决定的雏形,因为做出这个决定的通常是想把支付页面做得更漂亮的开发者,而这个问题往往在传到公司的业务一方之前很久就已经被决定了。

你没读就签了的那条规则

PCI DSS,即支付卡行业数据安全标准,并非政府法规,也没有任何国家机构负责执法。它是一项写入合同的义务,存在于每个商户与收单银行或支付服务商签订的协议中,之所以存在,是因为Visa、万事达和其他卡组织要求各自的收单机构,将这项义务传递给任何存储、处理或传输银行卡号的企业。标准制定机构本身说得很明确:它适用于任何处理持卡人数据的实体,无论是直接处理还是通过第三方处理,不因规模或交易量而有任何例外。

这与支付服务商在同意为你开户之前提出的问题不同。支付服务商在同意与你合作之前想知道什么,问的是业务本身:谁拥有这家企业,广告如何审核,广告主如何核实身份。PCI DSS则是在账户已经存在之后才开始,而且实际上从不真正结束。只要业务还在接受银行卡,它就每年续期,而且每当接受银行卡的方式发生变化,它的形态也随之改变。

交易量确实有影响,但方式与人们通常想象的不同。它决定了商户的"级别",从一级到四级,而这个级别决定了合规如何被验证:小型运营者填写一份自评问卷,而每年处理数百万笔交易的企业则需要外部审计师。交易量不会做的一件事,是让任何人免除义务。一个每月只处理几百笔交易的高风险商户,和一家大型连锁企业遵循的是完全相同的底层标准,只是用一份更短的表格来验证而已。

决定你多年工作量的唯一一个决定

适用于某个具体业务的表格,并非可以自由选择。它完全由一个技术事实决定:银行卡号在流程中的某个环节,是否经过了运营者控制的系统。把客户引导到支付服务商托管的支付页面,或者嵌入一个由该服务商提供、正确隔离的支付iframe,银行卡号就永远不会触碰运营者自己的服务器。反之,构建一个收集银行卡号、并在转发之前先发送到运营者自己后端的支付表单,哪怕只是短暂经过,银行卡号就触碰到了。

仅这一个事实,就把最轻的问卷和最重的问卷区分开一个数量级。完全外包的路径,称为SAQ A,大约有二十项要求。运营者自己的页面提供或影响部分支付流程、即便不直接触碰银行卡号的路径,例如一个自行托管的表单、其字段将数据转发出去,则属于SAQ A-EP,接近两百项要求。真正在自己系统上存储、处理或传输银行卡数据的,则属于SAQ D,涵盖该标准的全套控制措施:加密、密钥管理、网络分段、访问日志记录、访问控制,所有这些,加起来达到几百项。

有一个常见的误解值得立刻澄清。使用一个符合标准的服务商提供的iframe,并不会自动把网站归入更重的SAQ A-EP级别:一个正确隔离的第三方iframe,只要运营者自己的页面没有加入任何能够看到或触碰支付字段的代码,通常仍然可以适用较轻的SAQ A路径。真正把业务推向更高级别的,是运营者自己的代码触及了那个页面,不论是自行搭建的表单、为"改善"支付体验而添加的脚本,还是那种由浏览器通过运营者自己编写的代码(而非支付服务商提供的代码)发送银行卡数据的老式集成方式。

从去年起,轻量路径仍然要求做什么

有一个曾经正确、如今已不再正确的看法,值得在此纠正。选择外包路径的运营者们正确地了解到,这让他们免于承担该标准的大部分技术负担,但有些人仍然以为这意味着完全不需要任何持续性的安全检查。自PCI DSS 4.0.1版本起,该版本自2025年4月起强制执行,情况已不再如此。SAQ A现在也包含一项要求:由Approved Scanning Vendor针对运营者自己的网站(即托管跳转或iframe的那个网站)执行每季度一次的外部漏洞扫描,即便这个网站本身从未看到过银行卡号。

这项变化背后的逻辑一旦说出来就很简单:把客户送往支付处理商的那个页面,依然是攻击面的一部分。一个被攻破的支付页面,可以把客户重定向到真正支付处理商以外的地方,或者加载一个恶意脚本,在iframe加载之前就直接从浏览器中读取银行卡数据,这种攻击模式已经真实地打击过一些商户。同样的逻辑还衍生出两项相关要求:运营者必须维护一份在支付页面上运行的每个脚本的清单,并检测该页面内容遭受的任何未经授权的更改,这些义务之所以在SAQ A中适用,正是因为支付页面属于运营者,即便银行卡号从未属于过运营者。

轻量路径仍然可以避免的,也是真正重要的差距所在,是SAQ A-EP和SAQ D所要求的年度渗透测试,以及这些级别所要求的深层内部控制:加密存储的银行卡数据、管理保护这些数据的密钥、围绕任何触碰这些数据的系统进行网络分段,并详细记录每一次访问。选择外包路径不意味着完全没有安全工作。它意味着每年只需几个小时的扫描和脚本清理,而不是围绕本应由自己存储的数据、建立一套常设的安全体系。

做错这件事要付出什么代价

这一切都不是由法院或监管机构强制执行的,这也是它容易被低估的部分原因。当某个商户不合规时,卡组织会对其所属的收单银行处以罚款,而收单机构会通过合同直接把这笔成本转嫁给商户,通常从一个较低的金额开始,随着不合规状态持续的时间越长而不断上升。没有任何公开表格为每家收单机构规定这些具体金额,因为这项安排存在于私人合同之中,而非公开规则之中,但方向是一致的:罚款会随时间增长,而不是取决于企业把延迟解释得多么合理。

这只是单纯不合规的代价。真正的数据泄露,即存储的银行卡号因运营者处理了SAQ A本应帮他避免处理的数据而被暴露,则是完全另一个量级的支出。在任何人被允许重新开启账户之前,卡组织可以要求一家专业公司进行法务调查,费用无论结果如何都由商户承担,受影响的银行卡也会以商户的费用重新签发。网络责任保险很少能填补这样一家企业面临的这类缺口,因为成人内容出现在不止一家大型保险公司网络保单的除外行业名单上,这意味着这里所描述的风险敞口往往根本没有保险覆盖,而不仅仅是费用高昂。

最持久的后果既不是罚款,也不是调查本身。而是一旦某次数据泄露或长期不合规被记录在案,收单机构做出的决定:关闭账户,而不是继续承担这项风险,并以其他收单机构在开设新账户之前就能看到的方式,记录下这次关闭。第一次花了数月才建立起来的支付合作关系,一旦带上这样的历史记录,想要重新建立起来会困难得多。

这个月该做什么

先以书面形式弄清楚今天真正适用的是哪一份问卷。直接向支付服务商询问,而不是自行假设答案:确认当前的支付方式是跳转、正确隔离的iframe,还是在流程的某个环节触碰了运营者自己服务器的方式,因为这个问题的答案,一句话就概括了整个合规方案。要通过邮件获得这个答案,而不是电话,因为它是之后每一个决定的参考依据。

把任何想要改变收卡方式的请求,首先当作合规问题来对待,其次才是设计问题。一个想要构建定制支付表单的开发者,理由是托管页面看起来太普通,或者在托管支付iframe的同一页面上添加聊天窗口或分析脚本的开发者,实际上正在做出一个PCI相关的决定,不管有没有人把它说成是这样。这类改动应当在上线前审查,而不是等到扫描发现问题之后。

按时提交年度合规声明,并保留每一次季度扫描的结果,哪怕是那些什么都没变化的、乏味的扫描记录,因为在收单机构眼中,过期的合规声明和从未提交过没有任何区别。只要底层架构选对了,这一切都不难。一开始就围绕托管页面或正确隔离的iframe搭建起来的支付流程,能把这一切变成每年重复一次、只需一个下午的文书工作。而一个悄悄养成触碰银行卡数据习惯的支付流程,则会把同样的义务变成一套企业从未打算运营的常设安全体系。