自 2005 年以来,美国已有 9,000 多起数据泄露事件泄露了 100 多亿条消费者记录。这些数据来自 隐私权清算中心,该机构自 2005 年起报告影响消费者的数据泄露和安全漏洞。为了提高消费者数据的安全性和支付生态系统的信任度,制定了最低的数据安全标准。Visa、Mastercard、American Express、Discover 和 JCB 于 2006 年成立了支付卡行业安全标准委员会 (PCI SSC),负责制定和管理涉及信用卡数据的公司安全标准。
支付卡行业数据安全标准 (PCI DSS) 是全球性的安全标准,适用于所有存储、处理或传输持卡人数据和/或敏感身份认证数据的实体。PCI DSS 为消费者设定了基准保护级别,并有助于减少支付生态系统中的欺诈和数据泄露事件。它适用于所有接受或处理支付卡的组织,未能符合这些标准的组织将面临重大处罚、罚款和成本。
PCI DSS 合规性涉及三个主要组成部分:
- 处理客户信用卡数据的输入,确保敏感卡片详细信息的收集和传输安全
- 安全存储数据,这包括 PCI 标准中的 12 个安全领域,如加密、持续监控和访问卡数据的安全测试
- 每年验证所需的安全控制措施是否到位,可能包括表单、调查问卷、外部漏洞扫描服务以及第三方审核(请参阅下面的步骤指南,查看四个级别的要求表格)
所有接受信用卡付款的企业都必须遵守 PCI DSS,无论其交易量、地理区域或集成方法如何。通过遵守此框架,企业可以:
- 通过确保客户的银行卡数据安全来建立客户信任
- 保护自己免受欺诈和数据泄露的影响
- 避免因违反 PCI 合规而被罚款
免责声明: 本文仅用于指导目的,不应被视为最终建议。我们建议咨询支付卡行业数据安全标准 (PCI DSS) 合格安全评估员 (QSA) 进行澄清。
Stripe 如何帮助组织实现和维护 PCI 合规性
如果您的商业模式要求您处理银行卡数据,您可能需要满足 PCI DSS 中 300 多项安全控制措施中的每一项。PCI 安全标准委员会发布了 1,800 多页的关于 PCI DSS 的官方文档,还有 300 多页只是为了了解在验证合规性时使用哪种表格。
Stripe 通过提供各种令牌化集成方法(例如,Checkout、Elements、移动 SDK、Terminal SDK),避免了直接处理敏感信用卡数据的需要,可以显著减轻公司的 PCI 负担。
- Stripe Checkout 和 Stripe Elements 使用托管支付字段来处理所有支付卡数据,因此持卡人在直接来自我们 PCI DSS 验证服务器的支付字段中输入所有敏感的支付信息。
- Stripe 移动和 Terminal SDK 还使持卡人能够将敏感的支付信息直接发送到我们经 PCI DSS 验证的服务器。
对于我们所有的用户,无论集成类型如何,Stripe 都是 PCI 的倡导者,可以通过多种不同的方式提供帮助。
- 我们的 Stripe PCI 向导会分析您的集成方法,并就如何减轻合规负担为您提供建议。
- 如果不断增长的交易量需要更改您验证合规性的方式,我们会提前通知您。
- 对于因存储信用卡数据或支付流程更复杂而需要使用 PCI QSA 的大型或企业,全球有 400 多家此类 QSA 公司。我们可以为您联系几位深入了解不同 Stripe 集成方法的审核员。
PCI DSS 合规分步指南
1. 了解您的 PCI 级别
实现 PCI 合规性的第一步是了解哪些要求适用于您的组织。有四种不同的 PCI 合规级别,通常根据您在 12 个月内处理的信用卡交易量来确定。
根据您的级别,您将有不同的要求,包括定期漏洞扫描这些扫描来自经批准的扫描供应商 (ASV)。对于服务提供商还有额外的要求,服务提供商是指直接参与处理、存储或传输持卡人数据(CHD)和/或敏感身份验证数据(SAD)的商业实体,通常代表其他实体(例如,支付网关、支付服务提供商和独立销售组织)进行这些操作。
合规等级
|
适用对象
|
要求
|
---|---|---|
1 级
|
|
|
2 级
|
|
|
3 级
|
|
|
4 级
|
|
|
2. 了解您的集成类型和文档要求
一旦您知道自己的 PCI 级别,下一步就是根据您与 Stripe 的集成方式、您是否是服务提供商等因素,确定您需要完成哪些 PCI 文档来验证您的合规性。
1 级用户
1 级企业没有资格使用 SAQ 来证明 PCI 合规性。他们需要完成由 QSA 或商家执行官签署的 ROC,以每年验证其 PCI 合规性。
2-4 级用户
对于 2-4 级用户,根据您的支付集成方式,有不同的 SAQ 类型。如果您不确定哪种 SAQ 类型适合您,Stripe PCI 向导将自动确定适合您业务的文档类型。
集成
|
要求
|
建议
|
---|---|---|
Checkout 或 Elements
|
SAQ A |
Checkout 以及 Stripe.js 和 Elements 在 Stripe 的域名(而非您的域名)提供的 iframe 内托管所有银行卡数据收集输入字段,因此您客户的银行卡信息永远不会接触到您的服务器。
|
Connect
|
SAQ A | 如果您仅仅通过 Connect 平台(如 Squarespace)收集银行卡数据,我们可以确定平台是否提供了必要的 PCI 文档。 |
移动端 SDK
|
SAQ A |
Stripe 的移动端 SDK 的开发和修改控制符合 PCI DSS(要求 6.3 - 6.5)的要求,并且是通过我们的 PCI 验证系统来实施的。当您仅使用来自我们官方的 iOS 或 Android SDK 的用户界面组件时,或者在 WebView 中使用 Elements 构建支付表单时,卡号将直接从您的客户传递到 Stripe,因此您的 PCI 合规负担最轻。 如果您不这样做,例如编写自己的代码来处理银行卡信息,则您可能需要负责额外的 PCI DSS 要求 (6.3-6.5),并且不再具有 SAQ A 资格。请与 PCI 合格安全评估员 (QSA) 联系,以确定如何根据 PCI 委员会的现行指南来最好地验证您的合规性。 如果您的应用程序要求客户在他们自己的设备上输入其信息,那么您便有资格使用 SAQ A。如果您的应用程序在您的设备上接受多个客户的银行卡信息(例如,销售点应用程序),则请咨询 PCI 合格安全评估员,了解如何最好地验证您的 PCI 合规性。 |
Stripe.js v2
|
SAQ A-EP | |
Terminal
|
SAQ C |
如果您专门通过 Stripe Terminal 收集银行卡数据,则可以使用 SAQ C 进行验证。 如果您使用本表所列的其他方法与 Stripe 集成,则必须按照描述,分别证明它们的合规性。 |
管理平台
|
SAQ C-VT |
只有在特殊情况下才可以通过管理平台手动处理银行卡付款,不可作为常规付款处理方式。为您的客户提供合适的支付表单或移动应用程序来输入他们的银行卡信息。 我们无法验证手动输入的银行卡信息在 Stripe 之外是否安全,因此您必须根据 PCI 合规要求保护银行卡数据,并每年完成 SAQ C-VT,以证明您的业务符合 PCI 合规要求。 |
直接 API
|
SAQ D |
服务提供商
如果您代表其他实体(例如支付网关、支付服务提供商和独立销售组织)直接参与持卡人数据 (CHD) 和/或敏感身份验证数据 (SAD) 的处理、存储或传输,您可能会被归类为服务提供商。服务提供商通常:
- 为其他组织处理持卡人数据
- 代表客户存储持卡人数据
- 在系统之间传输持卡人数据
- 提供可能影响持卡人数据安全或可能影响持卡人环境安全的服务
常见的例子包括支付网关、存储持卡人数据的托管服务提供商、第三方数据中心、提供支付应用程序的公司和令牌化服务提供商。
作为服务提供商,您有额外的要求,需要进行合规验证。
3. 完成评估,并提交 SAQ 文档
确定需要完成的评估后,下一步就是执行评估,完成相关的 SAQ 或 ROC 文档,并将其提交给 Stripe 进行审核。
大批量用户可能需要聘请在您运营地区注册的 QSA(认证评估员)。QSA 将帮助您根据 PCI 要求审查您的系统,并提供修复缺陷的建议。他们还将为您制作并签署适当的文档,您可以将这些文档每年分享给 Stripe。
3 级和 4 级用户可能需要完成适合其业务类型的 PCI DSS 自我评估问卷。更多商家资源 可通过 PCI 安全标准委员会获得。Stripe 也可以为您提供帮助,因为我们在您的 PCI 管理平台上的定制向导将提出一系列问题并为您生成所需的文档。您可以使用 Stripe PCI 管理平台上传任何自行完成的 SAQ 或 ROC 文档。
4. 监控和维护
需要注意的是,PCI 合规性不是一次性事件。这是一个年度流程,以确保您的业务在数据流和客户接触点不断变化的情况下仍保持合规性。
PCI DSS 为处理和存储持卡人数据设定了重要标准,但它自身并不能为所有支付环境提供充分的保护。相反,转向使用令牌化数据的更安全的卡接收方法(例如 Stripe Checkout、Elements 和移动 SDK)是保护您组织的更有效方式。这种方法为敏捷型企业提供了一种减轻潜在数据泄露风险的途径,避免了耗时且成本高昂的传统 PCI 验证方法。
随着公司的发展,核心业务逻辑和流程也会随之发展,这意味着合规性要求也会发生变化。例如,一家在线企业可能会决定开设实体店、进入新市场或设立一个客户服务中心。如果任何新的业务涉及支付卡数据,建议主动检查这是否会对所选 PCI 验证方法产生影响,并根据需要重新验证 PCI 合规性。
有关 PCI 合规性的复杂世界的更多信息,请前往PCI 安全标准委员会网站。如果您只阅读本指南和其他一些 PCI 文档,我们建议您从以下内容开始:
- 优先方法用于 PCI DSS
- [SAQ 说明和指南](https://docs-prv.pcisecuritystandards.org/SAQ%20(Assessment)/Instructions%20%26%20Guidance/SAQ-Instructions-Guidelines-PCI-DSS-v4-0.pdf)
- 关于使用 SAQ 资格标准来确定现场评估要求的常见问题
- 关于为接受支付卡数据的消费者设备开发应用程序的企业义务的常见问题
Stripe 如何帮助组织维护 PCI 合规性
Stripe 是 PCI 1 级服务提供商,每年由独立的 PCI 合格安全评估员根据所有 PCI DSS 要求进行认证。这意味着我们所有的产品在默认情况下都是安全的,从而减少了您的合规性要求。
对于我们所有的用户,无论集成类型如何,Stripe 都是 PCI 的倡导者,可以通过多种不同的方式提供帮助。
支持我们的小型企业
Stripe 通过提供定制的合规流程,包括为一些用户提供预填充的 SAQ 和引导式流程,利用更安全的集成方法,如 Checkout、Elements、移动 SDK 和 Terminal SDK,大大简化了我们小型用户的 PCI 负担。
定制的管理平台体验
一旦您成为 Stripe 的客户,我们将分析您的交易记录,并通过定制化的管理平台体验,就如何减轻您的合规负担为您提供建议。
在您的业务发展过程中提供支持
随着您的年度交易总量不断增加,您可能会发现自己在一年内就改变了 PCI 等级。Stripe 会在您临近 PCI 续期时提醒您新的要求,从而支持您完成过渡时期。
多个服务提供商
如果您的企业使用多个处理商,您的 PCI 合规流程可能会变得复杂。Stripe 支持提供商提交 AOC,从而简化您的合规流程,让您轻松实现合规。
支持 MOTO(邮购/电话订购)支付
Stripe 通过与第三方服务集成来支持接受 MOTO 支付的企业,以实现安全的基于电话的银行卡信息收集。这些服务使用按键式卡号提交或语音识别等技术自动收集银行卡详细信息,并且无需人工转录银行卡详细信息。这种方法可以通过消除“人工参与”的需求来显著减轻 PCI 合规性负担。对于 MOTO 用例,可能的 SAQ 结果有三种:
- SAQ-A:支付连接器用例,其中使用符合 PCI 标准的第三方解决方案通过电话收集持卡人数据,银行卡数据直接流入 Stripe。在此用例中,在银行卡数据通过电话呈现时用户不应访问银行卡数据,并且不应在其环境中存储、处理或传输持卡人数据。
- SAQ C-VT:用户通过 MOTO 支付接收银行卡数据,这些数据被直接输入到 Stripe 管理平台中。在这种情况下,手动提交仅适用于有限的使用场景,不能经常发生,并且要知道不允许以电子方式存储银行卡信息。
- SAQ-D:用户从客户那里收集持卡人数据并在其环境中电子存储持卡人数据的任何用例。
有关 PCI 合规性和 MOTO 实施的具体指导,我们建议咨询 PCI 合格安全评估员 (QSA)。