电子商务最佳实践：对于被拒绝的信用卡，多少信息算太多？
我的同事们正在争论如何具体处理被拒绝的信用卡交易。我们从卡处理器获得了有关交易的大量详细信息，并且我们正在尝试决定向用户传递多少信息。
例如，您是否告诉用户他们的卡因过期或 CCV 号码错误而被拒绝，或者其中是否存在太多欺诈潜力？当我们将用户返回到他们提供付款详细信息的页面时，我们是否会使用他们之前输入的数据预先填写字段？
My colleagues are having a debate as to how specific to be for credit card transactions that were declined. We get a lot of details about the transactions from our card processor, and we're trying to decide how much info to pass on to the user.
For example, do you tell the user that their card was declined because it's expired or the CCV number is wrong, or is there too much fraud potential in that? And when we return the user to the page where they provide payment details, do we pre-fill in the fields with the data they entered previously or not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
大约 4 年前，我参加了一次 PCI 合规性审查，当时的政策是简单地向用户返回“已接受”或“已拒绝”以及交易 ID。如果交易被拒绝，我们会添加一条注释“有关更多信息，请联系您的信用卡提供商并引用此号码......”。
原因是，如果有人尝试生成卡号，您不想向他们提供任何有关如何更改以获得有效卡的信息。如果是真人，交易中出现的问题太多，您无法修复，只需告诉他们联系他们的卡提供商即可。即使交易响应是“卡已过期”，也可能是其他内容，您不知道，所以不要猜测。
另外，如果您返回带有付款字段的页面，请不要预先填写它们，请将其留空。客户可能会偏执地想“嘿，这东西记住了我的信用卡信息吗！？”该卡被拒绝的最可能原因是他们输入了错误的内容，并且通过再次预先填写错误的信息，您只会诱使他们一遍又一遍地单击“提交”，直到超出他们的信用额度。去过那里，做过那件事。
I participated in a PCI Compliance review about 4 years ago, and the policy then was to simply return an Accepted or Rejected, and the transaction ID to the user. If the transaction was rejected we added a note "For more information contact your credit card provider and quote this number ...".
The reasoning is that if someone is trying to generate card numbers you don't want to provide them any information as to what to change to get a valid card. If it is a real person, there are too many things that go wrong with a transaction you are in no position to fix, just tell them to contact their card provider. Even if the transaction response is "Card Expired" it could be something else, you don't know so don't guess.
Also, if you return to a page with payment fields, don't prefill them, leave them blank. Customers might go paranoid thinking "Hey, is this thing remembering my credit card info!?" The most likely reason the card was rejected is that they typed something in wrong, and by prefilling it with the wrong info again you are just tempting them to click Submit over and over again until their credit limit is exceeded. Been there, done that.
过去，我提供了尽可能多的信息，并让人们尽可能容易地纠正。不想停止潜在的销售（或者在我的例子中是捐赠）。至于处理欺诈问题，不要试图通过指望给他们提供错误的 CCV 号码来减缓他们的速度，而是以其他方式处理，例如跟踪会话尝试处理卡的频率（并且失败），如果在 X 时间内出现太多次，请将其列入黑名单。但这是一个单独的问题。
In the past I have given as much information as possible and made it as easy for someone to correct as possible. Don't want to stop a potential sale (or in my case donation). As for dealing with fraud, don't try to deal with it by hoping that cluing them into a bad CCV number is going to slow them down, deal with it in other ways, like tracking how often a session is attempting to process a card (and failing), if it is too many times in X amount of time, blacklist them. That is a separate question though.
过去我尝试尽可能笼统。例如，如果您告知 CVV2 号码不正确。当然，这可以让有效持卡人知道 CVV2 不正确，从而帮助他们摆脱困境。它还会让不法分子知道信用卡号是正确。如果他们确实一直失败，也许你会提示他们联系某人。
当您谈论预填充字段时，是在谈论失败后重试还是在完全单独的场合？
如果是在他们失败之后，在我看来，安全的方法是不再显示它，但您需要确保他们无法单击返回并获取相同的信息，否则就没有意义。不过，这可能并不那么重要。
如果您正在谈论一个完全独立的场合，您需要在某个地方存储该信息。如果它在您的服务器上，我建议您查看PCI-DSS。即使您只是将数据传输到网关，您也需要遵守规定。
In the past I have tried to be as general as possible. For example, if you tell that the CVV2 number is incorrect. Sure, that helps the valid cardholder out by letting them know it's the CVV2 that's incorrect. It also lets an undesirable know that the credit card number IS correct. If they do keep failing perhaps you prompt them to contact someone.
When you are talking about pre-filling fields are talking about after they fail and retry or on a completely separate occasion?
If it's after they have failed it seems to me that the secure way to do it would be to not display it again, but you would need to make sure that they couldn't click back and get the same info, otherwise there's no point. It might not matter that much, though.
If you are talking about a completely separate occasion you need somewhere to store that info. If it's on your servers I suggest you have a look at PCI-DSS. Even if you just transmit the data to a gateway you are required to be in compliance.