Verified By Visa
The worst form I’ve ever seen.
Verified By Visa, internally known as 3-D Secure, is an additional layer of security in online transactions designed to reduce fraud. This is a reasonable idea, but its execution was so badly butchered that it has been a bane on my existence for months.
I order a lot of food online (I even started a company around this idea), and now that I live in Montreal, Just-Eat is the only real candidate in the space. For months, I have been unable to use their credit card payment system because of 3-D Secure.
After you enter your payment information, an iFrame opens to an externally-hosted Verified by Visa gateway (more on this later). It explains that you need to enter certain details to confirm your identity: most of this information was already previously given to Just-Eat, with the exception of the card limit.
Every time I saw this screen, I tried in vain to enter my details, which I know to be correct; every time, I got a message saying my input was invalid. Even when copying and pasting the exact values from my banking profile, I got the same generic error message.
After spending half an hour on the phone with Visa, I discovered that you first have to register to use the service. Nowhere on the form does it make any reference to registration being a thing.
Registering for the service
Should be easy, right? They have a page which has a link to all the different portals, depending on your bank:
Clicking on your bank takes you to a brief description of the service, and clicking on your bank’s registration button takes you back to the 3-D Secure portal, with a thinly skinned registration process:
There’s a lot I could say about this aesthetic, but I won’t. I don’t care how ugly it is, I just want it to work. It does not.
After a few unnecessary pages of introduction, agreeing to terms, etc, you finally discover the registration form:
The Small Beans
There are some relatively minor gripes I have with this form. The supplied formats are rigid as steel; See that phone number format? If you add a space between the (123) and the rest of the numbers, like most people would, you get an old-school Javascript alert() telling you your phone number is formatted poorly.
If you forget the space in the postal code, you get a different alert().
The Meat And Potatoes
Here’s the real problem: If you enter any other error, you get the most generic error message imaginable:
The credentials supplied are incorrect.
Like before, I copied and pasted the info from my bank account into this form, and still, I got that error. I tried putting my name in ALL CAPS like it is on my card; no dice. I tried inverting the month and date fields, thinking maybe they were labeled wrong; nope.
You’ll notice the one field that has no formatting instructions is credit limit. One would assume, then, that the proper input would be the same as it appears in my bank statement: 1234.00. I tried adding a dollar sign in front of it. I tried adding a comma after the first digit.
The problem was it only accepts integers.
After changing the input from 1234.00 to 1234, it finally deemed my credentials as valid.
This is, of course, absurd.
Having designed many hundreds of forms over the past 10 years of my life, I am aware that they can be surprisingly difficult. It’s hard to make something that is both simple and intuitive. But this is just unbelievably bad.
This form was made by Arcot Systems, a company that has received $62,000,000 in funding. All they do is digital security interfaces. How can it be this bad?!
The solution is easy and obvious.
After submitting the form, for a brief second the phone number field loses all formatting and just becomes 10 digits.
This is done, presumably, because the data needs to be only digits when sent to their server, so they use regular expressions to remove formatting.
(Good developers know to do this behind-the-scenes, so the user doesn’t get confused by seeing their typed-in value flash momentarily to a different value)
The irony is if I enter my phone number as just 10 digits, the format its server supports, I get an alert telling me it’s formatted incorrectly. I need to add parentheses and a dash, so that javascript can then remove them.
If they are able and willing to use regular expressions to clean up the input, why do they insist on such a strict format? This whole mess could have been avoided by allowing the user to enter the input in whatever format they like, and then using regular expressions to convert it to the desired format. It is not hard.
An even better solution
I would love to live in a world in which merchants like Just-Eat stopped paying exorbitant fees for security mechanisms that render their service unusable. The negligible amount they’re saving from fraudulent charge-backs has got to be far outweighed by the fees and the cart abandonment that I and so many others are forced to do when unable to surpass their security.
Security for whom?
So, this falls outside the scope of the main point I was trying to make, but I’d be remiss if I didn’t mention it.
Arcot provides minimal security for the merchant, and in exchange they compromise the security of the user (that’s you and me) in a major way.
This subject is covered in far greater detail in a blog post by Jason Pearce, but I’ll summarize.
Verified by Visa asks you to select a password. This password can be at most 10 characters, and cannot feature any spaces or special symbols. As a result, it is impossible to make a password that cannot easily be cracked.
It gets worse.
The password limit suggests that they aren’t hashing or encrypting our passwords. If they were, the length of the password would be irrelevant, as it always gets encrypted to a 256-character hash.
In other words, as a result of needing to register for this “security”, my credit card number/expiration/CVV, credit limit, birth date, and other extremely sensitive information is likely sitting unencrypted in Arcot’s database somewhere.
13,000 financial institutions have implemented Verified by Visa. Imagine what will happen when that server inevitably gets hacked.
