Somewhere, in one of the Usability books I read ( probably Donald Norman ), there was a suggestion that the normal format for entering credit cards was wrong. The usual format is 16 characters in a long string. However, the way that we read then and they are printed on the card is 4 groups of 4. The argument is - and I completely agree with it - that entering the card in 4 lots of 4 would be much easier, both to enter and to verify for the user.

This only needs a little bit of coding to include the dashes in the entered data, and ignore them in the validation. Or to have 4 boxes with focus going to the next one. It is not a complex coding issue. So why does no-one seem to do it? Why is the standard box format so prevelant still?

This comes out of having just tried to use my credit card, and make a mistake, and then had to search through the whole lot to identify the mistakes - tedious, and something that would be much easier if it was properly divided.

Edit: To add some points from comments. I think the proper implementation would need to be worked out - 4 boxes of autoinserted dashes may not work, or may need to be tweaked. So it is not saying xxx is the right approach, but that the current approach does have its own set of problems.

  • 7
    I know great works around exist, but all too many sites still give you 4 boxes for a multipart code and expect you to manually tab into the next one and/or they break copy/paste functionality and so 4 boxes can only accept 1/4th of your input. You couldn't copy/paste your CC number but still the 4 box method has proven to be extremely frustrating when not done well (think CD keys), and 1/10 times is it ever done well. A single input box avoids various pitfalls.
    – Ben Brocka
    Sep 13 '11 at 13:41
  • 1
    I highly doubt it was Donald Norman, because I'm pretty sure I heard him at a talk once say the exact opposite - just use a single text box. Sep 13 '11 at 13:42
  • 1
    I'm just wondering if there is a difference in error rates between the two scenarios?
    – colmcq
    Sep 13 '11 at 13:47
  • 4
    Please, please, please don't use four boxes. It is annoying, the auto-tabbing often can't be gotten right, but far more importantly, it breaks copy-paste! I never ever type in my credit-card number, always paste it. If a site doesn't allow for that, or forces me to remove hyphens and/or spaces, I go elsewhere. Sep 13 '11 at 16:39
  • 2
    @Marjam - another factor that needs to be accounted for. But I am puzzled - why do people keep their card number somewhere they can copy and paste it? That seems strange to me ( but is interesting to add to my understanding ). Sep 13 '11 at 16:44

Accept any and all formats typed into one box.

As stated by Don Norman:

"Compliance: How Microsoft Outlook Does Things Properly

Microsoft Office Outlook has done a brilliant job of handling telephone numbers, dates, times, and addresses. Surprise: this is a product that people usually target with complaints, but I intend to heap praise upon them. When Outlook's address book or contact forms ask for a telephone number, it accepts any format the person wishes to use, figures out what country it belongs to, and reformats it into a standard form. Start a phone number with +358 and it knows that you are typing a Finnish number, so it doesn't try to format it the same way it does for US numbers. If it is an American number, you can use almost any spacing character you wish, as long as the number has the usual 7, 10, or 11 digits. As a result, you can type in any of these American phone numbers:



847 555-1212

(847) 555-1212




And they all get transformed into either 555-1212, (847) 555-1212, or in the last case, +1 (847) 555-1212.

Most systems are just as bad with dates as they are with phone numbers. We say dates in all sorts of ways: most systems scold us if we don't do it just the way they like, again, often not even telling us what they like.

Here are some of the ways people write the date January 20, 2009:




20 Jan 09


20th January 09

Hurrah for Outlook! It shows huge compliance, huge tolerance for our variability. It takes all of these formats and transforms them into the target specification it prefers: Tue 1/20/2009. But even better, the target specification is set by the person using the computer and is stored within the Operating System, so all programs can use the same formats. "

  • That would do, as long as it would also display it in groups. Accepting in any format is cool. But the feedback to the user of whatever grouping the number is displayed on the card. Sep 13 '11 at 16:21
  • 2
  • 1
    +1 for it accepts any format the person wishes to use - your job is to help the user
    – mmmmmm
    Sep 13 '11 at 18:45
  • 3
    The downside is when, e.g., Excel tries to be TOO smart. When entering simple fractions (1/3) it will autoconvert to 3-Jan whether you wanted to or not... Sep 13 '11 at 18:55

