Could someone who deals with PCI compliance please explain some other nuances of credit cards that I've been curious about:<p>* Fault/Decline Codes returned from processors like CyberSource. How are these factored? How do processors do Regex on names/addresses? [1][2]<p>* CVV numbers and what they mean/how they are treated in the system? If CVV number is included does this increase chargeback protection?<p>* How CHIP cards work differently in the processing system, if at all?<p>* Do "knuckle-busters" (carbon copy physical imprints) follow any sort of compliance anymore?<p>[1] <a href="http://apps.cybersource.com/library/documentation/dev_guides/Reporting_Developers_Guide/reporting_dg.pdf" rel="nofollow">http://apps.cybersource.com/library/documentation/dev_guides...</a>
[2] <a href="http://apps.cybersource.com/library/documentation/dev_guides/AFS_IG/20050726_AFS_IG.pdf" rel="nofollow">http://apps.cybersource.com/library/documentation/dev_guides...</a>
It's certainly not necessary, but my guess is that it follows from the "Don't Make Me Think" school of UX design. If a majority of consumers have been conditioned to expect a credit-card-selection menu (or series of clickable icons), then the absence of such might confuse them and cause measurable drop-offs in the purchase completion funnel. It seems a little farfetched, but I'm sure at least someone has done the tests and proven this to be the case. (And if not, then there is truly no reason for the continued presence of these menus.)<p>Anecdotally, I've noticed that more and more sites are using autodetect features based on the first 4 digits entered. It certainly didn't put me off as a shopper; in fact, I found it a lot more elegant. But I'm an unusual guy, as are most people who work in tech. We can't assume that what's appealing or efficient to us is necessarily the same for the broader masses.
If you only accept the 4 biggest card issuers, you can get away with some dead-simple code to indicate to the user what card type their number indicates they are.<p>Personally, I bind an onkeyup event handler to fade in the appropriate icon based on the first digit of the number. This is not safe if you accept more than these 4 card types, (we don't).<p><pre><code> function detect_cc_type(number){
return {
'3': 'american_express',
'4': 'visa',
'5': 'mastercard',
'6': 'discover'
}[number[0]];
}</code></pre>
I think it was just a convention and made people feel better about having entered the form correctly. It makes sense to tell a merchant what type of card you are using even though someone "in the know" might know that it can be sussed from the digits.<p>Most payment gateways still require it even though it's probably superfluous.<p>I've also wondered why forms ask for name on card even though I'm pretty sure it's not checked by most/all processors and would never lead to a decline. Worse is that hardly any merchants pre-fill it if they've already collected your name.
I'd like to see an A/B test between the 2 options. It sounds plausible that a less-sophisticated buyer might see the Visa logo light up after they've typed the first digit of their card and get confused ("WHAT WITCHCRAFT IS THIS").
Why do credit card forms ask you to enter the credit card number without spaces between the clusters of digits, when it's simple for the machine to parse with or without them?
Working for nonprofits and church's, I know we do it because AMEX and others charge higher rates per transaction than say VISA, thus some clients only take VISA and giving a select list of options, lets the user know to use that type of card.
For a good example of how to do this right, see skeuocard:<p><a href="http://kenkeiter.com/skeuocard/" rel="nofollow">http://kenkeiter.com/skeuocard/</a>
Worked in restaurants for years while I was in college. All but 1 restaurant I worked at had systems that asked for the type of card.<p>I dont think this is limited to web forms.
This has always been a pet peeve of mine, it's totally unnecessary to ask for the card type.<p>Also, it bothers me that I can't type in my card number <i>exactly</i> as it appears on the card, with embedded spaces for readability. Stupid form! Don't tell me the number is invalid since it has spaces in it! If you don't like my spaces, take them out!
If anyone is curious about the luhn algorithm, here is one I made in C# from the example in the question:<p>static bool IsValidLuhn(string numbers)
{
if (numbers == null)
throw new ArgumentNullException("number", "number must have a value.");<p>var allNumbers = numbers
.Where((c) => c >= '0' && c <= '9')
.Reverse()
.Select((c, i) => (i % 2 == 1) ? ((Convert.ToInt32(c) - 48) * 2).ToString() : c.ToString());<p>return allNumbers.Count() > 0 ? allNumbers.Aggregate((x, y) => x + y).Sum((c) => Convert.ToInt32(c) - 48) % 10 == 0 : false;
}<p>Edit: Can sum one link me to HackerNews markdown?
I think it's one of those things where convenience for those looking at the underlying data has bled over into the UI. While you can deduce the type from the number, it's not easy for humans to do that at glance while looking over SQL query results. I could be wrong, but often, we ask users for more input than we need to because elegant UIs take lots of work.
Might also be that some people will try to enter an amex or discover card number if you don't do this. Even if you state that only visa or mc can be used, people don't always read it. Having to select an option is how you can be sure that they are aware of it. Kind of like having to check off the "I agree to the terms" checkbox.
I wonder if this was used to discourage AmEX cards(Higher processing fee), as to my knowledge these forms have originated in pre-checkout JS era and have just been copied thereafter. Would be helpful if we could get a look at the processing rates 6-7 years back.
The same reason forms make your enter your phone number in a particular format.<p>It's easier to make the user do all the work, and lazy developers can't be bothered to do simple things like strip all non-digits from a phone number.