Why do credit card forms ask for Visa, MasterCard, etc.?
You can tell if it's a Visa or MasterCard based on the number it starts with, i.e. 4 for Visa, 5 for MasterCard. Why do most billing forms request the type of card?
- It's not a barrier for bots (to my knowledge).
- It's redundant information.
- It's an additional button to click for someone about to pay for something.
Why? If it's for consistency of experience for users:
"Wait, why wasn't I asked what type of card I had? Everyone always asks that! Something's fishy here."
Why not just show them "Visa" (or whatever card symbol that they have) as they start typing?
I have no idea. I'm adding a credit card form now and just skipping the type. The payment gateway doesn't even care. It's all just a number. https://www.braintreepayments.com/docs/ruby/transactions/create#minimal_example
Surely this is a duplicate: http://ux.stackexchange.com/questions/31873/auto-detection-of-credit-card-type-in-a-credit-card-form
@tim.baker I'm not sure it's a duplicate, but it is highly relevant (this question is 'why do forms ask for card type' whereas that question is 'should I autodetect card type'.). Highly related, but not a duplicate in my opinion.
Because some designers are not programmers, and others just don't care if their UX is that good.
Yes, you could deduce it, but I'm glad we generally don't. I can't fully explain _why_, other than that I like things that are explicit.
For that matter, why do credit card forms prohibit me from entering spaces in my credit card number? It's much easier for me to double check the number when I have spaces than when I have a single 16 digit number. Though the forms that have separate boxes for each 4 digits are even worse from a usability perspective.
Deduce the credit card company based on the first digit? Bad idea. The moment the convention changes (in other words, if Visa starts running out of numbers, and starts beginning credit cards with an 8, e.g.), then you have a maintenance nightmare nightmare on your hands. It's only redundant information as long as the convention never changes – and conventions **do** tend to change over time. There was a time when all U.S. area codes had a 0 or 1 as their middle digit, for example, which is why we didn't need to dial the area code for all long distance numbers back then.
@J.R.: I don't think Visa is likely to run out of numbers before the Sun expands and destroys the Earth.
@Wooble - It doesn't have to be a "run out of numbers" thing – it could be a merger or split in the financial market, or any number of events that might prompt a change to the convention. My point is, if the convention changes, the software needs to be updated. If you're willing to bet that every Visa card will start with 4 and every MasterCard will start with 5 until the cows come home, then go ahead, put that in your website and save the user one click. As for me, I'll let the user click one extra radio button, and not rely on 4=V/5=MC to be an immutable truth.
@J.R. - It's really not as big of a deal as you are making it to be. No matter how the convention changes with respect to card numbering for a specific issuer, you are talking about updating the one method in your code that returns the card type based on its card number. How is that a _maintenance nightmare_?
@CodeMaverick - Relying on the credit card numbering scheme to extract information only works as long as the scheme never changes. If one website does this, it obviously wouldn't be a maintenance nightmare. But if a thousand websites decide to do this really clever trick, and the scheme changes, then it becomes a pain in the butt to fix.
@J.R. - I still am not seeing the issue. Each dev would only have their website. So the thousand sites you are referring to would have a thousand devs. That's not an issue. And if you happen to have 100's of sites, I would assume that as a dev you'd have local copies that you sync up to your servers. You could simply do a replace all, still only having to change it in one place. I dunno, I just don't see the issue. Am I missing something?
@CodeMaverick - I dunno; maybe you are, maybe you aren't. I was just trying to address the other side of the coin, that is, when you rely on some industry standard to convey information, and that standard changes, you have to change your code. Maybe it's not really that big a deal, but I still think it's worth considering the maintenance impact of design decisions. Assuming this change comes, say, six, seven, eight years down the road, the original developers may have moved on, the design decision long forgotten. In a big enough legacy system, these things can get expensive to find and fix.
@J.R. The numbering system isn’t a convention. It’s based on an international standard, and, as a result VISA can’t unilaterally change to putting an 8 on the front. Deducing the card type from the IIN range (the IIN is the prefix on the front of the card number, and is the thing covered by the standard) is a perfectly valid thing to do.
@Johnny They don’t. The one on our site intentionally strips spaces, dashes and anything else users might type to separate the digits. Sadly, most sites don’t seem to have thought about their card forms very much.
@J.R. Realistically, VISA is always going to stick to its ‘4’ prefix — though it might make the card numbers longer at some point — however Mastercard branded cards can *already* be found outside of the ‘51’/‘55’ ranges that are mentioned below (this is especially true of Mastercard’s Maestro brand, which is used for debit cards in various countries).
@alastair - Fine, maybe this isn't the best example, then. Still, all I meant to do was offer a yellow caution light. All I'm saying is that a design team ought to be careful when they decide to base their design on some convention, like, _SSNs will always be 9-digits long_, or _area codes will always have a "1" or "0" as the second digit_. Can we at least agree that it's worth thinking about, before marching forward? If a team does an analysis, and decides it's sufficiently immutable, then, fine, code it that way. But at least do the analysis first – a step that's too often skipped instead.
@J.R. Agreed, it’s important to understand the problem domain before trying to solve a problem. A good example here is that some people foolishly check the length of card numbers against their expectations; the only *actual* restrictions are that it has to be over 6 digits long and pass the Luhn checksum.
Probably this is done for the same reason that we include check digits, even if they're redundant: namely, to detect user error.
@J.R. lol, "maintenance nightmare"? If Mastercard added an alternative starting sequence to their card numbers, I'm sure it would not clash with other card issuers' numbers. 5 minutes of coding to handle the additional pattern. That... and they'll never run out of numbers anyway.
@Buttle - I think my initial comment has been misconstrued somewhat. My point is, this is a design decision essentially says: "There is something external to my program that I am relying on. My program will work, so long as that never changes. If that ever changes, though, for any reason, then the code will need to be updated." Make such decisions often enough, and the code will need more maintenance down the road. Moreover, in a large legacy system, many "5-minute" fixes take more than five minutes, if you include regression testing, etc. How many Y2K problems were fixed in 5 minutes?
@ButtleButkus: Suppose you're the sysadmin for ten sites, three of which for legacy reasons are written in languages you're not hugely practiced in. Now you have to update them all. Suppose the web programmer for a company left and they haven't hired a replacement yet. Suppose you put ten sites live, took 3 of them down, 2 of them split into five each, and 3 others merged. How many codebases do you have to update? (Okay, if you've written it ideally, one. Ideal programming isn't always followed in the real world.)
@J.R. - You said `How many Y2K problems were fixed in 5 minutes?` I would answer that with another question. How many companies spent millions upon millions of dollars redesigning out of fear when they didn't even have to worry about Y2K? When a contractor heard a company mention Y2K, it was their dream come true. Gold mine. Mana from Heaven. Your premise is simply offbase. You design for what exists today while protecting yourself as much as you can for what may come tomorrow. That said, you can't make everything dynamic. Maintenance will always exist. Things change. Period.
@J.R. - Just to demonstrate that adding a number to the end of a credit card number may not be as big of a deal as you think it is, take this VISA number **4563 9601 2200 1999** and run it through a Luhn algorithm validator. Now add a 5 to the end. Run the algorithm again. What happens? Now add a 9 to the end of that. Run the algorithm again. What happens? They all pass!
@CodeM - My "premise" for mentioning Y2K was two-fold, and you didn't seem to catch my drift. Contractual gold mines aside, there were two factors I hoped someone would see: (1) a design decision was made that made it inevitable that the code would need to be modified, if it stayed around long enough; (2) this change would ultimately need to be made long after many of the original programmers had moved on. "Maintenance will always exist; things change." You and I agree there. But I think it's worth making smart decisions now that could minimize the need for maintenance later – esp. much later.
Why do credit card forms ask for Visa, MasterCard, etc.?
The simple answer is that 10-20 years ago, no one knew any better and it sort of just became the convention.
A slightly more complex answer indirectly deals with PCI (Payment Card Industry) compliance. If you want to accept credit cards online, you have to have an IMA (Internet Merchant Account). You may obtain your IMA through a bank or PSP (Payment Service Provider).
For the sake of this scenario, we will assume you are not PCI compliant and elect to go through a PSP to obtain your IMA and to process credit card transactions. At that point, you are at the mercy of whatever PSP you choose to go with. If their credit card form asks for the card type, then by proxy you are asking for the card type. Obviously, you decide what PSP you want to use, so you can find one whose credit card form has the functionality you want.
The good news is that the convention is changing to more of a user experience convention.
Designmodo has a great article called The Ultimate UX Design of: the Credit Card Payment Form.
Here are some quotes from that article:
Help people succeed
Will you help your users succeed in their purchase, or rather make it really hard for them? It’s up to you.
If you ask for tons of optional information, therefore risking distraction, have unclear labels, or don’t inform what type of credit card you accept, your call to action is obscure and data transfer isn’t safe… don’t be surprised if many people will leave the process without completing the payment.
You’re not helping them. You’re creating additional obstacles.
Amazon tries to be as simple as possible
They also minimized the information needed to just “Card number”, “Name on card” and “Expiration date” fields. In most cases they don’t even ask for the infamous CVV code (though how they manage to proceed with the transaction without the CVV is somehow mysterious).
Amazon tries to help their customers to go through the process as quickly as possible.
Do the job for them
Gumroad choose the same way of pointing out to the user that they know what kind of credit card you’re using.
Technically it’s rather simple. Credit card numbers are created in a consistent way. American Express cards start with either 34 or 37. Mastercard numbers begin with 51–55. Visa cards start with 4. And so on. This information can be used to detect what type of credit card someone is using simply by looking at their credit card number.
Comments to this answer, since removed, brought up another question:
Do you have to display credit card logos?
With respect to displaying credit card logos @ChrisLively mentioned the following:
The reason sites put the logos up and ask the user to select is because VISA, MC and others either require it or give slightly better rates when you do. Period.
He did not cite a source, but @alastair mentioned the following later:
The bit about displaying logos is part of the scheme rules (requirements of which are typically passed on to merchants by their acquirer); MasterCard’s website mentions that it’s compulsory. I’m not sure where VISA and AMEX mention it (or whether they mention it) on their websites.
In the MasterCard Acceptance Mark Uses source @alastair cited, it says the following:
Display the Acceptance Mark at parity with all other acceptance marks/symbols/logos also displayed (with the exception of MasterCard POI locations in the U.S., where a specific regional Standard that permits otherwise exists. Refer to MasterCard Rules, Rule 5.11.1 "Discrimination" of Chapter 15, "U.S. Region Rules").
This is sort of confusingly worded. Due to the use of the word parity in that statement, it seems to me that you only have to show their logo if you show other logos, as parity means equivalent to, or a state of equality. I could be wrong though, it doesn't seem to be very clear.
Later on the same page, it seems to clarify things a little bit more:
Use on Internet Merchant Locations
At internet merchant locations, cardholders must be able to determine immediately that the particular brand is accepted. The most effective way to ensure this is to display the appropriate Acceptance Marks on the merchant's home page. At the very least, the appropriate Acceptance Marks always must be displayed where payment options are presented.
So here, the last sentence MasterCard states that Acceptance Marks always must be displayed where payment options are presented. However, they don't tell you what happens if you don't.
In conclusion, it seems that you should display credit card logos, but I'm not sure if it's an actionable offense if you don't. If anyone has a source that clarifies whether or not it is, I'd love to know and update this section.
The last thing I want mention piggybacks the original question by asking:
How can I automatically detect the credit card type so I don't have to ask for it in the form?
So for those who are curious about or don't know what the breakdown of the credit card is, I found an article on Mint.com that has an info graphic that breaks things down rather well. As a bonus, it also shows you how validate a credit card number with your mind by using the Luhn algorithm:
Now, as you should have noted from the info graphic, we are able to determine the type of a credit card by looking up the first 6 digits of the card number. These first 6 digits make up what is called the credit card's IIN (Issuer Identification Number) or BIN (Bank Identification Number).
There are a few ways you can perform a lookup of an IIN:
Make your own database comprised from the known IINs listed on Wikipedia for you to query. This list is pretty much outdated, however.
a. You only get a limited amount of free lookups and then you have to purchase a license.
a. ISO/IEC 7812-1:2006 specifies a numbering system for the identification of issuers of cards that require an issuer identification number to operate in international, inter-industry and/or intra-industry interchange.
b. ISO/IEC 7812-2:2007 is one of a series of International Standards describing the parameters for identification cards, and the use of such cards for international and/or inter-industry interchange. It describes the application and registration procedures for numbers issued in accordance with ISO/IEC 7812-1.
I still dislike the use of the word “convention”, since it really was just collective laziness and/or ignorance. A convention is something people agree upon. However, your answer is now much improved so I've up-voted it.
@alastair - I hear you. I think some people think of it in terms of it meaning the same thing as a standard or best practice, but that really isn't the case. One of the definitions of convention states that it is a *practice established by usage*. That's why I said it *became* a convention due to the, as you stated, ignorance. I did find a decent article talking about the differences between convention, best practice, and standard. Take a look and tell me what you think. That said, thanks for the upvote!
Interestingly that Design Modo article misses a trick; if you’re using drop-downs for the expiry date, you should ask for the year first. That way you can provide a sensible set of months if they pick the current year. (Yes, people routinely try to use expired cards...)
@alastair - Yea, that's true if their card expires in the current year. To avoid that accidental entry of an expired date, you should exclude *all* years prior to the current year along with excluding prior months when the current year is selected. That's what I've always done in my implementations of an expiration date on any form.
I just bought from Amazon, and did have to select my card. Also, as far as the CRV code goes, it has to do with credit card regulations, who has to ask for a crv code and who doesn't. Some online retailers don't have to.
AFAIK (but I may be wrong) the CRV code is not required and only optional, but useful in case of fraud/dispute. It you as a merchant didn't ask for it, the transaction will go through but will be at a riskier position.
@AlejandroMezcua - Exactly. Now, when it comes to subscriptions, and even some purchases, where you store a credit card, the PSP typically asks the merchant for the security code to verify that the user has the card in hand. Neither the merchant nor the PSP store the security code, as that is _never_ allowed. Since the card is initially verified with the security code and the security code is not stored, subsequent transactions process without it.
@alastair & Code Maverick: Ugh! Having to pick the card expiry year or month from a dropdown list is my biggest peeve about cc entry forms. Why am I being forced to take my hands off the keyboard to select something from a dropdown when all I need to do is type in the digits that are on my card? Yes, I know you can select items from dropdowns using keyboard only but it's far more work than just typing in the digits. Furthermore, I should be typing them in the order that they appear on the card, asking for year first if month is what's first on my card is another annoyance.
@Bill - You have a point and a lot of people design the form such that the expiration dates are textboxes. With drop downs, you won't need input validation, but with textboxes you will. So it's really up to what the developer wants to do.
@Code Maverick: Right. And, in UX, of course, it should never be up to what the developer wants to do. :-P (I'm a developer also, so I can say that.)
@Bill - while they are a little annoying, there is a good non-UX reason for using drop downs; the input isn’t captured by key logger applications. This is quite a good idea for the expiry date, since the card number and expiry date are typically all that the card issuers’ back-end systems bother to check.
@alastair: Interesting. First time I've heard a reasonable argument for the drop downs -- the classic security vs usability trade-off.
@Bill You know you can select a value in a focused dropdown by typing it, right?
@Bill No - I meant, you can type the digits just like you would in a textbox (without having to resort to the arrow keys). I commonly use this method to choose from a country selection dropdown.
@lunchmeat317: Yes. I know that. But cc month dropdowns are frequently of the form "01", "02", "03", etc. This is mostly likely to have a consistent appearance with a credit card. If you're fast, yes, you can get April in 2 hits. If you're not, you can hit "0" four times. If you take too long for that second digit, you get nowhere. Add to that the months lists that actually indicate the names of the months! Now add the cognitive load of translating month to number. It's just way easier from a user's perspective to type 2 digits -- just like on my card. I type what I see on my card.
@BillDagg No, browsers have changed the way they do `select` controls. Chrome, at least, no longer does "best match based on first character typed". Instead, you can type the entire displayed name and the browser will accept each new character as adding to the rpeviuos one. So you can get "09" in two digits, 0 and 9.