I have previously been using 4 fields for the credit card number, splitting up each set of 4 numbers to make it easier to enter.
I am now thinking about having one field, which inserts spaces after every set of numbers instead:
For the one with 4 fields, the cursor jumps to the next field automatically.
Which format is preferred? Or are there any other better alternatives?
I only accept Visa, Mastercard and Discovery, with 16 and 17 digits.
I would generally always opt for the simplest solution. In this case, one single field for the user to type into.
With split fields, such as the 4-box one you propose it adds in an extra cognitive load to the user.
tab myself but the form automatically jumped - will it have jumped into the 3rd field instead...?"All these extra questions - perhaps subconciously, perhaps more forefront in their minds - are not questions that would even be considered in a single field form.
Sure, 4-field options aid readability - so if the user entered their number wrong it's easier for them to re-read their entry to see what area they did wrong. But this can still be mitigated in a single field. Just as you showed above, you can render the user input with spaces in the single field.
Another consideration is mobile users. While it may well be simple on a desktop, a mobile has a keyboard it needs to open and close on entry of the field. Different devices and OS's behave differently, but it's quite likely that on the jump from field 1 to field 2 the keyboard will autoclose and autoopen, causing a jarring flash on screen, with the user possibly trying to click the 5th digit just as the keyboard closes, thereby moving the cursor into another area of the screen altogether, or just missing that digit from entry altogether.
This mobile issue is illustrated nicely on Baymard blog, where they also point out that mobile users tend to manually press into each field - something desktop users don't do as often.
Your proposal is a nice idea, but I think it falls into the category of 'overengineering'. Unless you're noticing significant user input errors on a single field I don't think you need to introduce an alternative. You could risk decreasing the usability instead of improving it.
This answer and this answer cover some of the points nicely but for some reason nobody is discussing auto-fill support.
Don't use 4 separate fields.
Also, a CC number isn't four 4-digit numbers, it's a single long number. Some credit cards don't even have groups of four, in which case your four field input doesn't even make sense, for example:
The real one I want to add is some browsers give the option of filling out credit card info for you. Chrome, for example has this functionality, and Safari on iOS 8 will automatically add a camera-enabled "scan credit card" button to these fields if you craft them properly (see that article). And so the real "perfect" CC field from a UX perspective is a single field with the appropriate field name (like "Credit Card Number") and appropriate browser-specific trigger attributes (like autocomplete="cc-number" and id="cc_number").
Don't go trying to invent your own "convenient" input method for this. Stick to the same standard credit card number input methods that are already commonly in use (single field, appropriate name and attributes), because browser developers are already making an effort to improve the UX of these kinds of fields, so you let it be handled on the browser-side and give users something that they're familiar with instead of something inconvenient that also runs the risk of breaking all of the nice features their favorite browser normally gives them.
As someone who happens to use virtual credit cards, I'm strongly in favour of a single field. Every time I want to pay, there is a new card number generated for me by the banking app, and it's very tedious to have to copy-paste four times instead of one. I'm assuming here that your form won't fill the 4 fields if I paste 16 digits in the first one. Will it?
Also, I have seen several 4-field designs which were incredibly hard to use. Sometimes pressing Backspace was required to come back to a field with a typo, in other cases Shift+Tab was required. Sometimes the field you jumped to had its text pre-selected or cleared, so it was basically impossible to predict how the form would behave without observing it after each key-press.
Just give me one field where I can paste a card number into, and let me use Backspace to fix any typos if I happen to type the number manually. Here's something that looks acceptable:
$('#test_form').on('keyup', function(e){
var val = $(this).val();
var newval = '';
val = val.replace(/\s/g, '');
for(var i=0; i < val.length; i++) {
if(i%4 == 0 && i > 0) newval = newval.concat(' ');
newval = newval.concat(val[i]);
}
$(this).val(newval);
})
The simplest, if not necessarily the absolute best, solution is a single credit-card field that lets a user input any string of digits and spaces. It should be trivial for the server-side logic to strip the spaces out of the submitted string before checking whether the resulting string of digits is or is not a valid credit card number. If the user chooses to enter leading or trailing spaces or to break the digits in different places to what is on the card, so what?
Automagically inserting the spaces for the user may be slightly more user-friendly but is a lot more work.
Multiple fields with auto-tab from one to the next is OK, but if you take cards other than Mastercard/Visa then it is a lot of work to adjust the field lengths for the card type (e.g. 4,6,5,0 for Amex) on the fly (i.e in a browser-side script). On a card-company website that by definition only ever takes one sort of card, it's clear and easy. [Edit: OK-ish. Other answers indicate why it is a dis-benefit for some users ]
Refusing to let the user enter spaces is user-hostile. Allowing the user to enter spaces and then rejecting the (correct!) card number as invalid after submission is truly abominable, to the extent that I might refuse that retailer my custom at that point and instead buy from whoever was formerly my second choice.
Luke Wroblewski, a UX expert with great insights on building efficient forms, answered this question: use a single numeric input field (here’s a video of how this works).
As you can see in the video above of Zachary’s demo, a single input field is used to capture credit card number first. If the credit card number is invalid an error is displayed that prevents the user from moving forward. If the credit card number is valid, the generic credit card icon changes to reflect the type of card entered. This removes the need for a separate credit card “type” drop down or selector and reassures someone that their entry has been understood.
Once the credit card number is validated, it slides over to the left leaving only the last four trailing digits for reference and the next set of inputs appear in the mask: expiration date, CVV (security) code, and ZIP code. Since these are all numeric inputs, a 0-9 set of soft keys is all that is needed to keep people moving along on the keyboard.
Since the expiration date on a credit card can’t be in the past or far future, the input mask one again helps keep people away from errors. Invalid months or years simply won’t be accepted. After a valid expiration date has been added, Square’s design features another excellent enhancement. The credit card icon changes to reveal where the CVV code is located on the specific card being used to pay. This small detail helps clue people in to what information is required next.
Because CVV and ZIP are also numeric entries, there’s no reason to ever leave the dial-pad throughout the payment input process: no jumping between multiple form fields required. Zachary’s also made sure that people can use their keyboard (tab and shift-tab) and mouse to move between the various parts of this payment input mask.
Please follow the advice of others and do not attempt to reinvent the wheel. Not unless you have read and understood the ISO standard ISO/IEC 7812 that governs Payment card numbers, which, by the way, range from 13 to 19 digits and usually (but not always - read the spec) include a check digit that you can use to validate the input.
Inserting spaces where there are none is almost always a bad idea. Think of all the possible combinations you will have to deal with; auto-filled, used to populate auto-fill. Pasted in with no spaces, pasted in with spaces, cut for use elsewhere (should the cut include the spaces?), typed in, edited, and at the end of the day, what is the problem you are trying to solve?
I think Card.js is my favorite user experience when it comes to adding cards. Not only it lets you type in very quickly (single fields etc.), they also show you where those fields are on your particular cards so you don't have to wonder where's expiration date or CVV. I recommend you check it out.
Please, for the love of God do not do the second option.
one HUGE UX flaw is (which the majority of sites do when implementing this shutter) you can't go back to edit the numbers previously, because it auto forces you to go to the next field since you filled out the data.
Let's not forget that creating multiple fields make it appear as though you are filling different bits of information. In your design, it makes it look like potentially the last field will be for the "security code".
Making it one field implies one chunk of numbers (but please do what you did in option one: indenting because that shows the exact same format as your card).
When filling out credit card details, you want to come close to what the design of the actual physical card is because users will then be able to scan the card and look up to add the information they have just scanned. Jumbling anything up will cause confusion and frustration (from my experience in working in the ecommerce world for years).
A minor extra point I don't believe is addressed elsewhere: A single box is more accessible, especially on systems without a full suite of accessibility tools:
Tabbing between fields behaves reasonably (don't forget shift-tab).
This may not be true any more, but some screen-readers used to struggle with unlabelled input boxes -- this may still be the case for speech input technologies, but I haven't used them.
I'm not saying you can't make an accessible (and standards-compliant) input with separate boxes, but a single box is easier for you and users who need (or want) atypical interfaces.
My solution in the end, was to use one field. Then every 4 digits, it adds a space. Therefore it creates less potential confusion, yet also allows you to clearly view the credit card numbers, in the same format as the card.
The potential issues that arose are:
If you can get around these issues, then I believe this the most intuitive.
I have created a form here https://jsfiddle.net/9apu6ux3/ as you can see it splits up the numbers nicely, but is difficult to make bullet proof.
