PCI DSS 和 B2B 支付自动化：合规性要求

证据等级：A1 证据类型：官方一手信息 来源：Corpay Corporate Newsroom 官方发布日期：2026-07-28 采集时间：2026-07-31T12:43:43.590Z

PCI DSS 是支付卡行业数据安全标准，一套管理任何存储、处理或传输持卡人数据的组织的12项要求。无论公司规模或交易量大小，它都适用，并且它对企业对企业（B2B）卡项目的适用性与对零售结账的适用性完全相同。

最后一点让财务团队措手不及。PCI DSS 看起来像是一个零售标准，针对在销售点刷卡的商户而写，而且大多数在线讲解都是面向电子商务运营商的。与此同时，应付账款部门已经运行虚拟卡项目三年了，将供应商的卡号存储在电子表格中以进行重复付款，并将卡片详细信息通过电子邮件发送给无法接受付款文件的供应商。

是否涉及范围取决于一个比大多数人假设的更狭窄的问题。问题在于卡片数据是否接触您控制的系统，而不是您是否使用卡。一旦理解了这个区别，实际目标就会从变得合规转向缩小您必须合规的范围。

关键要点

• PCI DSS适用于存储、处理或传输持卡人数据的任何实体，没有最低规模或交易门槛。

• 该标准将12项核心要求组织在六个控制目标下，而且v4.0.1现为唯一有效版本。

• 您的持卡人数据环境是接触卡数据的系统集合以及与其连接的所有内容。环境中的所有内容都适用于该标准。

• 通过将卡支付路由到持有数据的提供商，大部分程序可以在您自己的环境之外执行，这属于范围缩减，而不是合规捷径。

• PCI DSS 和 SOC 2 回答的是不同的问题。前者是带有规定性要求的强制性卡数据标准；后者是对服务组织控制的认证。

PCI DSS 要求什么，谁来执行？

PCI DSS 是由主要卡组织成立的PCI安全标准委员会维护的安全标准，规定了保护账户数据的技术和操作要求。它是一种通过您的卡片协议产生的合同义务，而不是法律，这让那些期望有监管机构支持的人感到惊讶。

执法路径是通过网络和收单机构而不是政府机构进行的。这种区别在实际上很重要，因为不合规的后果表现为通过你的收单银行传递的罚款、增加的交易成本，或者在严重情况下失去卡支付接受权限，以及在违规后因合规失败而显著加重的责任风险。

该标准本身具有大多数安全框架没有的规范性。它不是只是询问你是否有记录在案的加密方法，而是具体规定必须加密的内容、加密的位置以及在何种条件下加密。一旦进入适用范围，这种具体性确实非常有用，也正因为如此，保持在范围之外才真正值得付出努力。

六个控制目标和十二项要求是什么？

根据PCI安全标准委员会，PCI DSS设定了12项核心要求，分为六个控制目标，并适用于任何存储、处理或传输持卡人数据的实体，无论其规模或交易量如何。所有v4.x版本的要求自2025年3月31日起成为强制性要求。

<table><tbody><tr><td><p><b>控制目标</b></p></td><td><p><b>其中包含的要求</b></p></td></tr><tr><td><p><b>建立和维护安全的网络和系统</b></p></td><td><p>安装和维护网络安全控制；对所有系统组件应用安全配置</p></td></tr><tr><td><p><b>保护账户数据</b></p></td><td><p>保护存储的账户数据；加密通过开放的公共网络传输的持卡人数据 网络</p></td></tr><tr><td><p><b>维护漏洞管理程序</b></p></td><td><p>保护系统和网络免受恶意软件侵害；开发和维护安全的系统和软件</p></td></tr><tr><td><p><b>实施强有力的访问控制措施</b></p></td><td><p>根据业务知情需要限制对系统组件和持卡人数据的访问；识别用户并验证访问权限；限制对持卡人数据的物理访问</p></td></tr><tr><td><p><b>定期监控和测试 记录和监控对系统组件和持卡人数据的所有访问；定期测试系统和网络的安全性 维护信息安全政策 通过组织政策和项目支持信息安全

来源：PCI 安全标准委员会，PCI DSS v4.0.1（2024–2025）。

向下阅读右侧栏，有一件事对财务团队来说尤为突出。大约一半的事项是您的 IT 部门为了其他原因已经在执行的，而真正麻烦的部分是存储、加密、访问限制和日志记录，这些恰恰是如果数据从未进入您的系统就可以省略的要求。

现在适用的是哪个版本？

