集成安全指南
确保客户端和服务器之间的通讯符合 PCI 规定且安全。
涉及处理、传输或存储银行卡数据的任何人都必须遵守支付卡行业数据安全标准 (PCI DSS)。Stripe 已通过独立 PCI 合格安全评估商 (QSA) 的审查，并且获得了 PCI 1 级服务商认证。这是支付行业中最严格的认证级别。
PCI 合规是一项共同责任，Stripe 及您的公司都要为之负责。当您接受付款时，必须要以符合 PCI 要求的方式进行。对您来说，保持 PCI 合规的最简单方法是永远不要看到（或访问）银行卡数据。Stripe 可让您轻松实现这一点，因为我们可以承担起保护您客户的银行卡信息此繁重的工作。做到以下几点您即可简化您的 PCI 合规：
- 使用我们推荐的某个支付集成来收集支付信息，确保其安全地直接传输到 Stripe，而不会经过您的服务器。
- 用传输层安全协议 (Transport Layer Security, TLS) 安全地提供您的支付页面，以便它们能够使用 HTTPS
- 每年检查并验证您账户的 PCI 合规性。
验证您的 PCI 合规性
所有 Stripe 用户都必须每年验证他们的 PCI 合规性。大部分用户都可以通过支付卡行业安全标准委员会提供的一份自我评估问卷 (Self-Assessment Questionnaire, SAQ) 来完成这项工作。SAQ 的类型取决于您集成 Stripe 的方式，以及您使用以下哪种方法来收集银行卡数据。某些方法可能需要您向我们上传额外的 PCI 文档。如果有必要，您可以在管理平台中上传它们。如果您使用下述方法中一个以上的方法，也没有必要上传多个 SAQ。
如果您不确定如何证明您的业务符合 PCI 标准（例如，您的集成应用由第三方构建），请与 PCI 合格安全评估员 (QSA) 联系，以确定如何根据 PCI 委员会的现行指南来最好地验证您的合规性。
集成的 PCI 合规要求
| 集成应用 | 要求 | 建议 |
|---|---|---|
直接 API | SAQ D | 当您直接将银行卡信息传递到 Stripe 的 API 时，您的集成应用将直接处理该数据，并且您需要每年使用 SAQ D 证明您的 PCI 合规性，这是 SAQ 中要求最严格的。为了减轻这一负担： |
| Checkout 或 Elements | SAQ A | Checkout 和 Stripe.js 与 Elements 将所有银行卡数据收集输入托管在由 Stripe 域（而非您的域）提供的 iframe 中，因此您的客户银行卡信息绝不会接触到您的服务器。因此，您可以将 PCI 合规性负担降到最低。 |
| Connect | SAQ A | 如果您仅仅通过 Connect 平台（如 Squarespace）收集银行卡数据，我们可以确定平台是否提供了必要的 PCI 文档。 |
管理平台 | SAQ C-VT | 只有在特殊情况下才可以通过管理平台手动处理银行卡付款，不可作为常规付款处理方式。为您的客户提供合适的支付表单或移动应用程序来输入他们的银行卡信息。 我们无法验证手动输入的银行卡信息在 Stripe 之外是否安全，因此您必须根据 PCI 合规要求保护银行卡数据，并每年完成 SAQ C-VT，以证明您的业务符合 PCI 合规要求。 |
Mobile 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 合格安全评估员 (QSA)，了解如何最好地验证您的 PCI 合规性。 |
Stripe.js v2 | SAQ A-EP | 使用 Stripe.js v2 来传递在您自己网站上托管的表单中输入的银行卡数据时，需要每年填写 SAQ A-EP，以证明您的业务符合 PCI 标准。 |
Terminal | SAQ C | 如果您专门通过 Stripe Terminal 收集银行卡数据，则可以使用 SAQ C 进行验证。 如果您使用本表所列的其他方法与 Stripe 集成，则必须按照描述，分别证明它们的合规性。 |
警告
如果您每年用 Visa 或 MasterCard 处理的交易笔数超过 600 万笔，或者用 American Express 处理的交易笔数超过 250 万笔，或者被任何卡组织视为一级提供商，则您没有资格用 SAQ 来证明您的 PCI 合规性。支付品牌要求您每年填写一份合规报告 (RoC)来验证您的 PCI 合规性。
使用 TLS 和 HTTPS
TLS 是指在客户端（您的客户使用的应用程序或浏览器）与您的服务器之间安全传输数据的过程。安全套接层 (SSL) 协议最初执行此功能，但已经过时且不再安全。TLS 已经代替了 SSL，但在提及 TLS 及其保护传输数据的功能时，仍通俗地使用术语 SSL。
支付页面必须使用近期版本（TLS 1.2 或以上），因为它可以显著降低您和您的客户遭受中间人攻击的风险。TLS 会尝试完成以下工作：
- 加密并验证客户端和服务器之间流量的完整性。
- 验证客户端能够与正确的服务器通讯。实际上，这通常就等于是验证了域名的所有者和服务器的所有者是同一个实体。这有助于防止中间人攻击 (Man-in-the-Middle Attack)。否则，就不能保证您将流量加密到正确的接收者。
此外，您的客户更愿意在明确使用 HTTPS 的页面上分享敏感信息，这有助于提高您的客户转化率。
如果需要，您可以在不使用 HTTPS 的情况下测试您的集成应用，然后在准备好接受真实收款时再启用它。但是，您的服务器和 Stripe 之间的所有交互（即在使用我们的库时）都必须使用 HTTPS。
设置 TLS
使用 TLS 需要_数字证书_——由认证中心 (CA) 发行的文件。安装该证书可向客户端保证，它实际上在与它期望与之对话的服务器通信，而非冒名顶替者。从信誉良好的证书提供商处获取数字证书，例如：
根据证书的类型和提供商，证书的费用可能会有所不同。“Let’s Encrypt” 是一个免费提供证书的认证机构。
如何设置 TLS：
- 从合适的提供商处购买证书。
- 配置您的服务器以使用该证书。此步骤可能很复杂，因此请遵循您使用的提供商的安装指南。
由于 TLS 是一套复杂的加密工具，因此很容易遗漏一些细节。建议您使用 Qualys SSL Labs 的 SSL Server Test，确保您以安全的方式设置所有内容。
安全考虑
包含来自其他网站的 JavaScript 会使您的安全性依赖于他们的安全性，并带来安全风险。如果它们的安全性遭到威胁，攻击者可能会在您的页面执行任意的代码。实际上，许多网站甚至在安全页面上使用 JavaScript 来提供 Google Analytics 等服务。尽管如此，我们建议尽量减少它。
如果您在使用 Webhook，则对端点使用 TLS，避免流量被拦截和通知被更改（Webhook 事件中永远不会包含敏感信息）。
虽然遵守《数据安全标准》很重要，但这不应该就此停止考虑安全性问题。以下这些资源可帮助您了解网络安全：
您可以安全存储的银行卡数据
Stripe 在响应收款请求时会返回非敏感银行卡信息。包括银行卡的类型、后四位数字及到期日。这些信息不受 PCI 合规的限制，因此可以在您的数据库中存储这些属性。此外，您还可以存储我们的 API 返回的任何内容。
内容安全政策
如果您已经部署了内容安全政策，则 Checkout、Connect 嵌入式组件和 Stripe.js 要求的全套指令为：