> “My card number has spaces. Do I enter my card number with spaces, or without?” To solve for this, we limit the input values to numbers only, so 0–9. So if a user types a space, it does not register and it does not affect the number format.
They failed, at the most important part of the form. The correct, i.e. the most user friendly solution is, obviously, to allow spaces (and optionally other characters, like "-,._") but ignore them when submitting the form. That way, users can type in the number any way they want. Using spaces to group digits makes it much easier to check the number after you've entered it (not that it's necessary, but I still often do it).
Edit: they seem to stick to this failure mode with other inputs as well, e.g. with the postal code input. In almost all circumstances, it's better to allow users to enter anything, and give feedback on whether it's correct or not (either when the focus moves to the next input, or better yet in realtime when the user is entering information, as long as you make sure that partially entered, potentially correct information is not labelled an error). For bonus points, reformat the entered information to some standard format (e.g. grupped dogits for card number) after the focus moves away.
Another example of doing it wrong is when the form splits the cc number into 4 separate boxes, and automatically skips along merrily to the next box as you type it in. This might look nice and everything, but usually breaks if you try to backspace your entry, or paste etc
jquery.payment from stripe[0] helps with formatting and automatically adjusts it to the card type as you type in the numbers. It does seem to ignore spaces though, but it adds them for you as you type. If you type in a VISA number it will format it as XXXX XXXX XXXX XXXX, but if you type in AMEX, it will format it as XXXX XXXXXX XXXXX. Pretty neat if you ask me.
The automatic formatting seems more "cool" then actually useful. I'd much prefer that it show characters as I type them, like pretty much every other text input field.
As opposed to most other text input fields you encounter in the wild, credit cards (and phone numbers) have a singular canonical format. As long as you don't limit HOW it's entered (or pasted), it makes a lot of sense to coerce the input into the canonical format.
At least for the US, the issuer of a credit card (and thus the format) can frequently be determined from as little as the first digit. For instance, nearly all card numbers starting with '4' are Visa.
Most fields don't reformat and add characters like spaces as I type. I personally find it a bit jarring. I suppose reformatting it one the box loses focus isn't as bad, but I'd still prefer you just keep what I type.
Try moving to a country that splits phone numbers different that what you are used to. I grew up with 3-3-4 but live in a country that splits 2-4-4. Subtly annoying.
I find it both cool and useful. The digits on my credit card are already separated into 4 segments, so it's natural for me to both read and type them in 'chunks' of 4. If I need to compare it to what's on screen, it's much easier to see. And it's harder to lose track of which digit you're at and what's next. Or if you mistyped anything - it's visually clear as well because you're likely to change the "balance" between the individual segments (e.g. push one digit to the next segment).
Ditto for the expiry date. Showing a slash in the placeholder text but silently eating it if the customer actually tries to enter one is a recipe for confusion.
As a matter of fact, you won't even have to worry about the expiry date format for the rest of your life. None of the valid YY or YYYY codes for the next 84 years (15-99, 2015-2099) collide with a valid MM code (01-12). There's no ambiguity. So just let the customer enter any 4 or 6 digit number, figure out which part is the month and which part is the year, and convert it into your preferred format with a few lines of JS.
This is especially important if you ever plan to expand into countries where nobody is used to the MM/YY format. If the customer enters 2207, it's obviously July 2022, not the 22nd month of 2007.
I'm curious about their statement that they automatically append a slash as soon as you type the month.
The instructions say "MM/YY", but do not indicate whether the month is required to have two digits, or just permitted to have two digits. My card says it expires 1/16 So when I key in 1, does a slash get appended? Probably not. Instead, it gets appended after 11. 11/6. now what?
11/6 may have been a valid expiration date before November 2006, but not anymore. So a smart algorithm could tell that you meant 1/16 rather than 11/6.
It even works if you put the year first. 16/1 is valid, and it's clear that 16 is the year. Meanwhile, 1/61 either contains an invalid month or is too far in the future to be a valid expiration date.
NearlyFreeSpeech.net [1] does it right. It accepts anything between 3 and 6 digits (MYY, MMYY, MYYYY, MM YYYY, YYYY/MM, etc) and only throws an error if parsing it results in an impossible date.
Testing whether a account number is valid before transmitting to the server is a problem that was identified and solved over 60 years ago with the Mod10 algorithm. Why aren't they using it?
Right now, the only "does this credit card number look right" validation they do in JS is to look for a known prefix digit, and the length of the number. Otherwise the send it to the server for processing.
This is silly. In 1954, the Mod 10 (AKA Luhn Algorithm) was designed specifically to catch people mistyping in account numbers and all credit cards use it. It's a check digit, where the last digit of your credit card number is based on the all the other numbers. It catches transposed digits, and mistyped digits, which are super common when asking a human to type in 15+ digits.
The live demo linked flat the end of the blog post makes a feeble attempt to insert a space after the first 4 digits, but ultimately fails (on Firefox 38 on Windows).
I personally like it when the form inserts a space for me after every 4 digits and has a maximum length of the field set to (number of digits + spaces between). For some reason I rarely see websites that have such forms. Maybe it is actually confusing for the majority of users.
In Hungary the most used credit card form by me (OTP Bank paywall) inserts not spaces but "-" after every 4 digits. It behaves strangely for backspace.
I have worked on an actual product where the user input is validated prior to losing focus, and if the input is invalid, the user cannot move focus from that control until it is corrected.
Several developers on the team opined that it must be the worst idea in the history of input validation, yet the customer still wanted it that way.
For postal codes, they're even doing the right thing for the wrong reason. They believe they're only going to encounter US or Canadian postal codes. Billing addresses can be anywhere, of course.
This comes up all the time. Moderately annoying situation if you ever drive in the US with a foreign payment card. The gas pumps use some "ZipSecure" thing that requires you to enter your zip code to authorize a credit card payment at the pump.
... Except I don't have a zip code. Which usually meant I either had to prepay inside (and then go back inside to receive the remaining balance as cash) or leave my credit card unattended with the clerk while I filled.
Checking the demo, they sort of do what you suggest, and allow spaces, but in fact they are adding them in automatically. So the number is split into groups of four digits, visually.
Yeah, seriously. The expiry date field fails as well.
>Note that the placeholder text includes a “/”, but this is not required to be typed by the user. We limit the input value to numbers only, so if a user does type a forward slash, it is not registered.
Frankly, I'd prefer that field to be split into two, but I'd be fine with a single field, if they didn't ignore slash. It's pretty annoying to see a form silently fail and ignore characters that the form itself seemingly required (by showing them in the placeholder). A cluster of numbers like 0515 for date is not very intuitive either.
In my opinion much better way is to allow characters like spaces, dashes and slashes, show them when they are typed, but strip them on validation and further operations, working with only numbers.
They do exactly that! However it depends on the type of card, so if you just start typing '1234567' it is not a valid card number and is unformtted. Try entering something that starts '42' (for a Visa debit card) and it will be formatted as such, in four groups of four digits. They also recognise AMEX cards and format appropriately, try '345612346712348' for example.
They do, but only when the number you're entering is recognised as one of the expected formats. If you type 1234, you'll see the space being added, but it's then stripped again with the next digit you input. If you hold down 4 or type 3 then hold down 4, the spaces will be added.
Things get fun if you try to go back and edit the number, though. Forms are hell :)
They failed, at the most important part of the form. The correct, i.e. the most user friendly solution is, obviously, to allow spaces (and optionally other characters, like "-,._") but ignore them when submitting the form. That way, users can type in the number any way they want. Using spaces to group digits makes it much easier to check the number after you've entered it (not that it's necessary, but I still often do it).
Edit: they seem to stick to this failure mode with other inputs as well, e.g. with the postal code input. In almost all circumstances, it's better to allow users to enter anything, and give feedback on whether it's correct or not (either when the focus moves to the next input, or better yet in realtime when the user is entering information, as long as you make sure that partially entered, potentially correct information is not labelled an error). For bonus points, reformat the entered information to some standard format (e.g. grupped dogits for card number) after the focus moves away.