Is there a GOOD reason many web sites won't accept credit cards with spaces and dashes in them?

Question

Is there a technical/legal/financial/contractual/design reason for not accepting credit card numbers with spaces in them?

So many web sites do not allow you to put spaces or dashes in a credit card number. I've always put this up to sloppy programming, but I've used merchant APIs before. If you can figure out how to process a credit card you can figure out how to strip characters from a string. The designers know they're generating a user frustration because they put a warning right on the web site. They're right there on the card! There's even a wall of shame for this.

False laziness, bad programming, callousness, sadism... all these assume the worst in the person doing the code. The most generous I can come up with is they're being really conservative with anything involving money. I've always wondered if there's some Deep And Really Important reason why you should not accept credit card numbers with spaces in them? Why you should absolutely not try to apply any heuristics. Maybe some bizarre financial law dating back to the telegraph age? Maybe they're unsung heroes, protecting us from some unknown evil lest we type in the credit card number of Hastur three times.

Answer 1

Not everything has a valid reason. I simply think that the first guy who did it didn't allow spaces because it was easier; and then everyone followed and didn't question it.

Answer 2

I don't recall anything in my merchant agreement that stipulated what users had to enter in a form field asking for a credit card number. I don't go to great lengths to normalize it, but I do remove whitespace and hyphens. There are rules about what you can re-display though, but that is merely an amount of content and not the precise form.

You'll see similar things for phone numbers and social security numbers, though, so I don't think it's a credit card number problem.

I mostly think that this is mostly a middleware problem. You have the front-end developed by one group, the backend developed by another, and inbetween there is an off-the-shelf middleware component that nobody likes and everyone has to target. The middleware is written as strictly as possible thinking that it's the responsibility of either side to normalize all data. Then the fingerpointing starts and everyone goes home crying, and you can't use spaces in your credit card number.

Answer 3

There really is no good reason other that laziness or time constraints.

Good UI's should adapt to the user and the multiple ways that users think about their data.

It's easy enough for the UI to adapt to the user entering dashes or spaces in the credit card.

Answer 4

My first answer would be "to reduce the complexity to the absolute minimum", but I guess you could also argue that it obfuscates the data if there is an attack surface somewhere - a dodgy router / sniffer / man-in-the-middle - "xxxx xxxx xxxx xxxx" is almost certainly a credit card number, but "xxxxxxxxxxxxxxxx" could be a number of things. Of course, that won't hold back much determined hacking, and hopefully is largely mitigated by SSL etc.

I stress, I don't think this is a good reason, but it may be a reason...

Answer 5

I think its just a matter of laziness and less programing because one can make it accept with AND without dash. or even make different text boxes for each part(using 4 or 5 small text boxes instead of using a giant text box. or maybe its just because people might get confused

Answer 6

I've always found this very odd since its trivial to remove non-digits from a string.

This is even more confusing, given that each card type (Visa/MC/Amex/Discover) has a unique encoding using check digits. So when I enter a credit card number and select VISA as the card type an intelligent validator will verify that the number IS a Visa number. So, if you're going to correctly validate a CC number, you're going to have to remove non-digits from any user-supplied string.

There's three main reasons I can think of why the card validation is implemented poorly:

• Check digit validation that doesn't anticipate non-numbers.
• A lazy/distressed programmer passes all arguments without pre-validation to a payment gateway and lets the gateway validate the credit card info. A payment gateway is much more rigid with it's argument/data validation then a user interface should be.
• Misapprehension about the imaginary legal ramifications of modifying user-supplied cc data.