logo标签列表

存储信用卡信息

payment-gatewaypaymentcredit-cardpci-dss
8
我知道有很多文章关于存储信用卡信息。我们正在开发一个移动应用，希望用户只需输入一次卡片信息，而不是每次购买都要重新输入。
我们看了Authorize.net CIM，它似乎是一个理想的解决方案（我们只需存储返回信用卡号码的个人资料ID或令牌）...但它可能无法满足我们的需求，因为信用卡信息并不一定由Authorize.net处理，而是由我们发送付款的任何商家账户处理。换句话说，我们想像钱包一样存储信用卡信息...而不是每次都必须通过Authorize.net处理。
阅读CIM XML文档（第94页），看起来getCustomerPaymentProfileResponse掩盖了信用卡返回数据...所以如果数据被掩盖，我不明白它如何有用于处理？
我们确实有其他的实现选项，但我真的希望有一种基于Web的方式让客户管理他们的付款账户。有人知道任何存储信用卡数据的方法，可以随时调用并传递给任何给定商家的处理器吗？
编辑4.28.2011 - 我在这方面遇到了难题。如果我们根本不存储信用卡信息，让客户输入并传递它...我们如何安全地做到这一点？不存储它，通过HTTPS传递，加密卡数据在传输过程中？
是的，我同意Sony的事情非常及时。我不想将这些信息存储在我们的数据库中... 在我看来，这样做太冒险了。 - Nick
仅仅是一个建议。请勿将此信息存储在手机本身上。如果您将其存储在网站上，以便客户可以管理客户档案，请确保投资于SSL证书。我甚至会建议只收集所需的信息，这样您的公司就不会发生像索尼那样的事情。 - Security Hound
关于你的问题，老实说我会直接联系Authorize.net的支持人员。除非必须，否则不要存储完整的信用卡信息。确保只允许客户选择保存信息。我一直认为大多数供应商在第一次交易后处理此类信息时仅存储授权号码。 - Security Hound
是的，问题在于我们将与几个不同的供应商集成...这实际上取决于应用程序的使用位置。所以我真的只需要存储部分，而不是处理部分。 - Nick
1
如果是我，我会与您的处理器一起工作。例如，如果您通过Authorize.net处理交易，那么这个解决方案听起来很理想。而且您的处理器可能有特定的要求，所以我建议您联系他们。 - Jonathan Wood
很遗憾，除非我们在每个可能的处理器中存储客户的信用卡信息，否则这对我们的商业模式不起作用...即使如此，我也不知道是否可行，因为我们甚至不是账户的主要管理者。 - Nick
3个回答
8
很遗憾，没有简单的方法可以实现这一点。
如您所知，支付服务提供商将安全地存储卡详细信息，并返回令牌ID（以便您可以引用这些详细信息），但他们永远不能将原始卡详细信息返回给您。
这是因为PSP将经过PCI-DSS合规性。该合规性的一部分是确保卡详细信息传递到的任何地方（例如其他第三方）也符合PCI-DSS合规性。如果他们允许从保险库向客户端返回卡详细信息，则需要确保客户端也符合PCI-DSS合规性（这几乎会使客户使用支付服务提供商的目的失败！）。
因此，您的选择是： - 通过PCI-DSS合规性来安全地存储卡详细信息。 - 将卡详细信息存储到您与之交互的每个支付服务提供商，并存储每个提供商返回的令牌。
3

Stripe会执行类似的操作。他们可以在你无需存储信用卡信息的情况下处理卡片细节，并返回代表信用卡的令牌，然后你可以：

  • 要么进行一次性收费，
  • 将其保存为“客户”，然后在未来按需要或自动循环的方式进行账单结算。

有一个关于使用Stripe进行计费的RailsCast非常值得一看。非常适合开发人员使用。

同意 - 就开发友好性而言，这是我们使用过的最佳解决方案。我们已经将其用于捐赠、循环收费，甚至为一次性和循环收费不是由客户启动SAAS的完整客户计费系统。他们的API有一些假设，使得某些功能更加困难 - 但总体来说，这是我们集成过的最简单和最可靠的。令牌身份验证目前是最好的选择。 - Mary Camacho
他们允许您将信用卡详细信息放在类似于Authorize.net CIM的托管弹出窗口中吗？ - Kunal
1

编辑
我刚刚意识到Authorize.Net CIM是一种令牌化服务。所以你可能已经了解了大部分内容。但我还是将这篇文章保留下来，因为它可能对其他人有用。

如果这些商家/供应商愿意修改他们的API，那么我建议你考虑使用卡片令牌化功能。这是一些处理器提供的功能，可以让你在没有卡号的情况下进行交易。它的工作原理是，在第一次交易时，用户将其卡信息传递给处理器，处理器会返回一个标记（token）给商家，该标记唯一地识别了该用户和商家的持卡人数据，并且用户的卡数据由处理器内部存储。

然后，你可以存储这些标记并将它们传递给供应商支付应用程序，供应商支付应用程序再使用它们来处理交易。我想这些标记会针对特定商家而唯一，因此你可能需要为每个供应商/商家存储1个标记。

可能会有一条规则，即供应商/商家无法代理标记或从第三方获取标记。如果情况如此，你的供应商可以提供一个新标记/guid，该标记/guid映射到他们内部存储的用于与卡处理器一起使用的标记。

谷歌-信用卡令牌化

PCI标准

PCI-DSS并不是闹着玩的，虽然这些商家/供应商从技术上讲不需要向其处理器披露您的应用程序正在存储卡号，但如果他们确实披露了，可能会变得混乱。事情会有两种可能：

  • 供应商可能被迫阻止您的应用程序使用API
  • 您的应用程序将必须通过PCI认证。
谢谢...我后来发现分词是同样的事情。我联系了几个供应商，他们大多同意PaulG的评论，即我们需要通过他们的商家账户进行处理。我可能需要考虑另一种处理方式。 - Nick
你提出的想法很棒，祝你好运！我唯一能预见到传递这些令牌可能出现的问题就是如果这些令牌被攻击者入侵并从你的应用程序之外或在没有经过认证的上下文下被商家接受，那么攻击者最坏的情况就是以该令牌绑定的送货/账单地址，购买和发送给我一些我不想要的东西- 这可能是不好的- 我会感到沮丧- 但它比窃取信用卡数据更不严重。 - HAL9000
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接