PCI DSS v4.0.1 是唯一有效的标准版本。它于 2024 年 6 月 11 日发布，而 v4.0 已于 2024 年 12 月 31 日退役，根据 PCI 安全标准委员会的“刚发布：PCI DSS v4.0.1”公告。

版本问题出现的频率比应有的要高，因为 v4.x 的过渡经历了很长时间，同时伴随着大量未来需求，组织可以将其视为最佳实践，直到 2025 年 3 月的截止日期。那个宽限期已经结束。如果供应商或内部团队仍在使用 v3.2.1 的清单，那么差距是真实存在的，并且值得在下一次评估之前就将其揭示，而不是在评估过程中才发现。

PCI DSS 是否适用于您的 B2B 支付？

如果持卡人数据触及您拥有、操作或配置的任何系统，它就适用。交易量不会使您免除，B2B也不会使您免除，支付供应商而非接受消费者付款也不会使您免除。问题完全关于数据流。

大多数财务团队发现他们比自己想象的范围更接近。触发原因很少是支付平台本身，而是围绕它产生的变通方法，比如供应商无法通过门户处理虚拟卡，因此有人会通过电话读出号码并将其保存到共享文档中以备下个月使用。

不过，这值得按比例看待。按数量计算，信用卡只是B2B支付总量中的少数，而大部分支付都是通过根本不承载持卡人数据的支付通道进行的。仅ACH网络在2024年就处理了73亿笔B2B支付，同比增长11.6%，总支付33.6亿笔，金额达86.2万亿美元，根据Nacha的2024网络统计。你的PCI义务仅适用于信用卡部分，而不是整个项目，这就是为什么跨越信用卡以及B2B中的EDI和ACH格式的支付组合，需要按支付通道而不是按部门划定范围。

PCI DSS适用于谁？

PCI DSS 适用于任何存储、处理或传输持卡人数据的实体，以及任何其系统可能影响该数据安全性的实体。在 B2B 支付计划中，通常包括：

• 运营虚拟卡计划的公司，其卡号会通过他们控制的系统传输

• 为定期付款存储供应商或企业卡号的公司，包括电子表格和 CRM 记录中的任何格式

• 运营支付门户或接受自己客户的卡支付的公司

• 代表他人处理卡交易的服务提供商，这是一个独立且要求更高的类别

• 未与上述系统隔离的任何连接系统，包括共享文件服务器或未分割的办公网络

通常不会将你纳入范围的是，通过你的收单机构终端作为供应商接收付款，或者通过提供商发卡支付，而卡号完全在他们的基础设施上生成、存储和传输。在第二种情况下，数据实际上从未进入你的环境，范围追随数据而非意图。

支付计划中的持卡人数据环境（CDE）是什么？

持卡人数据环境包括处理持卡人数据的每个人、每个流程和每个系统。它还包括与该集合连接或能够影响其安全性的任何组件。准确定义你的CDE是任何PCI工作中的第一项真正任务，也是大多数评估出问题的地方。

连接性是意外扩展范围的部分。一个能够访问存有卡数据系统的单一工作站会将自身拉入CDE，其所在的网络段也是如此，除非分段控制能证明不是这样。一个财务团队原以为他们的CDE只有一个应用程序，但经常会发现它实际上是一个应用程序加一个VLAN加一个跳转主机加四个应付专员的笔记本电脑。

在B2B支付中，卡数据隐藏在五个大多数盘点容易忽略的地方：

• 应付账款收件箱，供应商发送附带卡号的汇款问题的地方

• 记录的客户服务电话，这些电话很少被搜索，也很少被清除

• ERP的供应商备注字段，有人为了方便而存放了一个号码

• 备份文件和归档电子邮件，会继承它们创建时的范围

• 当门户无法处理特定供应商时，团队创建的任何电子表格

将你在支付系统数据管理中应用的同样纪律作为实际起点，因为未映射的CDE是无法缩小的CDE。保护企业的安全措施通常也是评估人员在这里测试的措施，只不过应用于更狭窄的目标。

支付自动化如何影响你的PCI DSS范围？

支付自动化可以通过将卡片数据从您控制的系统转移到供应商环境中，显著减少您的范围。如果实施过程中，数据仍然保留在您的ERP中，或者您的团队需要围绕不完整的供应商注册构建手动解决方案，也可能会扩大您的范围。

方向几乎完全取决于供应商付款实际是如何交付的，而不是平台宣传册上声称的内容。这是在评估过程中需要问的问题，这个问题比询问供应商是否合规更有用。对企业电子支付的任何认真评估都应该包括一个数据流图，因为评估人员最终会要求提供该图。

一个合规的平台如何能够减少您的范围？

