【问题标题】:PCI Compliance. Pass credit card information to a 3rd party APIPCI 合规性。将信用卡信息传递给第 3 方 API
【发布时间】:2017-07-02 20:50:07
【问题描述】:

我有一个应用程序要求提供信用卡信息以向第三方公司付款。

我的应用程序捕获 CC、CVV、到期日期等,然后将这些信息传递给向客户收费的 API。

我一直在阅读有关 PCI 合规性的信息,但根据下图,我不太确定我需要达到什么级别的合规性。

最后,如果我从同一个客户那里购买新产品,我想知道什么是最适合我的选择。由于我没有向客户收费,但第三方收费,存储支付信息的最佳方式是如何让用户在每次想要使用我的服务时都不需要输入他的信息?从 PCI 合规性的角度来看,将支付信息存储在我的服务器上会有什么影响?有没有一种方法可以让我不需要为用户存储付款信息,但我可以将他们的信息(如果他们是回头客)传递给第 3 方 API 并且仍然符合 PCI 合规性?

【问题讨论】:

  • 当您说“应用程序”时,您是指网站、内部业务应用程序还是手机应用程序?这很重要。
  • 这是一个嵌入在 Facebook messenger 上的网络应用程序

标签: e-commerce stripe-payments pci-compliance pci-dss


【解决方案1】:

由于您正在构建一个 Web 应用程序(甚至嵌入到 Facebook Messenger),如果您正在构建收集卡片数据的表单,您将要么属于“购物车 - 付款页面直接发布”(这是 A-EP)或“购物车 - 付款页面未外包”(即 D-Merchant)。如果可以,您真的想加入 A-EP,但你可能做不到。

两者的区别在于卡片数据是否通过您的服务器。使用“Direct Post”,网页本身将数据(通常通过 HTTP POST)发送到支付 API,而您无法捕获它。使用“未外包”,数据返回到您的服务器,然后调用支付 API 并将其传递。在这种情况下,您将不得不完成整个 D-Merchant 问卷(迄今为止最长的,除了 D-Service Provider),并且可能设置了一个特殊的环境来防止任何人试图读取卡片传输您的服务器时的数据。

实际上没有值得存储的卡数据部分来尝试识别重复购买者,因为您没有支付数据来实际完成支付。相反,您应该查看您的支付提供商是否提供任何类型的“token”,以便以后识别该支付数据。如果是这样,您可以将该令牌与客户相关联(无论您如何识别客户)并在他们返回时重新使用它。

延伸阅读:https://www.pcisecuritystandards.org/documents/SAQ_InstrGuidelines_v3-1.pdf

【讨论】:

  • 然后我会更容易使用诸如条带之类的第三种API来避免构建我自己的表单然后属于A(或A-EP)类别吗?我将与第三方 API 公司核实他们是否可以在完成付款后向我提供某种令牌,以便我可以将其用于将来的付款,而无需每次都询问用户付款信息。 (为此,我需要将令牌映射到您指出的给定用户)谢谢!
猜你喜欢
  • 1970-01-01
  • 2019-10-29
  • 2013-09-25
  • 2017-02-07
  • 2012-05-21
  • 2020-05-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多