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

Also, dealing with AMEX screws up a lot of forms.

15 numbers, 4 then 6 then 5. Yes, only 3 groups. And the CVV2/CVC2/CID is on the front and four digits, not three.

I wonder if this has any thing to do with why amex was so infrequently an available payment option online for so long...

I doubt it. A more probable reason is the higher transaction fee charged by Amex (3.5% compared to 2%).

The demo form does seem to handle backspacing and pasting correctly.

I do know a LOT of places where this gets missed, and a typo goes to the next field, but reflexive backspace correction also fails.

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.

You can try it here http://codepen.io/anon/pen/WvygyO

VISA: 4242 4242 4242 4242 AMEX: 3782 822463 10005 Diners: 3056 930902 5904

[0]https://stripe.com/blog/jquery-payment / https://github.com/stripe/jquery.payment

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.

They most certainly do not have a singular canonical format. American Express cards use different groupings and a four-digit card security code.

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.

The iPhone reformats phone numbers as you type them, and I personally don't find it jarring at all.

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.

[1] https://blog.nearlyfreespeech.net/2015/05/13/new-payment-fea...

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.

They are using it, they just don't reference it specifically in the article.

You can try the demo: https://s3.amazonaws.com/gabe-cc-form/index.html

Judging from the screenshots with filled inputs, they automatically add spaces making the card number look exactly like it is on the physical card.

https://medium2.global.ssl.fastly.net/max/800/1*QzxyS4KGIvCw...

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

Probably because you didn't enter a valid card number. Try something that starts with '42' (for a Visa card). It works for me with a valid number.

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 know a banking site that inserts dashes. However, if you type too fast, then it inserts them into the wrong places :/

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.

This is indeed annoying. I've found that entering 00000 as the zip for a foreign card quite often works (though not 100% of the time).

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.

Do they still (automatically) insert a gap in-between groupings of numbers?

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.

The "/" is automatically added after you type the month, so you're never left with "0515". Try out the demo [1] and it should be a bit clearer.

[1] https://s3.amazonaws.com/gabe-cc-form/index.html

Ah, I didn't notice the demo. That is actually pretty nice. If only they would do the same with the credit card number field and spaces.

Edit: okay seems like it is more thought out than I assumed.

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