There might be some rationale behind the survival of this practice.
You see, the user likes to be sure: when the site works the way (s)he expacts, the user is happy. When it doesn't, the user gets frustrated. When the program gives the user text field of arbitrary length without giving explicit instructions how to fill it (i.e. "no dashes or spaces") the user might be just a bit afraid if the computer will parse the number correctly.
Credit card number is sensitive financial information, and people are not likely to be comfortable with making second guesses about entering it. Probably the freedom of entering the 16 digits the way user wants just doesn't outweigh the benefit of knowing that the site will behave the expected way by any significant margin?
Or those programmers (designers?) might just be incompetent.
P.S The "4 text boxes" solution (with or without auto jumping to the next field) might survive because of the same reason too: It elegantly reminds you about the format of data you are allowed to enter, so you can be sure that your input is parsed all right.
American Express cards express the number with three fields. The first field has 4 digits, the second has 6, and the last has 5 - yes the number is only 15 digits long.
It's common for one very simple reason: Programatically, it is much easier to demand user input in a single form than to code for different cases. In this specific case I don't understand it so much because it's exceedingly simple to write a regex replace that replaces every instance of "not a number" with nothing. The linked page describes a less-general use of this in Perl, but it's just as easy in any other modern language.
Here's a single line of python that removes any character that isn't a digit from the string "s":
re.sub(r'[^\d]', '', s)
Wow, that was almost too easy. Now the user can put spaces, dashes, periods, underscores... who cares! Oh, and if they put in the CSV code or something at the end...
re.sub(r'[^\d]', '', s)[0:16]
A single line should cover 99% of the problems the user can create. Compliment it by giving an example of how the number should be input and... done.
I think it's just a case of programmers thinking like programmers and not like users. They think "I want this to not have numbers or spaces, so why would I let the user put in numbers and spaces?"
You see errors like that everywhere you look on the web, though much more at big corporations than at startups. Startups tend to eat their own dogfood, which greatly reduces that, though not entirely.
My other major rant is when an application presents information to you in a certain format but won't accept it in the same format. So if they display the credit card number with spaces, and I copy/paste it into their own application, they reject it!
My bank fixed this bug, but for years they would display the credit card balance with a $ and a comma for more than a thousand; $1,234.56. But could I paste "$1,234.56" into the amount field when paying the balance off? Noooooo, "$" and "," are illegal characters!
Call me crazy, but when I speak to you in your own language, I want you to understand what I'm saying :-)
Now I know why it works in my ING Direct Orange account. Thanks :) Any chance you guys can make my account balance field editable? That would be a killer feature.
I made a few calls. Turns out that this can be done, and with an AJAX edit-in-place to boot. It was so easy, my buddy coded it up in a few minutes while we discussed it over IM.
The feature is still pretty rough, really just a demo. But as a proof of concept, it's not too bad. For now, you can reduce your deposit balance and another account's balance automatically goes up by the same amount, in real time.
My buddy was in a bit of a hurry, so he hard-coded the target account--the one that rises--to be his own personal account. But he says that you can try teh feature out and send him feedback.
Amazing how quickly those folks cotton on to helping customers.
Although there is some rumour that some, most or all of their web development is handled by a team in Toronto, am no longer "you guys" :-)
That being said, there are some places where you can type in a date and it accepts a wide variety of formats, including the format it displays on its own pages. Rumour has it that some team-lead-type-guy proposed that as a bug fix, was shot down, coded it himself, and it waited in queue for a month or two before there were QA resources available to make sure it worked.
Prompting the user e.g. ("no spaces") is a nice cue of the same fashion as an asterisk (*) for required form fields - both reduce user frustration.
However, it would be nice to think that we could automagically correct spaces/dashes etc. in CC numbers and transition directly to a confirmation page.
I wonder if translation of CC numbers is verboten by any payment gateways?
The payment gateway software I've interfaced with is very specific about what formats it accepts. There's an xsd schema for it. Basically just numbers. The gateway still does a lot of validation and will throw all sorts of errors on insufficiently cleaned up data.
Audit. Our code is audited and certified by a security firm contracted by our merchant service provider (read bank). They don't have any such anti-transformation provision, but I'm curious to know if any payment gateway does.
I love the "please enter your account number exactly as it appears on your statement" prompts which then require you to skip dashes/spaces which DO appear on the statement.
I've often wondered this myself, however, I have also thought about it from the opposite angle.
There are many sites that give no instruction as to how we are supposed to enter our credit card info. One can assume two possibilities: 1) The programmer of the site was ready, willing and able to parse multiple input types and simply strip out spaces, dashes, etc, or 2) I'm going to enter my credit card number into this page in a fashion not expected by said programmer and my much coveted Scarface Special Edition DVD will never show up at my door...
Just tell me what format you want so I can have some peace of mind and not have to decide which method is the best.
The payment gateways I've used have explicitly stated in their documentation, that there must be no validation of credit card numbers. I guess it's to avoid programmers messing up the card numbers or something.
I personally don't find that particulary annoying, I just hit the tab key. You can always take the user to the next textbox automatically with JavaScript.
I find that intensely annoying. I type 4 digits; press the tab key; start typing the next 4 digits; realise that the page had automatically taken me to the next box, so I’m typing into the 3rd box instead of the 2nd; swear…
At my university they had done something even more impressive. In order to change your password (which they made you do every six months) you had to type Eagle\foo.bar even though you've been typing foo.bar as your username the whole time and you have no idea what Eagle is. Luckily they put the helpful suggestion "type Eagle\ before your username" above the username text field.
The example code I've seen from popular payment gateways is some of the worst code I've ever seen and that's usually the code the web developers start with. It's obvious the original authors of payment API examples has zero experience with each language. It's doesn't surprise me that the whole payment gateway feels and operates like one giant hack.
I've seen ecommerce documentation billed as having examples in Perl, PHP and Java. What they meant was some of the examples were in each language and you needed experience with all three to get something working.
In some way it is a security feature... Some keyloggers are set to record when a combination of '4 number + space + 4 number + etc'. This is why my bank removed the first 4 numbers (which are common to everyone) when I login to my account. Also, they switch automatically to the password field as if it was a continuation of the number.
That's silly, because the same keyloggers can recognize sequences of 16 digits as a credit card number, particularly since they can be easily checksummed for confirmation.
I disagree. It would be easier to write keylogger which reads 16 sequential digits, computes a checksum and then emits a UDP packet to a hardcoded IP address.
Can people submitting posts please take the time to give a few words of description if the title doesn't explain. It would save lots of others reading posts they've no interest in. Some of us use RSS to follow the site and having to pick and choose based on "Why is this shameful practice so common?" doesn't help.
As a consumer, I'd agree wholeheartedly with this post. I can't tell you how annoying it is when online companies make it almost impossible for me to give them my hard-earned money. More than once I've left a site I was ready to buy from in disgust because the forms are so awful.
