应用开发者的 PCI 合规指南：简短而痛苦的版本
如果银行卡数据曾接触过您编写的代码，您就必须承担 PCI DSS 的全部重量。本文介绍了从 SAQ A 到 SAQ D 的升级阶梯、为什么面对面支付需要经过认证的硬件，以及如何通过架构设计避免承担这些责任。
Mathias NielsenCEO, Final POS
PCI 合规（即支付卡行业针对处理卡数据的任何人制定的安全规则）是使用“支持信用卡支付”这句话的代价。简而言之：如果卡数据曾经接触过您编写的代码或运行的服务器，您就会继承一项包含数百项控制措施的安全标准、年度签署声明（证明您符合标准的正式签署声明），以及通过您的支付处理商带来的后果。对应用开发者而言，PCI 合规令人头疼的地方在于：大多数人都是在结账功能已经构建完成后才发现这一点的。
在进入细节前先说明一点。以下的版本号、日期和问卷规则截至本文发布时是准确的；但该标准会不断更新，因此请将这些细节视为当时情况的快照。
PCI 合规到底是什么？
PCI DSS（支付卡行业数据安全标准）是一项合同义务，而非法律。卡组织将其施加给银行和支付处理商，再由他们施加给商家以及商家运行的软件。当前版本为 4.0.1，其最新一轮的新要求已于 2025 年 3 月 31 日成为强制性要求¹。该标准涵盖 12 个要求大类，从网络安全和加密到访问控制和日志记录，进一步细分为数百个具体的控制项²。
不会有监管人员登门检查。后果是通过商业途径传导的：通过您的收单银行（为商家结算刷卡支付的银行）下发的罚款、更高的处理费率，最坏的情况下则是彻底失去接受刷卡支付的能力。发生数据泄露后，司法鉴定调查和重新发卡的成本也会沿着同样的路径由您承担。
为什么“直接添加支付功能”会让您的整个应用都纳入合规范围？
合规范围（Scope）是整个问题的核心。PCI DSS 适用于存储、处理或传输持卡人数据的每一个系统，以及与这些系统连接的所有内容。合规验证就像爬梯子，每一级都比上一级沉重得多²：
SAQ A（自我评估问卷 A）：支付完全外包给符合合规要求的提供商，卡数据绝不接触您的系统。这是最简短的问卷。
SAQ A-EP：您的网站绝不接触卡数据，但控制着客户如何到达支付表单。此时完整标准中的很大一部分已开始适用于您的 Web 服务器。
SAQ D：卡数据经过您构建的任何内容，即使是暂时的、未经存储的。这实际上意味着整个标准都需要每年进行文档化和签署确认。
最低的那一级也并不意味着“毫无要求”。2025 年 1 月，PCI 安全标准理事会虽然从 SAQ A 中移除了支付页面脚本要求，但增加了一项资格条件：您必须确认您的网站不易受到可能影响电子商务系统的脚本攻击¹。即使是完全外包的层级，也要求您能够防护托管他人支付表单的页面。
每年处理的刷卡交易超过 600 万笔后，自我评估将彻底结束，由 QSA（认证的外部评估员）进行的现场审计将随之开始²。
您能通过编写代码绕过面对面支付的限制吗？
不能。面对面支付是梯子变成高墙的地方。面对面交易需要经过认证的硬件：通过了理事会 PTS 实验室项目认证的物理读卡器，运行着经过批准的固件，并通过支付处理商进行配置。仅靠软件将手机变成读卡器属于另一项标准 Mobile Payments on COTS (MPoC) 的范畴，且它认证的是解决方案提供商，而非您自行构建的产品。
这是 AI 代码生成无法逾越的边界。模型可以在半天内生成一个有说服力的结账界面；你能用 Lovable 或 Replit 构建 POS 吗？ 和 氛围编码（Vibe Coding）POS 系统 梳理了这些构建陷入停滞的节点。没有生成的代码能凭空产生经过认证的读卡器、收单协议或合规签署声明，无论模型在无人监督的情况下编码多久。合规性也是氛围编码的支付应用被 App Store 拒绝的常见原因。
开发者实际上如何缩小 PCI 合规范围？
答案不是更硬核地去满足合规要求，而是通过架构设计减少需要合规的内容：
绝不要让 PAN（主账号，即卡号本身）接触您的代码。使用处理商托管的支付字段，使卡数据直接从客户的浏览器传输到处理商。
存储 Token（令牌），而非卡号。标记化（将卡号替换为即使被盗也毫无价值的引用字符串）可以防止保存的卡号和退款操作将您的数据库拖入合规范围。
对于面对面销售，请使用处理商提供的经过认证的读卡器，以便卡数据直接从读卡器流向处理商，而不经过您的应用。
保持支付页面简单干净。页面上的每一个第三方脚本都会变成您必须为此负责的内容。
如果设计得当，您的应用只需协调销售流程而无需拥有任何卡数据，评估问卷也会保持简短。如果设计失误，某项便利功能（比如“记录完整的请求体”）就会静悄悄地将您推向 SAQ D。
那么，PCI 合规对应用开发者而言究竟有多痛苦？
痛苦程度取决于您的代码接触了多少卡数据，这就是为什么最明智的做法是完全不接触。标准并不关心应用是由开发团队编写的，还是由 AI 在半天内生成的；范围就是范围。在发布任何支持刷卡支付的产品之前，请先问一个问题：卡号是否有可能经过我编写的代码？如果是，请准备好审计预算。如果否，请继续保持。
这同样也是 Final 处理合规问题的架构逻辑。基于 Final 构建的结账流程，无论是在 Build 中通过提示词生成，还是由您自己的 AI 通过 MCP 构建，其支付均通过 Final Pay 运行：由支付处理商和经过认证的终端硬件处理卡数据，因此流程本身绝不持有卡号。Final Pay 的可用地区涵盖了实用层面的说明，而将 Tap to Pay 连接到 AI POS 流程则展示了在合规层已经完备的前提下，刷卡支付是如何实现的。
常见问题
PCI 合规是法律强制要求吗？
不是。PCI DSS 是卡组织通过银行和支付处理商施加的合同义务。其后果是商业性质的：通过您的收单银行下发的罚款、更高的处理费率，或者失去接受刷卡支付的能力。
完全外包支付流程可以免除 PCI 义务吗？
不能。完全外包支付的商家可以使用最简短的问卷 SAQ A 进行验证，但自 2025 年 1 月修订以来，他们还必须确认其网站不易受到可能影响电子商务系统的脚本攻击。
SAQ A 和 SAQ D 有什么区别？
当符合合规要求的第三方处理所有卡数据时，适用 SAQ A，它仅涵盖标准的一小部分。当卡数据接触您自己的系统时，适用 SAQ D，它实际上涵盖整个标准，且需每年进行签署确认。
AI 生成的应用可以符合 PCI 标准吗？
代码可以遵循安全模式，但合规性依附于企业及其基础设施：经过认证的读卡器、处理商协议和年度签署声明。生成代码无法提供这些组成部分。
当前的 PCI DSS 版本是什么？
截至本文发布时，当前版本为 PCI DSS 4.0.1。其最终的预留未来生效的要求已于 2025 年 3 月 31 日成为强制性要求。请访问 PCI 安全标准理事会网站了解最新状态。