存储客户付款详细信息 - PCI 合规性

Posted 2023-02-22

【中文标题】存储客户付款详细信息 - PCI 合规性

【英文标题】：Storing customer payment details - PCI Compliance

【发布时间】：2012-05-21 22:41:19

【问题描述】：

我正在与一位新客户合作开展一个项目，但由于业务类型的原因，他们在获取用于处理在线支付的商家帐户时遇到了一些问题。该系统的工作方式与 Just Eat/Expedia 等类似，客户在网站上下订单，然后将订单传递到场地，网站收取佣金。

客户询问我们是否可以将客户付款详细信息存储在我们的数据库中（加密），然后将它们传递到场所，以便使用他们内部的卡系统自行处理。我知道这存在 PCI 合规性问题，但我无法直接回答我们需要做什么。我与几家托管公司谈过，一家说我们需要一个具有独立 Web 和数据库服务器的集群，而另一家说我们不会。我以前从未做过这样的事情，我通常只是将付款处理外包给 SagePay 等人。

这是建议的付款流程：

客户在网站下订单 付款详情存储在数据库中 客户通过电子邮件收到订单确认。地点通过电子邮件发送订单通知。如果场地接受订单，订单和付款详细信息将被传输以供内部离线处理 场地在内部完成付款后，即确认订单并从网站数据库中删除付款详细信息 通过电子邮件向客户发送最终订单确认邮件

我想确保任何流程都是正确的，我最不想做的就是让网站受到攻击、支付详细信息以及对任何损失负责！

任何建议将不胜感激。

【问题讨论】：

只要信息是加密的，这个过程是正确和安全的。我会更担心手动处理的 pci 合规性。

综合参考资料可在pcisecuritystandards.org获得

我们根本不会与场馆的系统进行任何交互。这个想法是，他们将使用他们目前用于处理场内交易的 Chip & Pin 机器。与34sp.com/business-hosting 之类的人一起托管是否足以完成此过程，还是需要集群？谢谢

@Terry：明确地说，您是说场所将使用 PDQ 终端处理客户不在场的交易，并通过 HTTPS 从您的网络服务器检索交易详细信息？

这是个糟糕的建议，“加密信息”并非易事（要正确执行），它涵盖了与持卡人数据存储相关的大约 1% 的巨额 PCI 义务，记住有大量的卡方案在试图合规之后对违规行为处以罚款。与您的供应商商家提供的托管在线支付解决方案集成将节省您的风险和成本（正确地做到这一点将非常昂贵）。

【参考方案1】：

另一种方法是完全不用您存储信用卡信息，将负担交给有能力和专业知识的其他人，同时让您在必要时轻松向客户收费。 Authorize.Net 提供他们的Customer Information Manager API，它允许您为您的客户创建付款配置文件。他们处理信用卡信息的存储，并为您提供支付 ID。然后，您可以在必要时根据该付款 ID 收费，而无需访问实际的付款详细信息。

【参考方案2】：

你没有包含一个实际的问题......

但是：PCI 合规性并非易事；有多个合规级别，standards 有点密集……一般来说，只要不存储付款明细，就比较容易合规。如果您确实存储了付款详细信息，您的合规要求会变得更加复杂，并且可能包括审查员工等流程。

您将付款详细信息转移到场馆的意图看起来像是一个巨大的危险信号 - 您基本上是在向第三方提供信用卡详细信息，我作为消费者不会对此感到高兴，而且几乎可以肯定在任何情况下都不允许这样做的 PCI 标准。

值得与专业的支付网关提供商讨论您的选项 - 例如，大多数信用卡交易都包含“授权”调用，该调用会提交卡详细信息和金额；该服务检查该卡是否物有所值，并“圈住”帐户上的金额，并发回授权码。实际的“结算”可能会在以后发生——对于某些卡，最长可达 10 天，并且可以只使用授权码，而不是完整的卡详细信息。专业的支付提供商会知道您有哪些选择。

您可能会与您的场所共享授权代码，以允许他们接受付款（尽管这几乎肯定需要你们所有人使用相同的网关提供商）。

更改您提到的流程以包含身份验证/结算逻辑很简单：

客户在网站下订单 您的网站使用信用卡详细信息发出“身份验证”，存储身份验证代码。 客户通过电子邮件收到订单确认。 会通过电子邮件向场地发送订单通知。 如果场地接受订单，您执行“结算”交易 您向场地确认订单详情 通过电子邮件向客户发送最终订单确认邮件 每周/每月/无论您向每个场所发布报告，显示未偿金额并向他们发送支票或其他任何方式。

【讨论】：

还有一个危险信号，我很确定捕获详细信息以供第 3 方处理（即通过不属于您自己的商家帐户）可能会使您进入“服务提供商”级别义务，这使您进入了核心的年度现场审核领域。

@AlexK：没有理由需要捕获数据 - 请参阅我上面的评论。