2024 年，全球 35.5% 的安全漏洞与第三方有关。当您与支付处理商合作时，这种漏洞的后果可能会更加严重。因此，安全性和合规性在任何支付征求建议书 (RFP) 中都是不容忽视的。您应在征求建议书 (RFP) 中要求潜在的支付服务商明确说明他们如何保护敏感数据、如何快速响应安全事件，以及如何帮助您的企业满足监管要求。
您需要在前期提出正确的问题，并要求支付服务商提供证据来佐证答案。下面，我们将探讨在支付征求建议书 (RFP) 中询问安全性和合规性的所有最佳实践。
本文内容
- 每份支付征求建议书 (RFP) 中应包含哪些安全性和合规性要求？
- 如何将 PCI DSS 要求写入支付征求建议书 (RFP) 中？
- 您应该向支付服务商询问哪些基本数据保护和隐私方面的问题？
- 如何在征求建议书 (RFP) 中评估供应商的欺诈预防能力？
- 供应商应提供哪些事件响应与灾难恢复细节？
- 如何在征求建议书 (RFP) 中询问全球合规要求？
- 您应该要求支付服务商在加密、令牌化和身份验证方面做些什么？
- 如何在征求建议书 (RFP) 中纳入移动端与应用程序内支付安全要求？
- 支付征求建议书 (RFP) 中应要求提供哪些报告和审计功能？
- 支付服务商在征求建议书 (RFP) 回复中出现的哪些警告信号表明其安全或合规性存在问题？
- Stripe Payments 能在哪些方面提供帮助
每份支付征求建议书 (RFP) 中应包含哪些安全性和合规性要求？
在撰写支付征求建议书 (RFP) 时，安全和合规性部分用于明确每个认真的支付服务商应满足您业务的基线期望。您的征求建议书 (RFP) 应强制要求支付服务商证明，其在所有这些领域都具有强大且经过独立验证的安全性。
行业认证与审计
要求支付服务商出示以下认证和审计证明：用于银行卡数据的支付卡行业数据安全标准 (PCI DSS)、用于信息安全的国际标准化组织 (ISO) 27001，以及用于运营控制的系统和组织控制 (SOC) 2 Type 2。这些证明外部审计员已经检查过支付服务商的做法。
PCI DSS 合规性
需要支付服务商达到 PCI 合规性的最高级别（1 级），并要求其提供合格安全评估员出具的最新合规性证明，作为正式凭证。
数据保护与隐私
确定支付服务商采用何种方式保护所有客户信息，包括个人详细信息、账单地址和身份信息。询问这些数据在何处存储、如何加密以及如何控制访问。确保支付服务商签署数据处理协议，并支持隐私法规，例如欧盟的通用数据保护条例 (GDPR) 和加州消费者隐私法案 (CCPA)。
欺诈预防
询问支付服务商的欺诈防范能力，例如是否使用机器学习、规则引擎和 3DS 验证。了解如何在阻止欺诈和保持高通过率之间取得平衡。通过征求建议书 (RFP) 回复，确认其能够帮助减少撤单和欺诈损失，同时避免影响合法客户的体验。
事件响应与灾难恢复
每家支付服务商都应具备应对违规和中断的计划。应询问支付服务商如何检测和响应突发事件，在数据受影响时会以多快的速度通知您，以及关键数据恢复目标（恢复时间目标 (RTO) 或恢复点目标 (RPO)）是什么。
全球监管合规范围
如果业务涉及国际运营，支付服务商需要能够处理当地法规，避免产生意外情况。要求支付服务商应符合欧洲的修订后的支付服务指令 (PSD2)、美国的制裁筛选以及印度等国家/地区的数据本地化规则。
核心数据安全管制
明确您对加密、令牌化和身份验证的要求。数据在传输和存储时应使用现代标准进行加密，敏感数据应进行令牌化处理，确保您无需直接接触。支付服务商系统应对内部用户强制执行严格的身份验证。
移动端与应用程序内支付
如果您的业务基于移动端运营，则应包括针对该移动环境的具体要求。询问其软件开发工具包 (SDK) 的安全性，敏感数据是否绕过您的服务器以缩小 PCI 范围，以及他们如何支持 Apple Pay 和 Google Pay 等数字钱包。
报告与审计功能
强制要求提供交易报告、欺诈和争议分析，以及用于跟踪管理操作的系统审计日志。您需要有足够的权限访问数据，以便能够自行进行审计，并满足合规性要求。
如何将 PCI DSS 要求写入支付征求建议书 (RFP) 中？
PCI DSS 是关于银行卡数据的全球规则手册。在您的征求建议书 (RFP) 中，PCI 合规性应像合同条款一样明确。应要求支付服务商提供 1 级认证证明，并确保其承诺随着标准的发展保持合规。
以下是确保您的征求建议书 (RFP) 措辞不会产生混淆或误解的方法：
明确级别和证明： 声明支付服务商必须通过 PCI 1 级认证。这是衡量合规性的黄金标准。
坚持持续合规： 询问支付服务商将如何适应不断变化的 PCI DSS 要求。您可以这样说：“确认贵方在合同有效期内保持 PCI 合规性，并说明贵方如何调整以适应新的 PCI DSS 版本。”答案应提及年度审计、季度扫描和持续监控。
明确共同责任： 讨论您应承担哪些 PCI 义务。例如，应询问：“哪些 PCI DSS 要求仍由我们负责？贵方将提供哪些支持，来协助我们满足这些要求？”寻找那些协助承担责任的支付服务商，例如他们可以预先填写 PCI 自我评估问卷或提供详细指导。
您应该向支付服务商询问哪些基本数据保护和隐私方面的问题？
姓名、地址、邮箱和设备 ID 都是敏感信息。优秀的支付服务商会清晰地告知您客户数据的存储位置、保护方式、保留期限以及出现问题时的处理流程。
以下是一些建议您提出的问题。
数据存储与处理位置？
管辖权非常重要。务必请支付服务商明确客户数据存储的国家/地区，并确认是否提供区域托管选项。透明的回答应该能说明具体位置，解释适用的法律框架，并阐述如何处理跨境传输。
如何保护个人数据？
应优先考虑加密、访问控制和监控。务必询问具体的实施方法：静态数据是否采用高级加密标准 (AES) 256 加密，传输中的数据是否采用传输层安全协议 (TLS) 1.2 及更高版本加密，以及是否采用基于角色的最小权限访问原则。同时，详细了解审计日志，包括谁在何时出于何种目的访问了哪些记录。您需要确保每个接触点都有据可查。
您遵守哪些隐私法，有哪些合同提供支持？
支付服务商应明确说明其对欧盟通用数据保护条例 (GDPR)、《加州消费者隐私法案》(CCPA) 及其他相关法律的遵循情况。务必索取符合欧盟通用数据保护条例 (GDPR) 的数据处理协议，并要求提供证据，说明支付服务商如何处理数据主体权利，例如访问权和删除权。如果支付服务商持有相关认证或参与公认框架，建议将其纳入评估范围。
您的留存和删除政策是什么？
请询问支付服务商交易和个人数据的保留期限，以及删除或匿名化数据的流程。重点关注结构化的政策，包括明确的保留期限、自动清除机制以及快速响应删除请求的能力。
谁是您的次级处理商，如何对他们进行审查？
如果支付服务商依赖云服务支付服务商或第三方，应披露其身份，并证明这些合作伙伴同样符合相关标准。有效的回答应包括对子处理商的尽职调查、合同义务以及相关认证。
违约通知流程是什么？
请索取支付服务商的书面事件报告政策，并询问通知时限（数据泄露发生后多少小时内通知您），以及将分享的详细信息。完善的回复应包含沟通渠道的具体信息，以及包含补救措施的事件后报告。
如何在征求建议书 (RFP) 中评估供应商的欺诈预防能力？
每一次未被发现的欺诈事件都会使收入受损并损害客户信任度。每一次阻止合法交易的误报，都会让您损失一笔销售。在讨论欺诈预防时，正确应对的支付服务商应该给出具体说明。例如，支付服务商可能会提到基于数十亿个数据点构建的机器学习模型、可配置的管理平台、具体的欺诈率，以及内置的身份验证流程。此外，支付服务商还应认识到欺诈预防和转化之间存在平衡关系，并展示其如何帮助您进行管理。
以下是您需要确定的内容。
欺诈检测系统
要求支付服务商详细解释其欺诈检测系统。寻找采用分层方法的支付服务商，例如基于大型数据集训练的机器学习、可配置的规则、设备指纹识别、速度检查和行为信号。优秀的支付服务商会将自动评分与人工审查和反馈循环选项相结合。如果支付服务商提到联盟数据（即从多家企业收集的信号），则表明其模型正在从更广泛的领域（您自身交易之外）学习。
例如，Stripe 具有先进的欺诈检测功能。任何银行卡在 Stripe 网络上被识别出来的可能性为 92%，这为欺诈评估提供了更丰富的数据。Stripe 还会安全地共享欺诈评分，以帮助发卡行做出更准确的授权决策。
强客户认证 (SCA)
欺诈控制与身份验证直接相关。要求支付服务商描述其通过何种方式支持 3D Secure、一次性密码和生物识别检查等方法。对于在欧洲运营的企业，这是 PSD2 的一项要求。即使在欧洲以外，高级身份验证对于高风险或可疑交易也是必要的。理想的支付服务商可以启用这些流程，而无需您自行构建。
跟踪指标
应询问欺诈率、撤单率、误报率和批准率等指标。寻找能够在这些指标之间实现平衡的支付服务商：既要保证高批准率，又要实现低欺诈率和尽可能小的用户摩擦。如果支付服务商提供撤单保护或责任转移计划，这表明他们对自身系统有充分的信心。当然，您仍需深入了解支付服务商是如何取得这些成果的。
自定义能力
每个企业的风险承受能力各不相同。有些企业可能追求最大转化率，即使这意味着会面临更多的争议；而另一些企业则可能为了减少欺诈，愿意对更多客户进行额外的验证。因此，请务必询问是否可以自定义欺诈规则、调整风险阈值，以及允许或阻止特定情境。优秀的支付服务商会提供管理平台，您可以在平台上编写规则，例如“标记来自新客户的超过 5,000 美元的交易”，以及“要求来自特定国家/地区的所有首次订单都使用 3D Secure 验证”。这种灵活性体现了支付服务商是否成熟。
例如，Stripe 通过技术文档、对开发者友好的 API、自定义选项、低代码和无代码工具、嵌入式组件以及 Stripe 托管的风控服务，提供简单而灵活的集成体验。
跨方法保护
从数字钱包到先买后付，每种支付方式都存在欺诈风险。您在征求建议书 (RFP) 中应询问支付服务商如何监控这些支付方式。他们是否会验证银行账户、根据制裁名单筛选提现收款人，或者检测账户盗用行为？如果支付服务商仅关注银行卡欺诈，可能会使您在其他方面面临风险。
争议处理
欺诈预防和争议管理息息相关。应询问支付服务商通过何种措施支持撤单响应：他们是否会自动整理证据、提供争议预警，或者针对根本原因进行分析？即使是最好的系统也无法完全避免欺诈，因此，在欺诈发生时，支付服务商限制其影响的能力至关重要。
供应商应提供哪些事件响应与灾难恢复细节？
支付服务商为数据泄露和中断所做的准备工作可以反映其成熟度。支付服务商应具备以下要素：经过测试的事件响应计划、快速的违规通知机制、可衡量的恢复目标、有弹性的基础设施，以及确保您企业及时了解情况的沟通协议。时间表、指标和测试频率可以体现其准备情况。
以下是您想了解的内容：
事件响应计划： 询问支付服务商如何处理安全事件。有力的回答应参考用于检测、遏制、调查和恢复的正式计划。优秀的支付服务商会定期演练或桌面演习来测试这些计划，并在实际事件发生后及时更新。您的合作伙伴应组建一支经过相关流程培训的团队。
违规沟通： 要求提供具体信息，例如：“确认违规后，多久会通知我们？将提供哪些详细信息？”优秀的支付服务商应承诺明确的时间范围（如 24-72 小时），并具体说明将分享的信息，包括范围、受影响的数据、补救措施和持续更新措施。同时，要求对方明确升级路径和联系人，例如，由谁、多久一次以及通过何种渠道与您联系？他们是否会在事件发生后分享问题根源分析？您的支付服务商应将您视为恢复过程中的合作伙伴。
灾难恢复和业务连续性计划： 应询问恢复时间目标 (RTO) 和恢复点目标 (RPO)。这些指标定义了系统恢复速度和可能丢失的数据量。评估具体数字和地域冗余的证据，例如多个数据中心、备用云区域。如果支付服务商无法提供这些详细信息，可能表示他们没有对相关计划进行测试。
备份基础设施： 应询问备用发电机、多家互联网服务支付服务商、自动故障转移机制和持续备份等问题。支付服务商多久测试一次故障转移流程？部分支付服务商会在中断后发布事后分析报告，以展现责任心。这种程度的透明度是信心的标志。
如何在征求建议书 (RFP) 中询问全球合规要求？
如果您的企业在多个市场运营（或计划运营），您的征求建议书 (RFP) 就必须确认支付服务商是否能确保您在所有客户所在地都能合规。最强大的支付服务商会将合规性视为其产品的一部分：他们可能会提到有关 PSD2 的自动化、具体的隐私措施、提现中内置的制裁检查，以及涵盖您关注市场的许可证目录。
以下是您需要询问的内容，以确定合规性是否已整合到您需要的程度。
PSD2 和 SCA
欧盟的 PSD2 指令规定，多数电子支付需进行 SCA 验证。可以向支付服务商询问“贵方如何处理 PSD2 要求，包括 SCA 验证？如何管理豁免？”可靠的支付服务商会确认，他们会在必要时自动应用 SCA 验证，并优化豁免管理（例如，小额购买、受信任的受益人、经常性付款），以减少不必要的障碍。他们应该自动执行这些豁免，而无需您自己编写代码。
数据保护和 GDPR（欧盟通用数据保护条例）
每个地区都有隐私法。您的征求建议书 (RFP) 应要求支付服务商解释他们采用了何种措施来遵守 GDPR、CCPA 和其他数据保护法规。应询问客户数据的存储位置、是否存在区域托管选项，以及他们使用哪些机制进行跨境传输（例如，欧盟-美国数据隐私框架，以及标准合同条款）。应强制要求将符合欧盟通用数据保护条例 (GDPR) 的数据处理协议加入合同中。应找到能够提供认证、审计或独立验证来证明其隐私保护水平的支付服务商。
制裁筛查
在许多国家/地区，强制要求遵守制裁规定。例如，美国外国资产控制办公室 (OFAC) 会在美国执行制裁。如果遗漏制裁检查，可能会导致罚款和声誉受损。因此，应向支付服务商询问“贵方执行哪些制裁筛查（例如，OFAC、欧盟、联合国）？如何阻止或标记受限交易？请描述贵方的制裁筛查流程，包括你们检查哪些列表以及更新频率。”强有力的回答应描述在交易和提现层面执行的自动筛查、持续的列表更新，以及处理匹配项的程序。
地区法规与本地化
不同地区有各自的执行规则，因此您在征求建议书 (RFP) 中应确保自身权益得到保障。请向支付服务商询问：“贵方直接支持哪些区域合规义务，以及如何帮助我们满足这些义务？”优秀的支付服务商会明确表示他们会积极跟踪区域规则。
许可与监管审查
确定支付服务商是否在主要市场持有适当的许可证或注册，这关系到谁承担监管责任，以及您的付款能否顺利进行。应要求支付服务商列出他们持有的监管许可证以及许可证涵盖的区域。
您应该要求支付服务商在加密、令牌化和身份验证方面做些什么？
如果支付服务商无法清楚描述其如何进行加密、令牌化和限制访问，则无需再阅读其提案。您应该看到详细信息：支付服务商应能说明其加密标准，解释令牌化流程，详细描述单点登录 (SSO) 和多重身份验证 (MFA)，限制应用程序编程接口 (API) 密钥，并提及 Webhook 签名。
以下是您的征求建议书 (RFP) 应明确涉及的特性。
加密
要求对传输中和静态的支付数据进行端到端加密。明确要求：传输中的数据采用 TLS 1.2 或 TLS 1.3 加密，静态数据采用 AES-256 或同等加密。应询问支付服务商如何管理密钥，例如是否使用硬件安全模块 (HSM)，是否按计划轮换密钥，以及是否通过职责分离来保护密钥。加密强度取决于其背后的密钥管理。
令牌化
令牌化可以将原始银行卡号从您的环境中移除，并替换为只有支付服务商系统才能解析的随机令牌。务必提出此项要求，例如您可以这样说：“持卡人数据必须进行令牌化，以确保我们的系统不会看到或存储原始数据。” 此外，请询问支付服务商对数据库的保护措施，以及令牌是否可以重复用于经常性收款、订阅或退款。
身份验证与访问控制
请支付服务商详细说明如何保护其平台和 API 的访问安全。对于管理平台的任何管理访问，必须强制实施多因素身份验证 (MFA)。如果能与您企业的身份支付服务商进行了 SSO 集成，将是一个优势。要求支付服务商提供基于角色的访问控制和审计跟踪的详细信息：能否为不同的团队成员分配不同的访问级别？能否跟踪谁在何时做了什么操作？对于 API，要寻找能够确保只有授权系统才能通信的控制措施，例如范围限定的密钥、临时令牌和 Webhook 签名。
面向客户的身份验证
欺诈预防通常与身份验证相关。支付服务商应说明在交易存在风险或法规要求时，如何支持 3D Secure 验证、数字钱包中的生物识别身份验证以及其他增强型验证措施。
如何在征求建议书 (RFP) 中纳入移动端与应用程序内支付安全要求？
征求建议书 (RFP) 应当明确，支付服务商在移动集成中对银行卡数据的保护，需要达到与 Web 端或销售点环境相同的严格程度。这包括详细说明银行卡数据在 SDK 中的流动方式，确保敏感信息不触及应用程序，支持内置钱包，以及提供主动安全测试的证明。移动端支付和任何其他渠道一样，可以做到安全可靠，前提是支付服务商在设计集成方案时充分考虑了安全性。
以下是您在征求建议书 (RFP) 中需关注的问题：
符合 PCI 标准的 SDK： 务必询问支付服务商，其 iOS 和 Android SDK 是否通过了 PCI 合规性验证。强大的 SDK 能够避免原始银行卡数据触及您的应用程序，它们会在设备上加密数据，并直接发送至支付服务商的安全服务器，最终只返回一个令牌。
钱包和平台支持： 务必确认支付服务商是否支持数字钱包（如 Apple Pay、Google Pay、Samsung Pay），并解释设备上生成的令牌在其系统中的流转方式。优秀的支付服务商会强调，真实的银行卡号绝不会离开客户的设备，且生物识别身份验证由钱包自身处理。这是目前最安全的支付方式之一。
设备和应用程序保护： 应询问 SDK 如何应对受损环境。例如，它能否检测到越狱或已 root 的设备？是否能阻止敏感数据记录？以及是否能保护存储在手机上的密钥？理想的回答应详细说明证书锁定、受限存储和运行时检查等安全措施，这些措施可以在不安全的环境下阻止支付行为。
更新和测试： 要求支付服务商解释他们多久更新一次 SDK 以获取安全补丁，以及他们如何测试漏洞，因为移动环境可能会快速发展。关注其定期渗透测试的频率，并了解其是否承诺在新版 iOS 或 Android 系统发布时及时更新。
支付征求建议书 (RFP) 中应要求提供哪些报告和审计功能？
财务、安全和合规团队需要使用报告和审计工具来验证控制措施的有效性，进行对账，并在监管机构提出质疑时做出响应。认真对待报告的支付服务商应详细说明其管理平台、API、可自定义的报告、审计跟踪、合规性认证和警报，包括保留期限、格式和集成等信息。征求建议书 (RFP) 应该能够帮助您了解支付服务商是否能真正提供充分的可见性。
以下是您应该询问了解的特性。
交易与财务报告
关于交易、结算、退款、争议和费用，有哪些可用的报告？报告的格式是怎样的？能否按日期范围、地理位置和支付方式等筛选条件自定义报告？建议寻找实时管理平台和 API，以便您可以将精细的数据提取到自己的系统中。如果您的财务团队无法轻松核对提现和银行存款，后续工作将会更加困难。
系统活动审计日志
成熟平台会跟踪每个敏感操作，如登录、权限变更、API 密钥生成、退款和设置更新。务必要求提供系统事件和用户活动的详细审计日志，并询问日志保留时长以及是否不可篡改。准确追踪操作者和操作时间至关重要，这在内部审计或调查可疑活动时必不可少。
支持外部合规审计
您的审计员可能会要求您提供证据，证明支付服务商确实在按其承诺行事。因此，请询问支付服务商能提供哪些文档，例如 SOC 1、SOC 2、ISO 认证、PCI DSS 证明等，以及如何共享这些报告。部分支付服务商可能会根据保密协议提供这些报告，另一些则可能通过客户门户提供。
实时监控与警报
出色的支付服务商应具备可配置的警报或 Webhook 功能，以便实时通知您异常情况，例如撤单激增、拒付异常集群或 API 错误率上升趋势。 如果没有早期预警系统，团队将无法快速响应。 因此，您的征求建议书 (RFP) 应明确指出，实时指标的可视性是一项必要条件。
数据的可获取性与保留
为了满足金融监管机构的要求，您可能需要多年的交易历史记录和审计跟踪。因此，应询问支付服务商：“报告和审计日志的保留期限是多久？我们能否导出并存档这些数据，以满足我们自身的合规性要求？” 满意的回答是承诺保留多年，并提供简便的方法，让您能将数据导出或同步到您自己的仓库中。
支付服务商在征求建议书 (RFP) 回复中出现的哪些警告信号表明其安全或合规性存在问题？
征求建议书 (RFP) 不仅在于评估书面内容，还在于发现缺失的信息。优秀的支付服务商会给出清晰明确的答案，并提供具体信息和证据。如果未能达到这些标准，您应谨慎对待，并在继续推进前进行深入调查。
以下是您在评估征求建议书 (RFP) 时需要注意的主要警告信号：
含糊不清的措辞： 如果回复中充斥着“最先进的安全性”等模糊说法，但未提及实际标准、协议或认证，则表明该支付服务商可能无法或不愿提供详细信息。负责任的支付服务商会明确提及 PCI DSS、SOC 2、ISO 27001 等标准，以及具体的加密方法和流程。
缺少独立验证： 处理付款业务的支付服务商应接受外部审计。如果一家公司未通过 PCI 认证，或无法提供 SOC 或 ISO 报告，请考虑选择已获得这些认证的支付服务商。
事件响应计划不明确： 征求建议书 (RFP) 应该明确展示具体的时限、经过测试的违规通知计划以及有据可查的恢复方案。如果支付服务商的回应含糊其辞，例如“我们会酌情通知客户”，那么您就无法确保在关键时刻获得及时的沟通。
转移责任： 警惕将重要义务推回给您团队的回复，例如“我们提供工具，但合规性由企业负责”。尽管您始终负有最终责任，但优秀的支付服务商会与您分担责任，并提供明确的支持。
过时做法： 如果提到薄弱或过时的标准（例如用于密码哈希的 MD5、较旧版本的 PCI），则表明其安全性没有与时俱进。您应该期望看到现代加密技术、用于管理访问的多重身份验证，以及与当前 PCI DSS 标准的一致性。
自相矛盾或过度承诺： 如果答案前后不一致（例如，声称从不存储数据，但又说静态数据已加密），则表明该支付服务商粗心大意或内部沟通不畅。在没有证据的情况下保证“零欺诈”或“100% 正常运行时间”同样不可信。
Stripe Payments 能在哪些方面提供帮助
Stripe Payments 提供统一的全球支付解决方案，帮助各类企业（从成长型初创公司到全球企业）在线上线下以及世界各地接收付款。
Stripe Payments 可以帮您：
优化结账体验：通过预构建的支付用户界面、超过 125 种支付方式以及 Stripe 构建的钱包 Link，营造顺畅的客户体验，并节省数千个工程小时。
更快拓展新市场： 覆盖全球客户，并通过跨境支付选项降低多币种管理的复杂性和成本，服务覆盖 195 个国家、支持超过 135 种货币。
统一线下与线上付款： 整合线上与线下渠道，打造统一的商务体验，实现个性化互动、奖励客户忠诚度并增加收入。
优化支付性能： 通过一系列可定制、易于配置的支付工具提升收入，包括无代码的欺诈保护功能与提高授权率的高级功能。
利用灵活、可靠的平台加快发展速度： 基于专为弹性扩展设计的平台运作，历史正常运行时间达 99.999%，享有行业领先的可靠性。
了解关于 Stripe Payments 如何为您的线上与线下支付提供支持的更多信息，或立即开始使用。