合规平台通过自身保存卡数据来减少范围，所以您的系统处理的是引用而不是数字。四种机制完成了大部分工作：

1. 令牌化。您的ERP和应付账款系统存储映射到提供商端保存的卡号的令牌。如果令牌被外泄，它是无用的，并且通常仅持有令牌的系统不在CDE范围内。

2. 提供商托管的发行和交付。在提供商的基础设施上生成虚拟卡号，并直接交付给供应商，因此您的团队从未看到或处理完整的卡号。了解B2B中虚拟卡支付的工作原理使评估这一机制更容易。

3. 托管支付页面和重定向。当您从客户那里接受卡片支付时，通过 iframe 或重定向到提供商的页面可以让您的 Web 服务器不参与交易路径。

4. 供应商入驻正确完成。这是最不引人注目的部分，也是决定其他三个是否成立的部分。每个无法接受自动支付方式的供应商都会成为手动例外，而手动例外则是卡号最终出现在电子邮件中的地方。

第四点值得强调，因为这是我看到范围缩减 quietly 失败的地方。一个自动化处理大部分供应商付款并通过电话处理剩余部分的项目，其 CDE 根本没有减少。它只是在人工作业上增加了一个平台，评估员还是会看到电子表格。让供应商使用他们实际会接受虚拟卡付款的方法是一项合规活动，而不仅仅是一个采用指标。

范围缩小并不等同于合规性转移。你仍然需要对自己的环境、合同以及验证服务提供商的范围是否覆盖你认为它覆盖的部分负责。变化的是，有多少部分资产需要满足12项规定的要求。在发行方面，虚拟卡项目中内置的安全控制决定了有多少资产一开始就保持在CDE之外。

这与欺诈和安全漏洞暴露有何关联？

它之所以相关，是因为在你的环境中集中的卡片数据既是一种合规义务，又是攻击目标，而将其移除可以同时解决这两方面的问题。损失数据为暴露问题提供了具体形象。根据Nilson报告，2024年全球卡片欺诈损失总额为334.1亿美元，而卡片交易总额为51.92万亿美元。美国当年占全球卡片欺诈损失的41.87%，而占全球卡片交易量的比例为26.31%。

41.87%与26.31%之间的差距是有趣的数据，它是卡片接受范围最广且历史上认证要求最宽松的地方欺诈集中程度的合理代理，可作为方向性参考。欺诈损失分配方法各异，各市场的底层报告也不统一。

违规成本是叠加在欺诈损失之上的，而不是取代它。根据 IBM 的《2024 年数据泄露成本报告》，2024 年全球数据泄露平均成本创下 488 万美元的纪录，同比上涨 10%，且第三方曝光问题占比不断增加。在 Verizon 最新的《数据泄露调查报告》中，15% 的泄露事件涉及第三方，同比增加 68%。

支付欺诈通过另一扇门出现，对应付款部门打击最为严重。根据金融专业人士协会的《2025 年支付欺诈与控制调查报告》，2024 年有 79% 的组织成为尝试或实际支付欺诈的受害者。PCI DSS 无法阻止企业电子邮件欺诈，这需要明确说明，因为供应商冒充攻击重定向 ACH 支付时根本不涉及卡数据。卡数据控制以及更广泛防御公司支付欺诈的做法是互补的项目，而不是单一项目。

PCI DSS 与 SOC 2 以及您的审计追踪有何关联？

它们回答的是不同的问题，彼此不能互相替代。PCI DSS 是针对特定数据类型的规定性、强制性标准。SOC 2 是对服务组织控制的一种灵活鉴证，根据它部分选择的标准进行。一个供应商可以拥有其中一个、两个或都没有，而了解哪一个会告诉你不同的信息。如何验证应付账款自动化供应商的 SOC 2 报告覆盖了该问题中鉴证的部分，这一部分进行了详细说明。

你自己的审计跟踪位于两者之下。PCI DSS 的第 10 条要求是关于记录和监控对持卡人数据的访问，而任何 SOC 2 审查都会测试特权操作是否会生成可审查的记录。两个框架都假设你能够重建是谁在何时做了什么，这正是你的审计人员和你的欺诈控制所依赖的能力。

PCI DSS 与 SOC 2：对支付买家来说有什么区别？

区别在于强制性与证明，以及规定性与判断性。在供应商评估过程中，以下是两者在关键维度上的比较：

