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

Question

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

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

这是建议的付款流程：

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

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

任何建议将不胜感激。

Answer 1

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

Answer 2

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

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

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

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

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

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

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