PCI DSS 合规实务：收卡业务的合规范围、SAQ 选型与成本控制

PCI DSS 合规实务：收卡业务的合规范围、SAQ 选型与成本控制

PCI DSS 是卡组织通过合同强制推行的行业标准，由 PCI 安全标准委员会（PCI SSC）维护。它不看你公司多大，只看两件事：你有没有接触持卡人数据，以及你的系统有没有能力影响这些数据的安全。本文按"范围、等级、问卷、架构、要求、令牌化、反模式、落地"八个部分展开。具体条款与验证口径以 PCI DSS 当前版本（主流为 v4.0.x）原文与签约收单机构的最新要求为准。

很多团队把合规理解成"要不要做渗透测试"的采购问题，实际上它是一个架构问题。收银台形态选错了，合规范围会被无谓放大，之后每年填表、审计、整改的成本都会成倍增加。反过来，架构选对，很多工作在源头就不必发生。

一、PCI DSS 到底管什么

PCI DSS 的适用对象不是"支付公司"，而是所有存储、处理或传输持卡人数据的主体，以及那些虽然没有直接接触卡数据、但系统一旦被攻破就会影响卡数据安全的实体。

关键词是"影响"。一个纯展示型商品站，收银台整页跳转到服务商域名，卡号从未进入你的服务器，你的合规范围就很小。但如果收银台页面由你的服务器渲染，即使卡号是通过浏览器脚本直接提交给服务商的，你的页面仍然有能力被篡改以窃取或替换卡号，于是合规范围就被拉大了。

所以判断范围的正确定序是：先画数据流图，看卡数据经过哪些系统、哪些系统有能力影响这些数据的完整性，而不是先看交易量。交易量决定的是合规等级和验证方式，它不决定范围。把这两件事混在一起，是最常见的认知错误。

二、四个合规等级与适用范围

PCI DSS 把受约束主体划分为四个等级，等级的判定维度主要有三个：年度交易规模、受理渠道（线上还是线下），以及你的角色是商户还是服务提供商。具体分档口径由各家卡组织与收单机构在商户合同中约定，不同收单机构的细节可能略有差异，本文不列具体数值，请以签约机构的最新商户手册为准。

等级影响两件事：验证方式的严格程度，以及是否需要外部评估机构介入。对绝大多数建站团队来说，实际落在三级或四级区间，走的是自评问卷路线，成本主要花在架构改造与填表上，而不是审计费。这也是为什么"改架构"比"多请一个顾问"更省钱：等级和范围都被架构决定，而架构是你自己能控制的变量。

三、SAQ 类型怎么选

SAQ 是自评问卷，按业务形态分为多种。收卡业务最常遇到的是 SAQ A、SAQ A-EP 和 SAQ D 三档。选错档位的后果很直接：选低了属于申报不实，选高了等于白背一堆不必要的控制要求。

3.1 SAQ A 的适用条件

适用前提是卡数据完全不进入、不经过、不驻留于你的系统与环境，收银环节完全由符合 PCI DSS 的服务商页面承担，典型形态是整页跳转或全托管表单。条件满足时，问卷条目最少，需要落实的主要是安全政策、外包服务商管理，以及确保那张支付页面没有受到你自己插入的脚本污染。注意"外包服务商管理"不是走过场：你需要保留服务商的合规证明，并确认其覆盖范围包含你使用的产品。

3.2 SAQ A-EP 的适用条件

适用于电商场景：你的网站虽然不直接接收卡号，但你的页面通过脚本或 iframe 与支付服务商接口交互，因此页面一旦被篡改，就可能改变交易内容或劫持卡号输入。此时问卷条目显著增加，重点落在支付页面的完整性监控、脚本来源管理、变更控制和第三方脚本审查上。很多团队以为自己"没碰卡号所以是 A"，实际上因为自建表单直连 API 而落在 A-EP。

3.3 SAQ D 与前两者的分界

只要卡号在你的服务器、数据库、缓存、日志或内存中以任何形式出现过，就不属于 A 或 A-EP，而落入 SAQ D 的范畴（商户版与服务商版不同）。SAQ D 是条目最全的一档，覆盖全部 12 项要求，工作量与 A 档不在一个量级。合规成本失控，几乎都发生在从 A 滑到 D 这一步。

判断口诀只有一句：卡号有没有落到你能控制的地方。落了，就是 D；没落，再看你的页面是否有能力影响交易的完整性，有就是 A-EP，没有才是 A。

四、四种收银台架构的合规负担对比

架构决定了范围，范围决定了问卷，问卷决定了一年要投入多少人天。下表把四种常见形态放在一起对比，卡数据接触点一列是判断的核心。

4.1 托管收银台跳转

整页跳转是最省事的方案：用户离开你的域名，进入服务商的收银页面完成支付，回跳时带回结果。卡号全程不经过你的系统，SAQ 走 A 档，年审工作量最小。代价是品牌一致性和转化率：部分用户对跳转到陌生域名有心理门槛，移动端跳转链路也可能出现返回丢失。可用自定义域名与预填能力缓解，具体支持程度因服务商而异。

4.2 iframe 内嵌

iframe 内嵌在保持页面观感的同时把卡号隔离在服务商域内。这类方案仍在 SAQ A 的射程内，但前提是你对父页面加载的所有脚本有清单和完整性控制，因为父页面脚本理论上能读到 iframe 的行为特征甚至覆盖输入焦点。实务上要避免在收银页挂载任何不必要的统计、客服、A/B 测试脚本。

4.3 自建表单直连 API

