Better E-Commerce Design using the Luhn Algorithm?
I finally put in my pre-order for SimpleScott’s Designing Obama book a few minutes ago. I wanted to buy it earlier but never overcame the inertia until I got a chance to have beers with Scott and then listen to him speak at the excellent Webstock conference in New Zealand last week (by the way, thanks to Khoi Vinh for asking me to step in for him as a speaker). Can I also just say that Webstock is the best designed conference I’ve ever seen?
Scott’s a great designer, obviously, but hearing about the care that’s going into just the production of the book is going to make this piece of art a must-have. I may even order two and keep one suspended in formaldehyde.
While ordering the book, one part of the process stuck out to me as something I’d never seen before, even having ordered probably a thousand items online in the past: when I typed in my credit card number, a green checkmark showed up immediately after the last digit was entered. My immediate suspicion was that they were counting digits and gave me a check to indicate I had typed in enough of them, but again, having never seen that before, my interest was piqued. I tried deleting the last digit and replacing it with a 1, then a 2, then a 3, and so on. Only when I typed the actual digit from the credit card did I get the green checkmark again.
Further investigation revealed that no server calls were being made, which means this was some sort client-side algorithm that verified credit card patterns. Iiiiiiiiiinteresting!. Even more investigation revealed that this was the work of something I’d never heard of: The Luhn Algorithm.
The Luhn Algorithm is a formula which can be run in javascript, PHP, and most other programming languages that uses some mathematical rules to determine if a credit card number is likely to be valid. Apparently, credit card companies issue numbers according to this algorithm, and if a number doesn’t fit it, it’s definitely not valid. Before you say to yourself “wow, that’s some neat, new technology I can use!”, note that the Luhn Algorithm has been around since 1954!
Although using this algorithm in your own projects is clearly not a necessity, I see a couple of potential advantages and a couple of potential disadvantages:
Advantages
- Instant UI feedback is a great tool to help users correct errors
- The checkmark is a nice bit of instant emotional validation to make sure users complete the process
Disadvantages
- Is there a guarantee that every card will always follow this pattern? What happens if one or many stop following it?
- Since it’s an unusual experience, does it add a bit of suspicion in some users? Would a less technical user assume their number was being broadcast across the internet more times than necessary?
I’m curious to see if this catches on as a trend.
The first time I built a checkout system and was researching CC card validation, I ran across this and was equally surprised. I also think there are deeper algorithms that allow you to determine which credit card provider issued that number (AMEX, Visa, Discover, etc. Read http://cuinl.tripod.com/Tips/o-1.htm) You’ll notice some checkouts don’t require that you choose the provider, or some auto-select it once your number is typed, which turns out to be a less-creepy version of the check mark.
We’ve used the Luhn algorithm at our small online store since we started in 2005. Reason being that in a multi-step checkout process I’d much rather let the customer know they mis-typed their credit card number prior to getting to the “place order” step.
I’ve never heard anyone mention it was creepy or suspicious, but know that it’s made the process smoother.
Using appropriate messaging rather than (or in addition to) the check would make this clearer. Using just a checkmark would be confusing/suspicious to me. Some may think that my card has been authorized or even charged (and may increase cart abandonment).
We started doing this around 2000 at the company where I was working at the time. It didn’t happen on the client in Javascript, but we did it server side before sending the number to the processor – it was a sanity check and we could decline the transaction without contacting the processor, which had costs both in transaction time and in real money for us.
I don’t think it’s an uncommon step.
-adam
Colin: Yep, I always thought type of card was just determined using the first digit, but looks like it’s slightly more complicated than that.
Jeff: Yep, messaging is key there.
Adam: Interesting. Yeah, I don’t think it’s an uncommon step on the server side. Just uncommon to give feedback to the user before they’ve actually submitted anything. There was a small debate about “feedback before submission” a couple of years ago when people started actually sending form input to servers via AJAX. The general consensus was that it was a creepy practice and except under circumstances where there was little chance any sort of sensitive info would be inputed, it shouldn’t be done. An example of where it seems to be ok is username availability checking.
Funny that it’s been around since the 50’s and used so little. Sounds useful to me.
Some have probably heard of Square by now- the credit card service being developed by Twitter founder Jack Dorsey. (For those who haven’t, see http://squarecreditcardreader.com )
This new way of using credit cards would put that capability in the hands of ordinary folk who would for one reason or another, rather take a card transaction than mess with cash.
I personally think it will get big, and was thinking how if they used this Luhn algorithm, it might serve as an added plus to assure a person paying and accepting that the transaction went through correctly.
Thanks for keeping us on our algorithmic toes Mike. :)
Tim: It’s probably only of use to a product like Square if the credit card swipe doesn’t work (which definitely happens). The algo is really meant to catch the fat-fingering of a number if and when it’s manually mistyped… I think.
OLD…
Answering your Q, this works with every card #, and has been used for client-side card validation for a very long time. See validation kits like Peter Blum, etc …
Related to comments – it’s astonishing is that sites ask for card type at all. It always is a bit irritating too when phone card takers, like florists, ask for card type. Card type is not a field used by any card processor that I am aware of, and even if it was needed it could be determined from the card number as described above. Whenever ecom sites ask users for card type, they are just wasting our time!
The same is true, actually, for “name on card”. No card processor uses the “name on card” field for validation or other processing. It’s also a useless field to ask customers for …
What is TRULY astonishing is that a system designed in the 1950s is now the basis for so much of our electronic commerce. We have such a wealth of means to authenticate people on the web … and yet we still use CC number, expiration, CVN, and house number/zip. (And give the card networks 2.5% of the transaction for the privilege) …
Peter, I could be mistaken, but I’m pretty sure I’ve seen real scenarios of actual processors that do validate the name on card.
The majority of ecommerce sites I’ve worked on over the past 10+ years do this in one form or another. Another item others haven’t mentioned is that there are test card numbers that satisfy the algorithm but are not valid card numbers. I’ve used these to test live sites without having to put the cart in test mode, or quickly hop into the gateway admin and cancel the charge. I don’t know if all gateways do this, but at least the ones I’ve used will accept the number as valid, but not process it as a real sale.
Ah ok I didn’t realize that Luhn Algorithm is a public domain source. Particularly since IBM is always so tight with everything they do and never release (to my knowledge) anything as PD.
So – if no pre-post feedback is to be given, the algorithm will only be used to sanity check numbers before the payment is processed? Is that really that useful?
Amazon.com now does this live credit card checking in their checkout.
Sorry, but this was around since 1999. Allas not for credit card numbers afaik, but almost identical algoritm is used in validating some european bank account numbers, by javascript and in a website. Before that, it was used by just about any financial application to check for erroneous entries.