Certainly there are enough of us UXers complaining about intolerant credit card entry. In addition to Norman 2009:

Add more to comments, if you like.

It’s viable to automatically insert delimiters such as dashes or spaces into a single text field as the user types. Nearly as good and programmatically simpler is to let the users enter whatever delimiters they want wherever they want. Chances are they’ll type it the way they want it to be. Behind the scenes, strip out all non-numbers for validation, checksum, and actual financial transactions.

Why do so many web sites insist on no entered delimiters? I would guess ignorance. And laziness. And resistance to change. Everyone does it, so where’s the competition to worry about? And callousness. By the time the users are entering their respective credit card numbers, they’re not going to abandon a purchase and lose all their work because of an error, no matter how much it pisses them off, so who cares?

  • The real reason I suspect is the backend API at the Visa/MC end requires the number as a single stream of digits. That gets reflected in the API the programmer must use.
    – Bryce
    Feb 4 '14 at 20:48

Agree with you in principle but not all credit cards have 16 digits. I have an American Express card sitting in front of me which has 15 digits (split as 4-6-5) - see more lengths on Wikipedia Bank card number page - It seems 12-19 digits might be possible.

That makes it a complex card-provider dependent task to provide a form which splits up the card number into the correct/appropriate number of fields. Testing would be a fairly major task and it may not be future proof either.

  • But it is not unknown - I have done it - to verify the card type and provide appropriate formatting. In particular, to check for start/end dates, 3/4 digit cvc. Sep 13 '11 at 14:12

The reason to use a single text box is because it is much easier for a user to just enter the numbers. Tabbing between text fields every 4 characters is an absolute pain. And the auto-switch focus is very annoying, especially if you have to go back and make changes. The implementation to make this work almost always causes issues when trying to make a change.

Roger is also correct that not all credit cards have the same format and as such, you can't force a specific format. You'd have to have different fields for each format, which would then just add to the complexity of your application.

Using some sort of masking to put separators in place when the user leaves the field can work okay, but again, it may not work as expected depending on the card type.

This is the same logic for other similar fields like phone number and social security number. We've discussed phone number form fields in the past as well.

  • 1
    As is illustrated by common usage of landline phone numbers - chunking a long number into smaller bits is easier for users to read - and remember. But then nobody probably needs to learn their card numbers.
    – PhillipW
    Sep 13 '11 at 14:11
  • 1
    The alternative is to have a formatted version displayed below, with the ability to click on a set of 4 and have these highlighted. There are ways around the issues, and I think something different would make it easier, if carefully done - as everything, if done badly, it is bad whatever. Sep 13 '11 at 14:14
  • @PhillipW - reading and typing it in are two completely different things. You can do whatever you want when displaying the data, but we are talking about data entry here. Oct 27 '11 at 14:17

Four boxes requires tabbing. A 16-character string is harder to get right. It seems to me that the solution here is one text box that accepts spaces (so you can enter 19 characters, and also be resilient to other number formats). Fix it in parsing, not by burdening the user. If you want to accept hyphens too that's ok, but since hyphens aren't on the card either you shouldn't require them (users won't expect it).

  • It needs to autotab, so you can type it in one go and it will split. Sep 13 '11 at 14:13
  • 2
    Why does it need to autotab?
    – jessegavin
    Sep 13 '11 at 14:21
  • 3
    @Schroedingers - autotabbing absolutely sucks, and you'll find just about every "expert" agrees with that. Sep 13 '11 at 14:23

Here's a contrary view:

Forcing the user to enter without spaces or dashes forces the user to enter data more carefully.

That said, I think this reason is bunk. I know the backend API's at common card processors require a stream of digits: when I've built credit card forms I simply remove spaces and dashes ("s/[ -]//g") and write a note to the user 'spaces are ok'.

Your Answer