<table><tbody><tr><td><p><b>维度</b></p></td><td><p><b>PCI DSS</b></p></td><td><p><b>SOC 2</b></p></td></tr><tr><td><p><b>Nature</b></p></td><td><p>持卡人数据的强制标准，通过卡组织合同强制执行</p></td><td><p>由独立注册会计师事务所自愿进行的认证声明</p></td></tr><tr><td><p><b>范围由</b></p></td><td><p>持卡人所在的位置 数据流</p></td><td><p>服务组织，根据AICPA标准</p></td></tr><tr><td><p><b>要求</b></p></td><td><p>六个目标下的12条规定性要求</p></td><td><p>信任服务标准，只有安全性是强制性的</p></td></tr><tr><td><p><b>输出</b></p></td><td><p>合规性证明、合规报告或自我评估问卷</p></td><td><p>类型I或类型II报告与审计员的 意见</p></td></tr><tr><td><p><b>直接适用于你吗?</b></p></td><td><p>是的，如果卡数据涉及你的系统</p></td><td><p>不。它描述的是供应商的环境，而不是你的</p></td></tr><tr><td><p><b>要请求什么</b></p></td><td><p>供应商当前的AOC及其服务提供商级别</p></td><td><p>在保密协议下的当前Type II报告</p></td></tr></tbody></table>

来源：PCI 安全标准委员会和 AICPA 框架文档.

在两者都适用的情况下都要询问，并阅读各自的适用范围。提供商的合规性声明会列出被评估的服务，这个清单通常比提供商的完整服务目录要窄。管理减少合规和监管摩擦的范围控制纪律同样适用于这里，这是一个在评估人员为你建立之前就值得养成的习惯。

使用 Corpay 进行合规的 B2B 支付

本文反复提到的失败模式是手动例外：无法接受自动支付的供应商，以及最终落入不该出现的地方的卡号。这就是我们的模型构建的具体问题所在。

Corpay 支付自动化 通过虚拟卡、ACH 和支票进行供应商支付。我们的托管服务负责注册供应商并处理后续事务，而不是让您的团队去追踪那些未注册的供应商。在此背景下，注册覆盖是一种安全控制，因为我们将每个供应商纳入自动化方式，都会减少一次卡号被口头读取的机会。卡凭证在我们这边生成和发放，因此您的 ERP 使用的是参考信息，而不是原始账户数据。

在卡片方面，Corpay 商业卡 支持具有一次性卡号的虚拟卡计划，并可进行金额和商户控制，以及每笔交易的数据回流以便对账。两个合规事实，范围精确定义。Corpay 符合 SOC 2 Type II 标准。Comdata，Corpay 旗下公司，是 PCI DSS 一级服务提供商，这也是卡网络定义的最高服务提供商等级。

对于您自己的评估，实际要求很直接。在评估期间，请求我们的当前认证文件，确认其涵盖的服务，并让您的评估人员验证最终的数据流是否落在您预期的位置。这就是我们也期望您对任何提供商所持的相同标准。

常见问题解答

什么是 PCI DSS？

PCI DSS 是支付卡行业数据安全标准，由 PCI 安全标准委员会维护，该标准规定了保护持卡人数据的 12 项要求。它通过卡网络和收单银行在合同上强制执行，而不是通过政府监管机构执行，并且适用于处理卡数据的任何组织。

什么是 PCI DSS 合规？

PCI DSS 合规意味着您的组织针对存储、处理或传输持卡人数据的每个系统都符合该标准的要求，并且已通过自我评估问卷或根据您的交易量和角色进行的正式评估进行了验证。验证是定期进行的；预计合规状态应持续保持。

PCI DSS适用于谁？

PCI DSS 适用于任何存储、处理或传输持卡人数据的实体，以及任何可能影响该数据安全的相关系统。没有最低交易量或公司规模的豁免，它对 B2B 卡计划的适用方式与对零售商的适用方式相同。

在 PCI DSS 中，CDE 是什么？

CDE，即持卡人数据环境，是处理持卡人数据的一组人员、流程和技术，以及与其连接或能够影响其安全的每个系统组件。准确定义 CDE 是任何评估的第一步，因为其中的所有内容都必须符合标准。

如何才能符合 PCI DSS？

首先绘制持卡人数据实际存放的位置，然后消除每个不真正需要的实例。确定您的商户或服务提供商等级，完成相应的自我评估问卷，或者聘请合格的安全评估员，修复发现的差距，并每年进行验证。先减少范围可以让每一个后续步骤更便宜。

大卫·卢瑟

产品营销项目经理

大卫·卢瑟，工商管理硕士，是一位产品营销项目经理，在商业银行、金融和技术领域拥有多年的经验，他的研究和撰写作品曾出现在金融出版物中。

支付自动化

风险管理