【问题标题】:Is it PCI compliant to momentarily save Credit Card in order to pass on to the API and then destroy the field?暂时保存信用卡以传递给 API 然后销毁字段是否符合 PCI 标准?
【发布时间】:2017-08-29 00:56:20
【问题描述】:

我正在尝试确定一种符合 PCI 的方式来将信用卡号传递给支付 API。我能想到的最明显的方法之一是创建一个局部变量来接受来自用户的 CC#,传递给 API,然后销毁该变量。

之后,我将存储该客户的标记化信息,这没有 PCI 负担。我的主机符合 SSL 和 PCI 标准。

关于什么是“接受”CC# 以便将其“传输”到 API 的安全方法有什么建议? (PS:像 Braintree 或 stripe 这样的网关对我来说不是解决方案...由于多种原因,可能更适合稍后再讨论!)

【问题讨论】:

  • 不确定您所说的“保存”是什么意思,但显然允许将 CC 数据暂时保存在变量中。你还能怎么做?但如前所述,它确实将您的系统置于完全外包的“范围内”。
  • “你还能怎么做?” :除了保存变量之外,还有一种完善的方法可以做到这一点,称为“直接发布”或“表单发布”。但是,是的,即使是片刻的存储 CC 也确实将解决方案置于 PCI 合规性的“范围内”。
  • 我认为这些都是“完全外包”的例子。

标签: payment-gateway credit-card pci-compliance pci-dss


【解决方案1】:

如果该信用卡信息曾经访问过您的系统,则您属于 PCI 范围。您需要使用直接提交给支付网关的表单,以避免属于 PCI 范围。

Authorize.Net 提供了一些这样的例子,包括 SIM、Direct Post MethodAccept HostedAccept.js。您需要检查您使用的支付网关是否提供类似的功能。

【讨论】:

  • 感谢您的中肯回答!我的处理器不为应用内支付提供任何托管字段。他们只提供一个托管支付页面(一个 iframe),该页面在 webapps 上效果很好,但在 iOS 和 Android 中变得相当不可靠。 (该处理器的技术人员提到我将需要利用 SignalR 库来完成此操作,无论是在应用程序内还是在网站中。在网站中,实施很容易,因为有由 Microsoft 维护的标准 SignalR 库,但用于在应用内,SignalR 库是社区资源,维护不善)
  • 我正在考虑要求处理器执行以下操作之一: 1. 如果它们可以单独托管字段(而不是在 iframe 中一起托管)。 2)如果他们可以在他们的服务器(而不是我们的)上创建一个 CC# 字段,我们只需将数据发布到它......类似于直接发布方法
猜你喜欢
  • 1970-01-01
  • 2016-08-06
  • 2020-07-12
  • 2015-01-12
  • 2016-12-21
  • 2017-10-01
  • 2011-10-31
  • 2016-01-06
  • 1970-01-01
相关资源
最近更新 更多