用服务商的令牌化字段组件（由服务商脚本生成输入框，卡号直接提交到服务商接口）是目前最常见的折中方案：视觉与交互完全自控，卡号不落地。但页面对交易的影响能力依旧存在，因此多数情况下按 A-EP 处理，需要落实脚本完整性监控与变更审批。如果团队没有前端安全维护能力，这一档反而是最容易被审计挑出问题的。

4.4 卡数据落到自有服务器

自建表单把卡号 POST 到自己的后端，再转发给服务商，或者在本地解密、记录、做风控后再提交，是最昂贵的选择：完整落入 SAQ D，需要加密传输、密钥管理、访问控制、日志脱敏、分段隔离、季度扫描与年度渗透测试等一整套要求。除非你有明确的业务理由（例如线下收单、特殊的收单直连协议），否则不应选择这条路。已经在这条路上的团队，优先目标应该是"把卡号移出去"，而不是"把 SAQ D 填得更好看"。

五、12 项要求里对建站团队真正有影响的

12 项要求覆盖网络安全控制、安全配置、持卡人数据保护、传输加密、恶意软件防护、安全开发、访问控制、身份识别、物理安全、日志与监控、安全测试、安全政策。对建站团队而言，真正会反复遇到、也最容易做错的集中在下面两块。

5.1 网络分段与最小暴露面

分段的目的不是"把网络切得好看"，而是把卡数据环境从其他系统里切出来，从而缩小范围。可行做法包括：把接收卡数据的服务单独部署在最小化加固的主机上，限制出入站连接，避免与内容管理、营销、数据分析系统共用主机与数据库。对走托管收银台的团队，这一项几乎自动满足；对走了自建中转的团队，这一项往往是最难补齐的。

5.2 日志、变更控制与年度复审

日志要求关注三点：记录关键事件、保护日志不被篡改、按要求保留期限。变更控制要求所有影响卡数据环境的改动有审批记录与测试证据。最容易被忽略的是复审：通过认证不等于持续符合，标准按年度周期要求重新验证，中间出现架构变更、服务商更换、新增支付方式时，范围与问卷都可能需要重新评估。

六、令牌化如何缩小合规范围

令牌化把卡号替换成一段无意义的令牌，令牌可以长期保存、可以用于订阅扣款与退款，但本身不携带可还原的卡号信息（除非你在自己的系统里做了可逆映射，那就等于又把它变回了敏感数据）。网关令牌通常绑定单一服务商，跨服务商迁移时需要重新收单；网络令牌由卡组织体系签发，可跨收单机构使用，也能在卡号更新时自动同步，适合订阅类业务。

令牌化对合规的真正价值在于：它让你在数据库、客服后台、对账系统里都不必出现卡号，从而把这些系统的合规范围剥离开。但它不能免除全部义务。如果你在令牌化之前就已经接收并处理过卡号，那一段流程仍然在范围内；如果你的页面能影响令牌化过程，A-EP 的要求也依然适用。令牌化是缩小范围的工具，不是免责工具。

七、五个常见的不合规做法

做法一：把卡号写进日志或数据库用于排障。 最常见的自伤行为，一次排障可能就把整条数据流带进 SAQ D 的范围，而且日志往往缺乏加密与访问控制。

做法二：自建表单收集卡号后"转发"给服务商。 看起来只是做了一层代理，实际上卡号完整经过自有服务器内存与网络，范围瞬间放大。

做法三：把支付页面外包给第三方脚本，却不做完整性监控。 页面被注入了什么脚本没人知道，A-EP 的核心控制项形同虚设。

做法四：只做一次合规，之后不再复审。 改版、换服务商、加支付方式都可能改变范围，不重新评估等于合规状态已经失效。

做法五：用共享账号或个人设备处理退款与卡数据查询。 访问控制与身份识别是 12 项要求里的硬性条款，共享凭据在审计中几乎必然被判定不符合。

八、实施路径与上线检查清单

8.1 分阶段实施路径

第一阶段画清楚数据流：列出所有涉及支付的系统、服务商、第三方脚本，标注卡号经过的每一跳。第二阶段降范围：能跳转就跳转，能内嵌就内嵌，能令牌化就令牌化，把卡号从自有系统里赶出去。第三阶段补齐控制：针对选定的 SAQ 档位逐条落实，优先做加密、访问控制、日志与变更控制。第四阶段填表并留证：每一项控制都要有可出示的证据，而不是一句"我们已经做了"。第五阶段建立年度复审机制，把范围变更纳入需求评审流程。

上线前逐条自查：

1. 收银台是否已确认架构形态与对应 SAQ 档位，并有书面结论；
2. 卡号是否从未写入自有日志、数据库、缓存与监控系统；
3. 收银页面加载的第三方脚本是否有完整清单与用途说明；
4. 服务商的合规证明是否在有效期内，覆盖范围是否包含所用产品；
5. 生产与测试环境是否使用不同的凭据，测试数据是否已脱敏；
6. 敏感配置与密钥是否与代码分离存放并有访问记录；
7. 退款、查询、对账等高权限操作是否按最小权限授权；
8. 是否建立了范围变更的触发机制（新增支付方式、更换服务商、改版收银台）；
9. 年度复审的负责人与时间点是否已经落到日历上；
10. 事故响应预案中是否包含卡数据泄露的通报路径。

支付欺诈与风控策略可参考 支付欺诈防范策略，拒付举证与原因码见 拒付原因码与举证手册，上线前的联调方法见 支付网关沙箱测试，资质与备案要求见 支付合规与备案资质指南。常见收银台方案可对比 Stripe、Adyen、Checkout.com 与 Braintree，欧洲本地化可参考 Mollie，国内场景可看 支付宝。更多支付方案可参见 支付 分类。

来源：16IDC 原创，文中涉及的产品能力、费率与准入要求以相关服务商官网文档及合同为准。