11

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.

skaffman
  • 398,947
  • 96
  • 818
  • 769
Schwern
  • 153,029
  • 25
  • 195
  • 336
  • 2
    Well, it can't for sure be bandwidth restrictions. – Cecil Has a Name Dec 13 '09 at 20:23
  • 7
    I think the definition of "programming related" around here is getting a little fascist. Issues that aren't directly related to the technical aspects of programming but are clearly things that lots of programmers need to deal with in the course of their jobs have a legitimate place on SO. This clearly is programming related by any reasonable definition as he's trying to figure out why websites are **programmed** the way they are. – dsimcha Dec 13 '09 at 21:37
  • 3
    Please reopen. See: http://meta.stackexchange.com/questions/5018/describing-close-reasons "not programming related": "Questions on stackoverflow.com are expected to generally relate to programming. This question is very far afield from programming.".. Saying that this question is *VERY FAR AFIELD* is ridicolous. – Andreas Bonini Dec 13 '09 at 21:47
  • 4
    Oh come now, not programming related? A question about why programmers program programs to do what they do? – Schwern Dec 13 '09 at 23:26
  • While I voted to reopen, this is very argumentative (esp. at the end) and UI design, at best, flirts suggestively with not-programming-related, both of which question the value to SO. (Even though this doesn't seem subjective, I wonder how many votes the S&A close reason got originally.) –  Feb 06 '10 at 21:46
  • 2
    @Roger That one might not consider interface design as programming related is possibly why so many programs have terrible interfaces. ;) Anyway, there's over 700 questions tagged "user-interface" so somebody thinks its valuable to SO, but it only takes 5 to think its not. I do not like the 5-person question veto the closing system creates. – Schwern Feb 07 '10 at 09:09
  • 1
    @Schwern: I agree you have to decide some things individually, and as I said, I voted to reopen because this question falls on the 'valuable' side, but if you could edit it to be less of a rant, that would be an improvement (at least as a SO question, what you have would make a fine entry on your blog). –  Feb 07 '10 at 09:28

6 Answers6

8

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.

Jeffrey Hines
  • 1,766
  • 1
  • 13
  • 16
  • 1
    Yeah, it's just sucky UI. Lump it in with address fields that don't expect you to add commas after the names so you end up with double commas. And date fields that that force you to type "02 09 2009" when 2 9 09 would be just as meaningful and correct. And pages that forget half the details you typed if you get any of the above "wrong". – Jason Williams Dec 13 '09 at 20:45
1

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...

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • Of course that processing could (and should in this case) be done client side, so the formatted version never leaves the machine... But I think sending credit card numbers in plaintext at all is outrageous. – KernelJ Dec 13 '09 at 20:29
  • @KernelJ - who mentioned plaintext? I said SSL. – Marc Gravell Dec 13 '09 at 20:31
  • If your dodgy router is generating valid credit card numbers, put it on EBay and retire. :P – Schwern Dec 13 '09 at 21:00
  • @KernelJ - even if the client-side validates the CC number the server side still needs to run the same validation. You can't control every possible client, but you an control your own server / code. – leepowers Dec 13 '09 at 21:15
0

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.

Andreas Bonini
  • 44,018
  • 30
  • 122
  • 156
0

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.

brian d foy
  • 129,424
  • 31
  • 207
  • 592
-1

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

Reza
  • 1
  • 1
  • 1
    Oooh, individual boxes is more evil than good due to the disparity in length and layout of credit card numbers. An AmEx card, for example, uses 3 groups. I'm sure you could come up with some sort of clever Javascripty thing that changed the box layout based on the credit card type, but I'm sure you're going to leave some users who won't think to set the type before the number puzzled. – Schwern Dec 13 '09 at 21:04
-1

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.
leepowers
  • 37,828
  • 23
  • 98
  • 129
  • 2
    Actually, the check digit stuff isn't different across cards. Almost all of them use the Luhn algorithm (and that doesn't encode anything). You can tell valid card numbers apart by the first digits, sometimes even identifying the issuing bank. – brian d foy Dec 13 '09 at 21:50