> “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 :)
UK banks sometime sends payments to a separate verification page which either returns automatically or asks further security questions.
I don't think this form is going to work with those banks.
A couple of takeaways:
1. This has been a standard problem for twenty years now. Why are designers and developers still having to reinvent the wheel?
2. Reinventing the wheel is really hard. If you want to support international trade, card and address formats are a non-trivial problem. It's easy to get something 90% right, but those edge cases will kill you and piss off your customers.
I suppose in an ideal world the card industry could think about standardised industry-approved forms with international support and customisable CSS. Maybe they'll get around to it in another twenty years or so.
Considering the incredible size of the financial industry, its inability to create efficient friction-free payment systems is shameful.
The worst thing about these programs is the liability shift. Normally the merchant is left on the hook for fraudulent transactions.
With VbV and 3DS that liability passes back to the credit card company. Since the credit card company doesn't want that liability, and obviously there are no security holes in their system, then only one person can be responsible for not taking adequate care of their card and security details. Yep, you the consumer (read your small print).
Hence, by signing up for any of these programs as a consumer, you are shooting yourself in the foot.
Thing is it is very difficult to not be signed up for 3D Secure/VbV/SecureCode. I've had friends who have gone through ludicrous arguments with banks to get them opted out from 3D Secure.
I have been unable to be opted out from 3D Secure. It just doesn't seem to be possible. The argument the credit card companies usually use is that they aren't forcing it on us; it's the merchants, who set a flag in the transaction saying they require it.
If you know how to opt out of it, I'd love to know.
It does seem to work that way, I'm sure I've signed up for Verified by Visa but I've only had to use it once or twice. Which makes me happy, because I hate it.
The implementation is up to the bank. My banks use 2-factor authentication solutions for 3DSecure (one has you put the chip in a special reader, the other uses a mobile app)
Yes - and if you look at the source URL (mostly hidden if they use an iframe, or sometimes visible if they do a complete page redirect), then the hostname is often a completely unrelated, unintelligible name that no-one would associate with either the shop or the card company. These are exactly the websites that you should NOT trust!
"Please type in a whole load of other personal information" Nope! I get a good feeling of petty bureaucratic victory every time I see a site bounce in and out of Verified by Visa since I persuaded my bank to opt me out.
It is basically up to merchant what to implement. I ever developed a site (in team) for South East Asia customer. Singapore law and Indonesia law are pretty much have freedom in it. You can choose 2D / 3DS. Yes, the different is pretty clear: who will responsible for the fraud. For 2D, merchant is responsible for fraudulent transaction -- and merchant can be charged back; while in 3DS the merchant will free from chargeback (hey you have been notified via two-factor authentication, so it is your fault, customer!)
Meanwhile, in Malaysia, all credit card transaction must be in 3DS.
My UK bank (Lloyds) cannot handle non ASCII symbols in the address fields for IBANN payments. Drives me crazy every time as most places I make payments to have at least a few å or ë letters in them. How someone could create such a form without testing it on a bunch of international addresses is boggling.
It's in their interests to make it inefficient. Payment gateways are a large source of revenue for banks. An efficient, friction-free payment system would likely make these payment gateways redundant, and hence, remove a revenue stream for banks.
Even in the UK when using payment gateways (by which I presume you mean PayPoint/Protex/WorldPay etc and you're a "merchant") you still, in many cases, need to use 3D Secure/VbV/SecureCode if you wish to remove being the liable party for fraudulent card use.
> Is this form safe and secure?
We just add a lock icon, sure it's secure. Lock means secure, right?
Joke aside sure, it's not the designer's fault. Every time I fill out a credit card form without even pulling out my card I cringe. Why do I need a physical credit card for this, I just authenticated myself with only something I know and not something I own and I know. And my authentication credentials are just written down on a piece of plastic. Why don't banks just host openid servers so I could authenticate myself and pay using that? It would be even more secure and convenient. Credit card security (for most card types) is a joke.
Interesting. I was going to say "there's no web UI for driving the SEPA system from a merchant's site", but is that what Giropay is?
Bank authentication systems themselves aren't great here in the UK. I'd be much happier with a USB/Bluetooth gizmo that behaved like a chip+pin terminal+card combo: display the value on the device, confirm payment with a pin/password on the device, bypass the PC's possibly-compromised keyboard and display entirely.
That’s exactly what GiroPay is. The merchant can use it as simple as they can use PayPal, but GiroPay then redirects you to the online banking backend of your bank. Depending on bank, this can use 2-Factor authentication, SmartCards, etc. Most banks use Smart Cards and 2-Factor authentication.
With Apple Pay, I now get iOS notifications for all the purchases on my Amex card.
Barclays now let me use their iPhone app as a software 2FA (bank-specific hardware 2FA needs to die—not being able to check your online banking at the office or whatever is a major PITA).
Both Barclays and NatWest have TouchID in their iOS apps.
I'm hopeful that mobile might lead the banks and card issuers to turn this ship around and make things less crap.
Mastercard SecureCode does this. I'm seeing it more and more. My bank implements it using hardware 2fa; a separate dongle that reads my CC, asks for my PIN and a transaction salt (or QR scan) and computes some hash (?) from it.
It's actually very frustrating when I don't have the 2fa device on me.
Yeah, I know MasterCard SecureCode. I have two bank accounts, one bank implements it using 2fa and uses SMS as the second factor, still no need for the card. The other bank doesn't implement it at all. And you still have to enter your credit card info, while the actual authentication actually has little to do with it.
> We realized that users may enter the ZIP code associated with their personal address, instead of the code associated with their cards. To add clarity, we added a note in a tooltip, which asks for the code from the credit’s card billing address.
By the time some people start typing, they are looking at the keyboard and not at whatever is changing in the UI. The people who might need this tooltip won't be the ones to see it.
I don't get the name and zip code requirements, is that standard in some countries? I only ever encounter the "Name on card" when shopping on US and UK sites. Danish online stores don't care.
Is the name and zip actually used as part of a validation process? If not it should just be left out.
The article says it helps with validation, and in my experience (living in the UK) many sites ask for it.
Postcodes are quite specific, they only cover around 1-30 addresses. My workplace has at least 4 postcodes to itself (different buildings). My home address shares the postcode with about 15 other houses on the same side of the road (odd numbers 1-31).
Minimal British address examples: "SW1A 1AA" (Buckingham Palace), "6, M1 4EX" (could be a house).
"As an extra security measure, we have to ask customers for the ZIP code associated with their card. There is a trade-off here: adding extra inputs to the form can increase bounce rates, but by adding it, our business is more secure and less prone to fraud."
Is the zip sent to the card processing company? Do they check that the zip matches your address? What if the customer just moved?
I've implemented card payments on multiple occasions, but not once have I seen a credit card processor that offered to validate the zip code.
Unless the name and zip can actually be sent to the credit card processor, and they have access to that information based on the credit card number alone, I don't see the use. Which brings up names, how fare of can your name be? I know plenty of people who wouldn't think twice about leaving out a middle name that they hate.
Yes. They are asking so that it can be sent to the credit card processing and used as part of a anti-fraud algorithm. Have you implemented credit card processing yourself or used something like Stripe? It's honestly a pretty common option. At least around me in the North Eastern US, pretty much every gas pump will refuse to sell you gas if you can't provide the billing zip for the credit card.
We use multiple companies, all of which are "something like Stripe", to avoid dealing with PCI requirements. I've never seen any of them check zip or name, if you want added security you ask for 3D Secure/Verified by VISA. That will either require the customer to login via their online banking solution of enter the code sent to them via SMS.
On of our payment providers just told us today that by August 1st. 3D Secure will be required for all online transaction in the EU. It might be later, less than one month doesn't seem like a reasonable notice.
Honestly name and zip seems like something that's easily obtained by a scammer.
I don't know how many people actually use it, but it's definitely a common option. The idea is that it would be another layer in your anti-fraud protection, not that it would replace something else.
> I know plenty of people who wouldn't think twice about leaving out a middle name that they hate.
And I haven't met a bank that didn't ignore the middle initial when validating a credit card. Even though they all say "enter your name as it appears on the card".
Which just makes it easier for them to be stolen. If someone gets a hold of your card number they probably also have the record of what you bought. If you had it delivered to your house they have your first and last names and zip code. All they need is the CVV2 (pick a random number from one to one-thousand) and they're in the clear.
I really don't get credit card security at all. Seems to me to be a lot of smoke and mirrors that the banks just plaster over with insurance for when they have to give back stolen money. It doesn't actually prevent or deter theft, just sweeps it under the rug.
We implemented our payments with PayPal Website Payments Pro, and we actually get back the name and address verification information and can choose to ignore it (at our own peril re chargebacks)
I wonder if they have customer beyond US/Canada that they mention. Otherwise this would fail spectacularly in other countries in general (eg, UK: both letters + numbers, Taiwan: 3 digit zip code)
Canadian postal codes are both letters+numbers as well (formatted AxByCz, where A,B,C are letters, x,y,z are numbers), so UK seems like it would be safe.
Too many or few characters, like you point out as the case for Taiwan, would be the problem.
> There goes Australia and their 4 digit zip codes...
To say nothing of Iceland, the Faroes or Madagascar (3 digits) let alone Jamaica (2 digits, and only in Kingston and St Andrew elsewhere there's no zip code) or Somalia (2 letters)
When I look at the logos on the top of the form, I feel like I should click on the one (Visa/Mastercard/Amex/Discover) I'm going to use to tell the form which one I'm entering the details for. Although this can be deduced from the number, most online forms require the user to select it explicitly (although most commonly with radio buttons or drop downs). This minor friction and confusion could be avoided by just saying "We accept " followed by the logos.
Apple should integrate Touch ID into their Macbooks and turn Apple Pay into a service for ecommerce. Payment would be one tap, similarly to Apple Pay IRL.
They could place the capacitive fingerprint sensor where the ON/OFF button used to be, it would actually be a neat way to wake up the machine without typing a password too.
For now, I just have my credit card number memorized so I can checkout fairly quickly without having to fiddle with physical objects in my pocket.
Suggestion: instead of generating garbage-looking "verification code" I as a user would prefer to have a string of digits separated in groups. Imagine the experience of spelling the code in its current incarnation over the phone...
Nit: the passage about "getting rid of physical cards" by replacing them with Apple Pay. If you use your phone to pay, it's still a "physical card", albeit more hi-tech.
Bug: enter a VISA number (example: the 4111 1111 1111 1111 test number), enter an expiration date, enter a 4 digit security code. An error appears: "enter a 3 or 4 digit security code". I entered 4 digits so the message is inappropriate. Probably it should be "enter a 3 digit security code", assuming that all VISA cards have 3 digit codes.
Has anyone actually stepped back and looked at the larger picture, what a buyer wants to do is pay X (credit card is only one of them payment methods available and not really popular in some countries)
they do not want to be entering long strings of numbers (whether its a credit card number, bank IBAN number, prepaid card #, or a bitcoin address) into forms
I had the same initial impression based on the opening paragraph. I thought the post was going to use the Uber technique of ocr-ing a webcam (in their case mobile) image of your card and auto inputting all the info.
Either way the UX process was interesting, and I think helpful for those who haven't had the chance to think through the painful development of credit card inputs.
With bitcoins, I click on a bitcoin address in my web browser. That opens up a bitcoin client with the information already filled in (amount and receiving address). I then have to type my bitcoin password for the transaction to complete.
Except for the authorisation step, which could be done in other ways, most of the convenience is already in bitcoins. Any other payment URI scheme could do the same thing.
Bitcoin is the most convenient way of payment, bar none. I point my phone at the QR code, keep my fingerprint on the sensor, the page refreshes, done. None of the CC crap.
Problem with PayPal is that they ban people (I lost my account years back, still do not know why) and also of course not available in all countries.
I was thinking something along the lines of some sort of new HTML "payment" tag so it could signal to the browser things such as "product details, price, available/preferred merchant payment method"
and then the browser would pay from an in browser wallet containing stored credit card numbers, or bitcoins or prepaid/voucher codes, or bank account information
Some browsers could outsource this by starting a separate wallet program altogether, sort of how some links on mobiles open up other apps like maps
Someone above mentioned bitcoin links, that be a very good example of how to do UI payment flow nicely, especially nowadays that
Eitherway I think credit card forms are anything but user friendly, even the cleanest of forms such as Stripe would dumbfound new internet users such as my mother who rightly asked before "is it safe for me to be entering my cardcode on the internet"
Pre-filled credit card information would be great - if it could be stored securely. PCs are basically far too insecure for this to be accepted by the payment processors, it would just be phished to death.
Apple Pay would be the right solution if it weren't so proprietary.
Apple Pay uses industry standard payment tokens, just like Google Wallet, there is nothing stopping any company out there from using the technology. The only thing about Apple Pay that is proprietary is the TouchID fingerprint verification.
>But we realized that the credit card number is not a “secret”. You can’t do much with just a card number.
I think I know what they're trying to get at in the context of the form, but this doesn't do much for my confidence in how much care they take in protecting my number at the backend.
Which is exactly what it does. Try entering a random 16 digit numer - it will probably be invalid, but then edit the last digit until it is accepted.
But, once you have a valid number, that's all it is, a number. So you still have to round-trip to the payment processor, via the server, to check the number represents an actual payment card, and has money available.
British Gas have JavaScript that actively prevents you from using LastPass because "as a business we've chosen not to have the compatibility with password managers".
I want to be a fly on the wall at the meeting where they decided that making security worse was a good idea.
Paywave / Paypass / Tap & pay / whatever your country or bank calls it. With NFC payments you don't have to type a PIN when using a card. Although you can use extra PIN when paying using your phone.
I guess one needs to type the pin in most places, but in the US I've been able to use my card by just swiping it. Sometimes I've had to sign a receipt after swiping.
Interesting post, and I'm not surprised to see a diversity of opinion on the design. Question: does anyone still use the CRC validity check for client- or server-side validation of payment card numbers?
Does anyone not? It's a dead stupid simple way to check that the card number entered could possibly be valid, so you can let your users know earlier in the process (during client side validation) that there may be an issue.
Yes. Luhn checksum detects adjacent digit transposition errors, which I'd tend to believe are the most common, and it will detect a single wrong digit, which might be most or second most common. It's a simple check, although all the example code I've seen is grotesque.
The lesson here is that when you're dealing with those pirates that do the "Rachel from Account Services" scam cold calling, transpose two digits seperated by another digit. Don't monkey with the first 7 digits or the final digit. You can get those idiots to go all the way through verifying your (incorrect) card number, as the BIN/IIN is correct and Luhn check passes. Waste some time on double checking your card number before spewing vitriol and profanity on them.
basically there are tons of browser plugins which listens to your keyboard, or anyway see everything you enter in a form. One nice example was facebook color changer;P
... And that is a problem with password managers why? It doesn't matter who enters the credit card, you or your password manager, those would still get it.
About the plugins, you are right, it's weak anyway, my bad. To better answer your question this is a paper explaining some critical vulnerabilities in the concept of password managers (let alone the implementation) http://devd.me/papers/pwdmgr-usenix14.pdf
I use Dashlane and stopped entering credit card and billing info manually 2 years ago :-)
Their tech is amazing. They autodetect credit card fields when you focus on them and show a little popover where you can choose the card that you want to use. Just click on the card and everything fills up.
http://dashlane.com - email me if you'd like a referral link to get 6 months of premium service for free, btw.
Ever since we've had cryptography, money on the internet has always seemed unnecessarily clunky to me. Everyone should have a password, then it's just a matter of encrypting who has how much money. While people make fun of how "fake" bitcoins are (as if any other money were not just a slightly more consensual mass hallucination), I really do like how they have demonstrated that internet money can be a lot more convenient. I hope that bitcoins or something like them become the standard for money online.
As to the whole fraud problem that intermediaries like Paypal or credit card companies are supposed to solve; this is orthogonal to the problems of authentication, authorisation, and consensus, which bitcoins solve. We could have both, such as banks, escrow, and arbitration (in the sense of having a third party decide if a transaction should proceed or not) even with bitcoins. We really do need better systems than what traditional internet money has done so far.
Do we have a comparison of how much is lost to fraud otherwise, without bitcoins?
Anecdotally, the only time I have ever been defrauded of money was when my debit card was skimmed. The fraudsters kept trying to withdraw money, which I didn't keep in that account as I immediately took it elsewhere. It was the account in which I received my paycheque. The fraudsters were able to steal one of my paycheques, and the bank was completely ineffective in protecting me. I got no warnings of unusual activity, and I got no money back. I should have gotten some sort of warning, since someone was repeatedly trying to withdraw money from unusual locations from my empty account. Even my account history showed nothing. Not until I asked the bank after the money was already gone did I learn that the fraudsters had been attempting every day to withdraw the money.
How many stories like mine are there compared to bitcoin stories?
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.