# 应用开发者的 PCI 合规指南：简短而痛苦的版本

> Published: 2026-07-28
> Updated: 2026-07-28
> Author: Mathias Nielsen
> Category: POS
> Canonical: https://finalpos.com/zh-Hans/blog/pci

如果银行卡数据曾接触过您编写的代码，您就必须承担 PCI DSS 的全部重量。本文介绍了从 SAQ A 到 SAQ D 的升级阶梯、为什么面对面支付需要经过认证的硬件，以及如何通过架构设计避免承担这些责任。

PCI 合规（即支付卡行业针对处理卡数据的任何人制定的安全规则）是使用“支持信用卡支付”这句话的代价。简而言之：如果卡数据曾经接触过您编写的代码或运行的服务器，您就会继承一项包含数百项控制措施的安全标准、年度签署声明（证明您符合标准的正式签署声明），以及通过您的支付处理商带来的后果。对应用开发者而言，PCI 合规令人头疼的地方在于：大多数人都是在结账功能已经构建完成后才发现这一点的。

在进入细节前先说明一点。以下的版本号、日期和问卷规则截至本文发布时是准确的；但该标准会不断更新，因此请将这些细节视为当时情况的快照。

## PCI 合规到底是什么？

PCI DSS（支付卡行业数据安全标准）是一项合同义务，而非法律。卡组织将其施加给银行和支付处理商，再由他们施加给商家以及商家运行的软件。当前版本为 4.0.1，其最新一轮的新要求已于 2025 年 3 月 31 日成为强制性要求[¹](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a)。该标准涵盖 12 个要求大类，从网络安全和加密到访问控制和日志记录，进一步细分为数百个具体的控制项[²](https://secureframe.com/blog/pci-saq)。

不会有监管人员登门检查。后果是通过商业途径传导的：通过您的收单银行（为商家结算刷卡支付的银行）下发的罚款、更高的处理费率，最坏的情况下则是彻底失去接受刷卡支付的能力。发生数据泄露后，司法鉴定调查和重新发卡的成本也会沿着同样的路径由您承担。

## 为什么“直接添加支付功能”会让您的整个应用都纳入合规范围？

合规范围（Scope）是整个问题的核心。PCI DSS 适用于存储、处理或传输持卡人数据的每一个系统，以及与这些系统连接的所有内容。合规验证就像爬梯子，每一级都比上一级沉重得多[²](https://secureframe.com/blog/pci-saq)：

- **SAQ A**（自我评估问卷 A）：支付完全外包给符合合规要求的提供商，卡数据绝不接触您的系统。这是最简短的问卷。
- **SAQ A-EP**：您的网站绝不接触卡数据，但控制着客户如何到达支付表单。此时完整标准中的很大一部分已开始适用于您的 Web 服务器。
- **SAQ D**：卡数据经过您构建的任何内容，即使是暂时的、未经存储的。这实际上意味着整个标准都需要每年进行文档化和签署确认。

![顶部放着信用卡的合规文件堆，代表 PCI DSS 自我评估问卷](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/0c4ed4b3d666d99c-pci-saq-paperwork-stack.png)

最低的那一级也并不意味着“毫无要求”。2025 年 1 月，PCI 安全标准理事会虽然从 SAQ A 中移除了支付页面脚本要求，但增加了一项资格条件：您必须确认您的网站不易受到可能影响电子商务系统的脚本攻击[¹](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a)。即使是完全外包的层级，也要求您能够防护托管他人支付表单的页面。

每年处理的刷卡交易超过 600 万笔后，自我评估将彻底结束，由 QSA（认证的外部评估员）进行的现场审计将随之开始[²](https://secureframe.com/blog/pci-saq)。

## 您能通过编写代码绕过面对面支付的限制吗？

不能。面对面支付是梯子变成高墙的地方。面对面交易需要经过认证的硬件：通过了理事会 [PTS 实验室项目](https://www.pcisecuritystandards.org/standards/pts-point-of-interaction-poi/)认证的物理读卡器，运行着经过批准的固件，并通过支付处理商进行配置。仅靠软件将手机变成读卡器属于另一项标准 [Mobile Payments on COTS (MPoC)](https://www.pcisecuritystandards.org/standards/mobile-payments-on-cots-mpoc/) 的范畴，且它认证的是解决方案提供商，而非您自行构建的产品。

![商店柜台上的无品牌已认证支付终端，即 PCI 对面对面支付要求的硬件层](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/0d02d9e5e5229253-certified-payment-terminal-counter.jpg)

这是 AI 代码生成无法逾越的边界。模型可以在半天内生成一个有说服力的结账界面；[你能用 Lovable 或 Replit 构建 POS 吗？](/blog/build-a-pos-with-lovable-or-replit) 和 [氛围编码（Vibe Coding）POS 系统](/blog/vibe-coding-a-point-of-sale) 梳理了这些构建陷入停滞的节点。没有生成的代码能凭空产生经过认证的读卡器、收单协议或合规签署声明，无论[模型在无人监督的情况下编码多久](/blog/claude-opus-5-pos-more-than-code)。合规性也是[氛围编码的支付应用被 App Store 拒绝](/blog/why-vibe-coded-payment-apps-get-rejected)的常见原因。

## 开发者实际上如何缩小 PCI 合规范围？

答案不是更硬核地去满足合规要求，而是通过架构设计减少需要合规的内容：

- 绝不要让 PAN（主账号，即卡号本身）接触您的代码。使用处理商托管的支付字段，使卡数据直接从客户的浏览器传输到处理商。
- 存储 Token（令牌），而非卡号。标记化（将卡号替换为即使被盗也毫无价值的引用字符串）可以防止保存的卡号和退款操作将您的数据库拖入合规范围。
- 对于面对面销售，请使用处理商提供的经过认证的读卡器，以便卡数据直接从读卡器流向处理商，而不经过您的应用。
- 保持支付页面简单干净。页面上的每一个第三方脚本都会变成您必须为此负责的内容。

![密封在玻璃罩内的信用卡，象征着将卡数据排除在 PCI 范围之外](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/2630089c92683ed9-card-data-out-of-scope-glass-case.jpg)

如果设计得当，您的应用只需协调销售流程而无需拥有任何卡数据，评估问卷也会保持简短。如果设计失误，某项便利功能（比如“记录完整的请求体”）就会静悄悄地将您推向 SAQ D。

## 那么，PCI 合规对应用开发者而言究竟有多痛苦？

痛苦程度取决于您的代码接触了多少卡数据，这就是为什么最明智的做法是完全不接触。标准并不关心应用是由开发团队编写的，还是由 AI 在半天内生成的；范围就是范围。在发布任何支持刷卡支付的产品之前，请先问一个问题：卡号是否有可能经过我编写的代码？如果是，请准备好审计预算。如果否，请继续保持。

这同样也是 Final 处理合规问题的架构逻辑。基于 Final 构建的结账流程，无论是在 Build 中通过提示词生成，还是由您自己的 AI 通过 MCP 构建，其支付均通过 Final Pay 运行：由支付处理商和经过认证的终端硬件处理卡数据，因此流程本身绝不持有卡号。[Final Pay 的可用地区](https://finalpos.com/help/where-final-pay-is-available)涵盖了实用层面的说明，而[将 Tap to Pay 连接到 AI POS 流程](/blog/connecting-tap-to-pay-to-an-ai-pos-flow)则展示了在合规层已经完备的前提下，刷卡支付是如何实现的。

## FAQ

**Q: PCI 合规是法律强制要求吗？**
A: 不是。PCI DSS 是卡组织通过银行和支付处理商施加的合同义务。其后果是商业性质的：通过您的收单银行下发的罚款、更高的处理费率，或者失去接受刷卡支付的能力。

**Q: 完全外包支付流程可以免除 PCI 义务吗？**
A: 不能。完全外包支付的商家可以使用最简短的问卷 SAQ A 进行验证，但自 2025 年 1 月修订以来，他们还必须确认其网站不易受到可能影响电子商务系统的脚本攻击。

**Q: SAQ A 和 SAQ D 有什么区别？**
A: 当符合合规要求的第三方处理所有卡数据时，适用 SAQ A，它仅涵盖标准的一小部分。当卡数据接触您自己的系统时，适用 SAQ D，它实际上涵盖整个标准，且需每年进行签署确认。

**Q: AI 生成的应用可以符合 PCI 标准吗？**
A: 代码可以遵循安全模式，但合规性依附于企业及其基础设施：经过认证的读卡器、处理商协议和年度签署声明。生成代码无法提供这些组成部分。

**Q: 当前的 PCI DSS 版本是什么？**
A: 截至本文发布时，当前版本为 PCI DSS 4.0.1。其最终的预留未来生效的要求已于 2025 年 3 月 31 日成为强制性要求。请访问 PCI 安全标准理事会网站了解最新状态。