存储信用卡信息

发布于 2024-11-03 09:29:11 字数 757 浏览 0 评论 0原文

所以我知道有很多关于存储信用卡信息的帖子。我们正在构建一个移动应用程序,希望人们能够输入一次卡信息,而不是每次购买时都输入。

我们研究了 Authorize.net CIM,它似乎是一个理想的解决方案(我们只是存储返回信用卡号的配置文件 ID 或令牌)...但它可能达不到我们的需求,因为信用卡信息不是由authorize.net(必然)处理的,而是由我们的任何商家帐户处理的。也在发送付款。换句话说,我们希望像钱包一样存储信用卡信息...不一定每次都使用 Authorize.net 进行处理。

阅读 CIM XML 文档(第 94 页),看起来 getCustomerPaymentProfileResponse 掩盖了信用卡返回数据...所以我不知道如果数据被屏蔽,这对于处理有何用处?

我们确实有一些其他的实施选项,但我真的希望有一种基于网络的方式让客户管理他们的支付帐户。有谁知道有什么方法可以存储可以按需调用并传递给任何给定商家的处理器的信用卡数据吗?

编辑 2011 年 4 月 28 日 - 我遇到了麻烦。如果我们根本不存储信用卡信息,让客户输入然后传递它怎么办……我们如何安全地做到这一点?不存储它、传递 HTTPS、在传输过程中加密卡数据?

So I know there have been numerous posts about storing credit card information. We are building a mobile application and want people to be able to enter in their card information once, not with each purchase.

We looked at Authorize.net CIM, and it appears to be an ideal solution (we just store a profile ID or Token that returns the credit card number)... but it might fall short of our needs, since the credit card information isn't processed (necessarily) by authorize.net but by whatever merchant account we are sending the payment too. In other words we want to store the credit card information like a wallet... not necessarily process with Authorize.net every time.

Reading the CIM XML documentation (p.94), it looks like the getCustomerPaymentProfileResponse masks the credit card return data... so I don't see how that would be useful for processing if the data is masked?

We do have some other options for implementation but I was really hoping to have a web-based way for customers to manage their payment accounts. Does anyone know of any ways to store credit card data that can be called on demand to be passed to any given merchant's processor?

EDIT 4.28.2011 - I'm hitting a wall with this. What if we don't store the credit card information at all, have customers enter it and then pass it... how do we do that securely? No storing it, pass along HTTPS, encrypt card data while in transit?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

要走干脆点 2024-11-10 09:29:11

遗憾的是,没有简单的方法可以实现这一目标。

如您所知,支付服务提供商将安全地存储卡详细信息,并返回令牌 ID(以便您可以参考这些详细信息),但他们永远无法将原始卡详细信息返回给您。

这是因为 PSP 将通过 PCI-DSS 合规性。该合规性的一部分是确保卡详细信息传递到的任何地方(例如传递给其他第三方)符合 PCI-DSS。如果他们允许将卡详细信息从保险库返回给客户端,那么他们需要确保客户端也符合 PCI-DSS 标准(这几乎会破坏客户端的初衷)使用支付服务提供商!)。

因此,您的选择是:
- 遵守 PCI-DSS 合规性,以便您可以自己安全地存储卡详细信息。
- 将卡详细信息存储到与您交互操作的每个支付服务提供商,并存储每个支付服务提供商返回的令牌。

Sadly, there is no easy way to achieve this.

As you are aware, Payment Service Providers will securely store the card details, and return a token id (so that you can reference those details), but they can never return the original card details back to you.

This is because the PSP will have gone through PCI-DSS compliance. Part of that compliance is ensuring that anywhere the card details are passed (such as to other 3rd parties) is also PCI-DSS compliant. If they were to allow card details to be returned from the vault to the client, then they would need to ensure that the client is also PCI-DSS compliant (which would pretty much defeat the point of the client using a Payment Service Provider!).

Your options therefore are:
- Work through PCI-DSS compliance so that you can store the card details securely yourself.
- Store the card details to every Payment Service Provider that you interoperate with, and store the returned tokens from each.

七色彩虹 2024-11-10 09:29:11

Stripe 就是这样做的。他们会处理卡的详细信息,而您无需存储它们,并向您返回代表信用卡的令牌,然后您可以:

  • 一次性收费,或
  • 保存为“客户”,然后在将来计费,根据需要,或者以自动重复的方式

有一个很好的 RailsCast 来计费值得一试的条纹。对开发者非常友好。

Stripe does something like this. They process the card details without you ever needing to store them and give you back a token representing the credit card, which you can then:

  • either make a one time charge on, OR
  • save as a 'customer' and then bill in the future, either as needed, or in a automatically recurring way

There's a good RailsCast on billing with Stripe that's worth checking out. Very developer friendly.

抱猫软卧 2024-11-10 09:29:11

编辑
我刚刚意识到 Authorize.Net CIM 是一种标记化服务。所以你可能知道其中的大部分内容。不过,我会将这篇文章留在这里 - 它可能对其他人有用。

如果这些商家/供应商愿意改变他们的 API,我会研究卡标记化。这是某些处理商提供的一项功能,可让您无需卡号即可进行付款。其工作方式是在用户将其卡信息交给处理器的第一笔交易中,处理器将令牌传回商家,该令牌唯一地标识该用户和持卡人的数据。商户,用户的卡数据由处理器内部存储。

然后,您可以存储这些令牌并将其传递给供应商支付应用程序,供应商支付应用程序又将使用它们来处理交易。我假设这些令牌对于特定商家来说是唯一的,因此您可能必须为特定用户的每个供应商/商家存储 1 个令牌。

可能有这样的规则,供应商/商家不能代理代币或以其他方式从第三方获取代币。如果是这种情况,您的供应商可以提供一个新的令牌/guid,该令牌/guid 映射到他们内部存储的令牌,以便与卡处理器一起使用...

Google - 信用卡令牌化

PCI 标准

PCI-DSS 不是开玩笑,虽然这些商家/供应商在技术上不需要向他们披露处理器认为您的应用程序正在存储卡号,但如果他们确实披露了它可能会变得混乱。以下两种情况都可能发生:

  • 供应商可能被迫阻止您的应用程序使用 API
  • 您的应用程序必须通过 PCI 认证

Edit
I just realized Authorize.Net CIM is a kind of tokenization service. So you're probably aware of most of this. I'll leave the post here though - it maybe useful for somebody else.

If these merchants/vendors are willing to alter their API, I'd look into card tokenization. It's a feature offered by some processors that lets you transact payments without a card number. The way this works is on the first transaction the user hands their card info to the processor, which passes back a token to the merchant which uniquely identifies the cardholder data for that user & merchant, and the user's card data is stored internally by the processor.

You could then store these tokens and pass them to the vendor payment applications, which would in turn use them to process the transactions. I assume these tokens would be unique to a specific merchant, so you would probably have to store 1 token per vendor/merchant for a specific user.

There maybe a rule about this, where the vendor/merchant can't proxy tokens or otherwise get them from a third party. If that is the case, your vendors could supply a new token/guid that maps to the token they store internally for use with their card processor...

Google - credit card tokenization

PCI Standards

PCI-DSS is no joke, and while these merchants/vendors don't technically need to disclose to their processor that your application is storing card numbers, but if they do disclose it could get messy. Either of two things could happen:

  • The vendor could be forced to prevent your application from using the API
  • Your application would have to go through PCI certification
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文