Splitting credit card number fields into four different inputs

  • 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:

    single field with spaces between groups of four digits, and old field with four separate boxes

    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.

    What if the credit card number was less than 16 characters (amex) or longer than 16 characters (can't remember the card type that does that)?

    @gabe3886 This article appears to state that it *can* go up to 19 digits but that none go over 16.

    @DasBeasto looking at wikipedia (not a great source, granted) there's some canadian banks which issue 19 digit cards https://en.wikipedia.org/wiki/Payment_card_number I posed the question more as a "has this been considered" statement, but admittedly in a recent project I worked on, the client didn't want to accept cards longer than 16 digits.

    @gabe3886 It's possible that none of their payment networks have more than 16 digits (if they only support Visa, Mastercard, Amex, and Discover, for example); and they couldn't process payments for those bank cards anyway even if they could be entered in. For "ideal" user experience, I'd probably change the spaces around if the first digit is a "3" (Amex cards use different digit grouping)

    What is wrong with a single entry field with no fanciness?

    My bank's website has a 3-field input for sort code when setting up a bank transfer which auto-jumps to the next field once you've entered 2 digits. When I noticed that I'd made a mistake in the previous field, I hit SHIFT+TAB, which moved the focus back to the previous field onkeydown, but when I _released_ the tab key, the site's onkeyup handler noticed there were two digits in that field and "helpfully" jumped the focus forward again! Argh! I had to find my mouse and click on the field. Horrible.

    In addition to having less than 16 numbers, Amex cards also would require 3 fields instead of 4. You'd have to add extra code so that if the user was entering an amex number, the field count went to three, with a wider 2nd field. I'd forego the extra complexity and just leave it one single field.

    Please please don't make it several boxes. I find this infuriating as I usually store my CC numbers in password database software which copy and pastes them in for me. This is totally broken when a website uses several boxes. Usually trying to paste it all into the first box.

    It's worth mentioning that credit card numbers have a checksum. A good entry field should check this on the client side and tell the client they've made a typo.

    @Najib Idrissi what's wrong with a string of 16 or 17 digits is the same reason they beak it up into shorter fields on the front of the card. Human beings find it hard to remember groups of more than five digits between looking at the source and reproducing them on the keyboard. Human beings find it even harder to check that two 16-digit strings are identical (ie, that there are no typing errors).

    @nigel222 That's an argument for *displaying* the number with separators, *if* you expect the user to need to read it. But for inputting?

    @Najib Idrissi see my full answer (just submitted) for my fuller opinion.

    The current PCI-DSS requires that credit card numbers never appear in page files. This may appear irrelevant but if you break the payment card number into chunks to send then the number is less likely to appear as a contiguous memory block. I personally prefer to the user interface to offer a single box, but the resulting HTTP request to use chunks.

    Think of any interface which interferes with a basic task as a real-life acquaintance that desperately wants to be your friend so they awkwardly try to finish your sentences for you when you are speaking and they get it wrong or only marginally correct every time they open their mouth. You might be a nice person and finish whatever it was that you were trying to accomplish in their presence but surely you will loathe being in the presence of that person moving forward. Let the user finish speaking and **then** you can mention that letters are not accepted in the CC field.

    @NajibIdrissi It's hard to check the whole number at once. Splitting it up makes it easier to compare with the number on the physical card before submitting. Whether this small benefit outweighs the downsides is a discuss for answers, but it provides an obvious motivation for wanting a split up number.

    @jpmc26 I don't think I have checked my CC# after typing it even once in my life. Either the whole combination (CC# + expiry date + CCV) is correct and the chances that I typed someone else's card number are insignificant, or it's incorrect and I'm going to find out very soon. And again, while I see how this could be an argument for *displaying* the CC# differently, I don't see why the *input* should be different.

    @NajibIdrissi I am averse to experiencing an error when submitting payment information, so I always double check it. As I said, weighing the pros and cons and coming up with a solution are matters for an answer. I was just stating the motivation.

    @SimonG. That's an invalid reason, even if you discount the notion that a technical reason shouldn't affect UI if it is not absolutely necessary. The point is, that *reducing the likelihood* of the number entering the page file is not the same thing as *ensuring that it never does*. If the specification requires the latter then you will need to take other steps anyway (e.g. only storing user data in non-pageable buffers) that render the suggestion unnecessary by always preventing the numbers entering the page file.

    I like what booking.com does. They have one text box, but the display inside that box changes depending on the type of card, so they will break it up into 4 blocks of 4 for VISA or MasterCard, but behave differently for e.g. Amex. You can paste one long number into it, and it looks really neat.

    @Random832 is redrawing the boxes based on input "ideal" (assuming I've understood you correctly)?

    @ChrisH this sort of dynamic behavior heavily favors the more "lightweight" version with no boxes to be redrawn.

    @Random832 I agree

    This is my favorite credit card entry field. Side steps the problem, and saves me having to enter my address.

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

    • "Do I need to manually jump to each field?"
    • "Will the system do it for me?"
    • "What if I hit 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.

    Speaking of cognitive load, should we highlight whether the numbers should be added with spaces or without the spaces?

    @EshwarenManoharen Just let them type the numbers, and ignore any other characters they type (including spaces) but render the output with spaces in the appropriate place.

    Thanks, I think that works. At least in HTML, if you add type=number to the form, I think it won't show Space as well I think.

    @EshwarenManoharen just throwing this in here, no matter what you do in HTML/JS to allow only numbers, make sure that you validate the input server side, HTML/JS can be easily manipulated by the user.

    Joined just to give this +1. I get very frustrated with UIs that auto-jump, such that when I tab I end up skipping an input box.

    @TomHart Hey, that's good advice.

    Bullet point 3 is a serious issue in lots of separated fields (phone numbers, social security numbers, credit card numbers); in "vanilla" forms, one gets used to pressing tab to jump to the next field, but when the "smart" form attempts to automatically move you, you wind up in the third field. The far more insidious (and related) "smart form" problem is the one that detects when a field has been completed and jumps you to the next field -- even when you click back into the field to make a correction.

    @DoktorJ Exactly. Plus, you end up having to code for so many variances and interactions that the effort spent building these components is outweighs their usefulness. More code = more possible bugs / accessibility issues / compatibility issues / load speed etc.

    I'll agree one single field is best **only** if it lets me type spaces as well as digits (and filters the spaces after submission without bothering me or saying that the number is invalid), or if it automagically displays spaces in the right places as I type (which means recognising from the first few digits whether it's Amex, Visa, or whatever, and adjusting the auto-space algorithm). The spaces make a **huge** difference to a human being trying to check that he typed his card number correctly.

    I've used single-field inputs for various types of info on web apps, and prefer them over multi-field inputs. You get quite extensive text-autoformatting Javascript libraries for the task, I've used Igor Escobar's jQuery Mask Plugin, others exist. It allows you to specify formatting characters like spaces, hyphens, braces etc. which can be typed, or are auto-inserted in the right position if omitted. Imagine doing e.g. a telno "+1 (12) 555 1234" in multifield inputs - much cleaner in a single field with an input mask. Con: scripting blocked.

    Sadly, a typical implementation flaw I've found with most multi-field in the wild forms is being able to undo mistakes. Say I typo my credit card number 1234 5687 9012 3456 -- I try to click in "5687" and the JS magic kicks me to the end unless I have superhuman backspace reflexes, so I also :+1: for the "one field, allow spaces".

    @nigel222 yes; it should allow spaces (or hyphens for that matter, because some people may enter it that way) and silently discard them in any validation scripts without modifying the displayed field.

    @DoktorJ Totally, re point 3. Plus it breaks the "next" button most mobile keyboards have these days, and touch keyboards are already annoying enough without the form jumping around all over the place. Especially in landscape mode when you're peering at a web site through an infuriatingly tiny sliver of screen space, tracking where you are in a form by pure faith alone.

    I'm going to add one thing to this. Just eat the dashes or spaces server-side if you find somebody typed them in.

    Also, be prepared for people to type the whole number without looking at the screen. The easiest way to enter long numbers is to look at the card and type using the numeric pad.

    In addition to accepting spaces, also consider that the spaces make the input longer. I'm completely annoyed with my bank's IBAN entry field. IBANs are usually printed with spaces at well defined places. Now the input field doesn't accept spaces. Well, seems not too much of a problem, just copy/paste the IBAN and remove the spaces manually, right? Wrong. The programmer limited the size of the input field to the number of digits of the IBAN, and therefore the copy/paste will stop after that number of characters. Since those characters include pasted spaces, this means some digits are missing.

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

    • First, it's annoying, a lot of those reasons are covered in the other answers.
    • 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:

      enter image description here

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

    Great answer! I hope it gets its share of upvotes despite being late in the game. Here's mine.

    When I make car payments, my browser (Chrome) tries to fill in my username in one of the credit card fields (split as four input boxes). This actually makes it *more* work than if it were one field. Developers really need to allow auto-fill to do its thing. Having one input field is the best choice. I'm also annoyed when my expiration date won't autofill because of some unusual jQuery plugin to select the month and year.

    Great answer, to add to this, not all credit cards are 16 digits long; there are shorter and longer variants. I also wouldn't trust browser vendors to get it right, although you can certainly trust them more than a homegrown solution. In my experience, it is better to avoid any prohibitive validation (validation that will not allow the user to continue) and let the payment gateway make the final decision.

  • 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);
    })  
    

    Similarly, I keep my credit card number in my password manager, so I want to be able to copy-and-paste it into a single field. Several times I've abandoned a purchase when a website expected me to break the number up into 4 digit chunks.

    Bit of an overreaction isn't it Johnny?

    Actually some fields do allow a 16 digit paste which fills in each of the 4 input boxes. Seen it more often than not, but your point is still valid

    @LightnessRacesinOrbit - Why is it an overreaction to not support a merchant that goes out of his way to make it harder for me to give him my credit card information? I'd also walk out of a brick and mortar merchant if they made me swipe my card in 4 different credit card readers. If the merchant will autosplit a pasted number across whatever fields they want, I'm fine with that, but I don't want to have to paste the number somewhere else on the screen, then copy-and-paste each chunk individually (or type it manually)

    @LightnessRacesinOrbit I have done the same thing as Johnny many times myself (for different reasons, but everybody has their own valid peeves). It's not like there usually isn't 1000 other merchants to buy the same thing from these days. Philosophically, I don't support stores that make me do frustrating things in order to give them my money. Personally, I'm sick to death of crappy web design.

    That's really cutting off your nose to spite your face, for something pretty trivial. But to each their own.

    No, it's not an overreaction; the website is asking you to do extra, fiddly, error-prone work because they've made entering the number more complex than necessary. Frustration is a good reason to resent design. If only websites supported contactless payments ...

    @LightnessRacesinOrbit Nah, it's no trouble. When a business has to contend with so many competitors, like an online shop for example, if they aren't perfect, they lose. And I still get what I want, so no spite. On the other hand, if your payment form lets me take a picture of my credit card instead of typing it all in on my phone, you've just earned yourself a new repeat customer. In fact, I encourage *everybody* to take a stand against bad design, ha; only by working together can we defeat slide shows once and for all! Captaaaiiin Plannneettt!!!

    Credit card OCR! If you can get a solution past PCI-DSS that would be fantastic. Next best thing since Stripe.

    This functionality would piss me off immediately. I can think of more than one occasion in which I missed digits 5-8 of my credit card due to my cat attacking my face, child spilling juice on my back, or I get caught up swinging my sword at dragons. Anyways, the point is that now I must delete digits 9-16 if I wish to type in my missing digits or else your code will **put my cursor to the end of the text field on EVERY SINGLE KEYSTROKE**

    @pjc50 Safari on iOS 8 does it for web sites, and for Android and iOS apps there is https://www.card.io/, for free no less. The future is now, man. It's just a data entry method so maybe it's outside the scope of PCI DSS on its own.

    Keyboard arrows are not working, Ctrl+A is not working. It does not look "acceptable" to me!

    @Francesco Do you have a better example? Certainly this question would benefit from a cleaner solution.

    Usually when a phone number or credit card number field is split up into 3 or 4 fields, I often notice I made a typo and the web page's Javascript that does the "auto-tab" to the next field makes it nearly impossible to shift-tab to the prior field to make corrections. Even clicking in the field with the typo often jumps the cursor to the next field as the Javascript sees four digits in the field with the typo, and jumps to the next field. My wife can often hear me scream from the other room....

    @MarkStewart I'm not an UI coder, but I assume this is because it's impossible to reposition the cursor in a text field those content was updated with JavaScript. At least I don't know a way to do it.

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

    Yes indeed. Requiring the user to remove the spaces from the credit card number is an example of lazy and harmful UX design. It is fine to store the credit card number without spaces, but requiring the user to perform the conversion by hand when the computer can easily do it is lazy. It is harmful because the spaces are there for a reason: to reduce data entry errors.

    +1 for making the system do some of the work. (-1 for auto-tab.)

    This solution is by far the best. No possibility of confusion or unexpected reactions. No unexpected results from typing tab or space. Fully compatible with various browsers' autofill. The only thing I might add is putting the phrase "spaces optional" next to it.

    It is very bad for spaces not to be allowed for entry, yes it should be a single field. If you are a financial institution the first 4,6 or 7 numbers may denote a particular BIN, product, sub-product respectively and these may be more important to you under the covers so you yould define an object with these mapped. The operator does not need to know in most cases. Also, despite PCI, some cards are swiped through a reader for entry, it is nice to dress the number.

    also, don't hard limit the length of the field to just 16 characters, if they paste a credit card number with spaces, some numbers are cut off, giving validation errors later

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

    Brad Frost has implemented a single-field solution on this donation site. Try it out!

    @KenMohnkern I don't tend to enjoy using forms where the placeholder is all that's there to tell me what data they expect. It makes it hard for me to review my input to see if the data is correct. Looking back at that credit card info in the link you shared, it takes a bit more contextual evaluation to determine which fields are which because there are no remaining visible labels.

    @maxathousand - Absolutely right. Those labels need to move out of the input field.

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

    It's buggy if you modify the credit card number in the middle.

    @CodesInChaos How. I just tried and didn't notice any issues

    @Insane Delete a few characters and type some in the middle of the number. Sometimes the cursor jumps to the end of the input. Sometimes backspace doesn't delete the character before the cursor.

    @CodesInChaos Maybe because I'm on mobile. You should submit these problems to the github so they can be fixed

    @Insane https://github.com/jessepollak/card/issues/257 sounds like the same issue and is 3 months old.

    @CodesInChaos Guess the project needs a contributor

    @Insane That, or people should stop trying to make fields "smart" when there's no need for them to be. Give me a plain input field with nothing active attached to it (except maybe instant validation) and I'll be happy.

    @PeriataBreatta I more or less like the visual display, which doesn't affect the field at all. So really just keep the display and a normal plain input field except for the validation you talked about.

    i'm not sure what the point of the visual display is—just seems distracting, slow, and buggy. the rest is nice though.

    @sgroves the "rest" is just the input field which is the part that's buggy. that's what we've been talking about.... we've said a normal input field would be fine. so..

    **Do not use Card.js**! If you type the number incorrectly, you can't edit it in the middle. Try using backspace and then try typing numbers without clicking again.

  • 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:

    • It scales if the window is zoomed (just zooming a browser window still leaves the cursor a thin line which can be hard to find - one pixel if I test on this page in firefox/windows)
    • 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:

    • Different number of credit card numbers, e.g. 16 or 17
    • When deleting numbers, it must also delete the spaces when necessary
    • What to do when use clicks on a number and adds or deletes, how will that affect spacing?
    • Typing too fast - javascript can not always react fast enough

    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.

    When your form is auto-filled (or pasted into), spaces are added at the end, but that's minor. What's worse is when you try to navigate the filled form with arrow keys, it keeps adding those spaces.

    I have made another jsfiddle which I like better, and put into my answer. Mind to take a look?

    You might be introducing confusion to people with 17 digit cards who see the last digit hanging out by itself and not matching their card. Not everyone knows that the spaces between digits are meaningless.

    sure happy to take a look

    Sorry, but I struggle to get around the issues when what I type is not what I get, but only sometimes. Inserting a space if, but only if I typed the fourth digit slowly enough is disconcerting. Consider reformatting on loss of focus instead.

    Not all credit card companies separate their credit card numbers into 4-digit blocks. This does not seem like a good solution to me.

    Do not split numbers into blocks of 4. That's not how it looks on my AMEX!

    perhaps the single most important issue is to use a Monospace font.

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM