代码之家 › 专栏 › 技术社区 › Schwern

许多网站不接受带有空格和破折号的信用卡有什么好的理由吗[关闭]

payment credit-card validation

Schwern · 技术社区 · 15 年前

许多网站不允许你在信用卡号上加空格或破折号。我总是把这归咎于草率的编程,但我以前使用过商业API。如果你知道如何处理信用卡,你就可以知道如何从字符串中去掉字符。设计师们知道他们正在给用户带来挫折,因为他们在网站上贴了一条警告。它们就在卡片上!甚至还有一个 wall of shame 为了这个。

虚假的懒惰,糟糕的编程,麻木不仁,虐待狂。。。所有这些都假设编写代码的人最糟糕。我能想出的最慷慨的办法就是 真正地 任何涉及金钱的事情都很保守。我一直在想,你不应该接受信用卡号中有空格,是否有一些深层次的、真正重要的原因?为什么你绝对不应该尝试应用任何启发法。也许是电报时代的一些奇怪的金融法?也许他们是无名英雄,保护我们远离未知的邪恶,以免我们三次输入Hastur的信用卡号。

6 回复 | 直到 15 年前

Jeffrey Hines 15 年前

除了懒惰或时间限制之外,真的没有什么好的理由。

用户界面很容易适应用户在信用卡中输入破折号或空格。

Marc Gravell 15 年前

我的第一个答案是“将复杂性降至绝对最低”,但我想你也可以说,如果某个地方存在攻击面,它会混淆数据-一个狡猾的路由器/嗅探器/中间人-“xxxxxxxxxxxxxxxx”几乎肯定是一个信用卡号码,但“XXXXXXXXXXXXXXXXXXXXXX”可能是很多东西。当然,这不会阻止太多坚决的黑客攻击,而且 有希望地

我强调,我不认为这是一个原因,但它可能是 A.

brian d foy 15 年前

我不记得我的商户协议中有任何规定,规定用户必须在表单字段中输入哪些内容以请求信用卡号。我并没有尽全力规范化它,但我确实删除了空格和连字符。不过,对于可以重新显示的内容有一些规则,但这只是内容的数量,而不是确切的形式。

你会在电话号码和社会保险号码上看到类似的情况,所以我不认为这是信用卡号码的问题。

我认为这主要是一个中间件问题。前端由一个组开发,后端由另一个组开发,中间有一个现成的中间件组件,没有人喜欢,每个人都必须瞄准它。中间件的编写尽可能严格,认为规范化所有数据是任何一方的责任。然后指指点点开始,每个人都哭着回家,你不能用信用卡号上的空格。

Andreas Bonini 15 年前

-1

Reza 15 年前

我认为这只是一个懒惰和少编程的问题,因为你可以让它接受,不管有没有破折号。甚至为每个零件制作不同的文本框(使用4或5个小文本框,而不是使用一个巨大的文本框)。或者只是因为人们可能会感到困惑

-1

leepowers 15 年前

我总是觉得这很奇怪,因为从字符串中删除非数字很简单。

考虑到每种卡类型(Visa/MC/Amex/Discover)都有一个使用 check digits

我能想到卡验证实施不佳的三个主要原因:

懒惰/苦恼的程序员将所有参数无需预先验证就传递给支付网关,并让网关验证信用卡信息。支付网关的参数/数据验证要比用户界面严格得多。
对修改用户提供的cc数据可能产生的法律后果的误解。