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.
@J.R. - Yea, I agree that designing with the future in mind is always the smart thing to do. That said, you can't predict the future. That's why you should develop within the conventions, best practices, and standards.
@CodeMaverick and I'm guessing that if they need more numbers for cards, that that is what they'll do - add numbers to the end and make sure the new card numbers pass the old tests. If they tried changing the way the numbers start, I think all the sysadmins would stop them!
@CodeMaverick The "it'll be easy to fix if it breaks later on" attitude you display in this comment is definitely not the right spirit to have. If you've been contracted to make payment pages for hundreds of different organizations, fixing a bug like this will rarely be a simple matter of syncing up a local copy to all those servers in one shot. A site's original developer could be long gone when when something like this breaks. You should assume that no maintentance will ever be a piece of cake; that will help you focus on more robust, long-lasting solutions.
@CodeMaverick Y2K became a non-issue _because_ of all the work that went into fixing systems beforehand. And not all of them did get fixed...
@Izkata - ... and not all of them *needed* to be fixed, hence my statement.
@CodeMaverick Yes, in some ideal utopian world every function could and would be written exactly once. But we don't live in an ideal utopian world. We may have systems written in different languages. We may have systems that we inherited from another company after a merger. We may have systems developed by an off-site contractor. We may have systems where the programmer decided he couldn't use the existing function for any number of technical reasons. And we may have had programmers on our staff at some point in our history who rewrote an existing function for absolutely no good reason. ...
... "Fix it in five minutes" assumes that not only does every system in our company use the same function, but that you are 100% sure that this is so. If there's even a possibility that it isn't, you have to search for other functions. And "even if there are many just do a quick search and replace" ... How, exactly? I don't know how to write a search for "every function that deduces card type from prefix". Are you assuming that the credit card number field is ALWAYS called "credit_card_number" and never, ever "CreditCardNum" or "cardnum" or "ccnumber" or any of millions of other possibilities?
Okay, maybe "Visa ran out of numbers" isn't all that likely a scenario. But "a new credit card was established somewhere in the world and we want to be able to accept it on our site" doesn't seem unlikely at all. Let's recall that Visa, MC, and Amex are not the only credit cards in the world. There are other brands in Europe and the Far East.
@Jay - Are you actually wanting responses or are you just ranting in the form of 3 comments in a row? Not sure, but I'll answer one of your statements anyway. You say you don't know how to write a function that deduces a card type from the prefix because you don't know the name of the credit card number field. My answer to that is simple. You don't need the credit card number field. The parameter for the function can simply be the prefix, so all you have to do is pass in the first 6 digits. From there the function deduces the card type and returns it. Simple.
BTW - Google wallet does this. It understands the type of card from it's number.
@CodeMaverick: I'm not saying that you need to know the name of the credit card number field to write a "deduce the card type" function. I was replying to your comment that if the function had to be changed, one could find and/or fix all occurrences of such a function with a "replace all". My point is that that assumes that you know the "from" value to replace, i.e. you have to start out knowing the names of all the functions that perform this operation, or all the fields that contain credit card numbers. And you almost certainly do not know that, or cannot be sure that you know that.
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.
This is also a way to let the user know which cards are supported by the merchant. If you only see Visa and Mastercard options available, you won't pull out your Amex and punch all the numbers in just to have the site tell you they don't accept Amex.
Many sites do not accept Amex or Discover because of the extra fees they charge for processing. Users with Amex cards will usually check the list first preferring to use their Amex, but if it's not listed they will (begrudgingly, in my experience) fall back to their Visa or MC.
This, I think, is the most convincing UX reason. By forcing the user to select card type first, also reduces the risk of pulling the wrong card out your wallet and charging something to it by mistake.
While I agree with most of what you said, you don't have to process the card to see if it's a valid number. That's what the Luhn check is for. So you can prompt the user to enter a valid card before processing. Also, they don't have to type all of the numbers before telling them it's not supported if you choose not to have card type as a field. They need only to type in the first couple digits for that.
@CodeMaverick this is a UX question, not a programming one. For the user is fundamental to know the supported cards before start to insert the digits, a message "We don't accept American Express cards" after I digit 34 it's a bad UX design.
There's no reason to have a UI control for this. Just have a few small card logos indicating what the vendor accepts. Unlike a popup you can just look at the icons at a glance, rather than having to click on something to see the list and you get the visual logo that matches up with what's on the card itself. Less work for the user for more clarity.
@GuidoPreite - I understand what type of question it is =D I was simply pointing out facts. I agree, you can definitely tell the user what cards are supported. That is just good common sense. However, you don't have to ask them for card type at that point. That was the point I was getting at.
@BergQuester and how many people will look at the image of the card logos and ignore it as just another pretty bit of branding that gets scattered all over websites? Besides, what's wrong with making the user slow down a little in this rather important step.
@BergQuester: I have seen this on windows of retailers in the US. However, many people don't follow this convention. The convention has become that you select the card type.
@gbjbaanb Show me an a/b test that shows that small logos clearly marked as "We accept:" in the context of a credit card entry form are merely dismissed as branding and I'll concede.
Why do I have to click a combo box to see what types of cards are supported? The "accepted payment method" logos are small enough to fit in the payment screen. I'd rather look at the logos, see my card is supported, pull it out and start typing away.
Upvoted, because the question is not _how should we do this?_ The question is _Why is it currently done_. It makes sense that the dropdown would show which cards the vendor takes regardless of whether or not it's the best UX choice.
With the ability to stumble onto random webpages from other countries, there have been a couple times that the 'we accept' card icons have been the most useful indicator that the purchase might not even be possible (without high shipping costs, etc). You could also argue that for the 7 remaining Discover card customers that the cocaine-like head-rush they get when their card is listed as accepted is reason enough.
This is just an attempt to justify poor UX after the event. There’s no reason to ask people what type of card they have; not only can you detect it automatically in many cases, but you’ve already shown people card logos at that point (you have to; it’s part of the card acceptance agreements), so they *know* what you support.
It probably is possible to design a system that figures that out on its own but it isn't great systems design to set it up that way. Different cards have different numbers of digits and it is best to explicitly state how the system should parse the values and number of digits it should expect. In the case of an error, it makes error handling easier as well.
If the consumer says it is an American Express card yet enters more than 15 digits, you can check against the first digits of the card to cross-check the type of card and, if that matches, give an error that extra digits were entered. Without that cross-check, the source of the error may be harder to figure out.
Also, it simply a way to verify the credit card. It's a check. It's also very helpful for the consumer. If he intends to pay with his Visa and he grabs his wallet and starts type 5455... he may then say "Whoa I didn't want the MasterCard."
The number of digits really isn't an issue. The first set of numbers determine the type of card so they don't need all the numbers.
That said, many systems systems can handle all of the above without having to ask the user what card it is. Inline validation to show the card type automatically as the user types would essentially accomplish the same as above without burdening the user.
Sorry, but IMO it doesn't make much sense... There is already a lot of redundant information to check for errors from the supplier (number + name + date + CSV) to see if it was a valid card. It's just another barrier for the user because that's how it's been done. Avoid setting up as many barriers as you can.
Indeed, doesn't make sense. If you know the relation between number and card well enough to reject numbers which don't match the card type, it's also easy to **show** the card type as the user types in the number. In fact, since it's based on the prefix, you can show the card type after no more than 6 digits, and often after the second digit. If you show a Visa logo and the user intended to enter his Mastercard number, he'll be surprised enough to break the (unintended) flow.
I, too, disagree. Luhn's algorithm is already used in credit card numbers, so the user can't typo the number and still have it be valid (probably), and you can display the type of card as they type. I don't see what advantage you're getting from forcing them to pick.
It's habit. There's no need to show the card type selection as the first six digits identify the card type and provider. The payment gateway will no doubt validate this themselves before forwarding to the card provider.
Do any payment systems actually check this and warn you appropriately at the right time? 95% of times I have made a mistake on an online payment form, I have got some kind of generic error page ('Something was wrong with your card details' or 'We couldn't find this account') which meant I had to re-check every single field. That, or the payment seemed to go through and then I was emailed to say it hadn't.
FWIW, Stripe Checkout automatically sets the card type when you enter the first number. It pops up the relevant logo next to the number. Very slick.
I've seens a lot of pages where although you might select between Visa/Mastercard/Maestro, it doesn't matter which one you select (for example if the default one is Visa and you forget to switch it to MC, or vice versa), as the payment will succeed.
There is one other possibility, of course: maybe someone did A/B testing and determined, for reasons that are unknown, that asking what kind of card it is works better? Seems weird that it would, but "it is shown to work better" trumps all the ad hoc theorizing in the world.
Um, Stripe sells a card processing service that does exactly what the question is asking for. As ElendilTheTail said, it pops the correct logo next to the number automatically. See https://stripe.com/docs/checkout for a demo. Really, the only reason companies still ask for it is laziness.
@FranciscoPresencia "check for errors from the supplier" -- But what if you want to check for errors immediately and locally?
@MSalters "he'll be surprised enough" -- Are you sure? How do you know he's even looking at the screen as he types?
@nmclean: There are very few people who look *only* at the keyboard while typing.
@IanLewis: Depending on the card payment system, it actually requires you to send it a certain direction because not all networks will support card types and so you have to send it to a different gateway for AMEX vs Visa or Mastercard.
@Phoshi: I don't know if you looked at the list of issuer identification numbers, but you would have to check several digits. This list is large. https://en.wikipedia.org/wiki/List_of_Issuer_Identification_Numbers
@0A0D True, indeed. A lot of companies end up using a mix of WorldPay, PayPal, SagePay, Realex and many others. The rules are simple enough to implement in code when selecting the correct gateway. A very good point I saw made on this page was that the images of the cards assist the user in selecting a card acceptable to the merchant (or indeed the merchant's choice of payment gateway).
I disagree. First paragraph basically says it's harder to implement not asking explicitly. True, but that doesn't mean it shouldn't be done. 2nd paragraph is fixed by displaying the type of automatically-id'd card. If > 15 digits, it won't show AMEX. 3rd paragraph, asking for the same thing in different ways is also a good check, but you don't ask people to spell out the month as well as put in the number - just introduces more room for input error (e.g. "you said MasterCard but you entered a VISA number).
@IanLewis: Correct, AMEX is a good example because not all payment gateways will support it and neither will the merchant. The fee structure is different. So typically I have seen merchants accept VISA and MasterCard but the more "exotic" or less prevalent brands aren't listed as a supported format. So allowing people to choose would indicate that there is a specific choice. Waiting until the user starts typing is too late, even if it does make some users have to click an extra dropdown.
It's quite easy to write code to parse CC numbers, grab the type and verify the length and checksum, and even format it live; I just did it a couple months ago. As for your second and third points, it's a much better experience for the user to get live feedback than waiting until he submits the form. A user enters a number starting with amex and too long? Notify them immediately. A user meant to use a visa but enters a MC? The visual feedback of showing a MC logo should tip him off.
My answer won't be voted up but you need this one if people from China is in your customer base, which is roughly 20% of earth's population.
Most online transactions in China are though 'UnionPay' system in a certain stage, and most of them are not MasterCards, none are VISA cards (due to some nasty competition issue between UNIONPAY and VISA). It is a monopoly, but that's a fact of life. Many users do not know that they need a MASTERCARD or VISA in order to pay outside of China, and those who do, do not know whether your website is outside of China.
So in the world's largest e-commerce market, billions of users are paying online with a card that has only UnionPay logo, unfit for most international online transactions, everyday. When they visit your website, which may be even in Chinese but doesn't process payment in China (and not through UnionPay), having to choose VISA/MASTERCARD effectively turn the problem "Your website doesn't process my payment" to "Your website doesn't support my card", which gives the user a clue to seek a solution on his own (let's find a card that is supported by this site) instead of sitting there frustrated.
The same may even be true in other countries int the second / third world, that most of the bank cards floating around being used for payment everyday are not one of MASTERCARD/VISA.
You can argue that you let them type the card number. If it is neither MASTERCARD nor VISA, nor anyone your system supports, you can display a message saying "We only support this, this and this, and your card is not one of them". If you added this in your question, I wouldn't need to post this answer.
On a side note, equipped with billion-numbered users, UnionPay wish to be accepted as an international payment method, direct in competition with MASTERCARD, VISA and American Express. I hope they are not so easily accepted, because that would be a wrong lesson, that "You can win the world with China's government-lead monopoly business".
Not upvoting, but that's basically because this kind of national systems should be sorted out first. In the Netherlands, I'd expect to pay by something called iDeal (which uses the two-factor authorization of my bank and is a lot safer). A Credit Card form should only appear in the payment flow after these national options have been skipped.
In Germany, credit card payments are unusual too. But the customer doesn't choose from a list saying "sofortüberweisung or lastschrift or master card or visa", he chooses from a list which says "sofortüberweisung or lastschrift or kreditkarte" and after I have chosen Kreditkarte, I still get the question about Mastercard or Visa.
"online transactions in China... none are VISA cards" is a strange assertion, but it depends on what you really mean. Many credit cards are dual UnionPay/Visa or UnionPay/something, and services like Alipay and 99Bill allow you to pay using Visa online too. It's usually only debit cards that are UnionPay-only.
I haven't see a new VISA card issued for almost a year now. I remember in 2004 when I got my first credit card, there are more dual VISA/Unionpay than MASTERCARD/Unionpay, but now they are Matercard/Unionpay. If you know a bank still issuing VISA/unionpay in 2013? And, it is veritable that most bank cards are not associated with either (although most credit cards are, it is actually not required - I have Bank of American /debit/ card that can do VISA).
@ZhangWeiwu I have no idea where you're getting this from. Walk into any Bank of China, ICBC, Bank of Communications, China Merchants Bank, or any other major Chinese bank today and apply for one. A simple example: http://www.boc.cn/en/bcservice/bc1/
UnionPay AFAIK can be routed through Discover Network http://www.discovernetwork.com/card-network/acceptance.html
Whether your site supports a particular card and how you present this to the user is one thing. How you get this information from the customer, or if you even need to explicitly ask for it is another. The question at hand is the second.
@RumiP. That's odd. We have a debit card in Ireland called Laser, and in our e-commerce sites, we simply offer people a choice between Visa, MasterCard, and Laser. We don't ask them to jump through two menus. (Also, we treat Visa Debit cards just as Visa cards: we see no reason to split them out separately.)
@Trig they are not debit cards, they are different payment methods. It is like choosing between Paypal, Google Wallet, Amazon payments and Credit card. In most of them, the money is ultimately coming from the account to which the person's usual debit card is also connected, but they use different middlemen.
Many early e-commerce systems were fairly unsophisticated and were just text boxes that passed payment data along, so they had to record the card type to pass along to the payment processing system. I think that has just become a standard that has stuck.
Payment processing systems need to know what type a card is so that they can pass it on to the relevant payment system (Visa, Mastercard or AMEX, or in some cases a country-specific system like Switch or EMV). Unfortunately, it is quite difficult to determine from the card number exactly which type of card you have been presented with; there is a database of “IIN numbers”, which form the first part of the card number, but it is not easy to get hold of.
FWIW, all card numbers starting with the digit “4” belong to the VISA system. Card numbers starting “34” or “37” belong to American Express. The other card schemes are trickier and tend to be rather fragmented (in particular, Maestro is part of the Mastercard system, but for historical reasons there are Maestro-branded cards dotted all around the number space; as a result, it’s probably best to regard cards as Mastercard unless they belong to a range you know isn’t Mastercard’s).
See Wikipedia’s list of IINs for more information.
This is the only correct answer, and has only three votes, as opposed to 330 votes for the huge wrong answer with all the graphics, above.
@alastair This is not "the only correct answer"; the accepted answer also states "that is what the convention was" which is just as valid as this answer. You may consider huge answers with graphics less desirable, but I prefer the inclusion of references, especially the link to the article which describes how the convention is shifting. I guess my point is: You stated your opinion as fact when 330 others have already disagreed; maybe try to be a bit more open minded.
@JesseWebb “That is what the convention was” is simply *not* an answer to the OP’s question. It’s also wrong. It’s never been a “convention”.
I went with the answer I did because I addressed the question of why some sites ask for the card type. The accepted answer addresses why sites no longer need to ask. It is well put together and I don't begrudge the points, I just took a different approach. I was working with ecommerce in the 90's and I can tell you it wasn't convention, it was that the expectation of quality wasn't as high and some people got away with unsophisticated HTML forms that leveraged an out-of-the-box CGI that mailed them the info or saved it to a file or db. Laziness in a market that accepted it - that's it
The last time I paid an invoice with PayPal it automatically detected the type of card I was entering. I was a bit surprised to not have to enter my card type but I was reassured after seeing the correct card type highlighted.
TL;DR the whole thing but here is an article with a few other examples I found after a quick search: http://webstandardssherpa.com/reviews/auto-detecting-credit-card-type
From my perspective it is nice to have the card type automatically detected but I can see how it might be more complex to implement. For the majority of projects I'm involved in, implementing this would fall under the "will it make us more money?" objection and likely wouldn't be a priority. Your situation may be different and I would welcome this as a standard practice.
It will make more money if the system is used and if its use makes money. The objection might be "how much more money compared to alternative ways to spend resources" and it should be easy to overcome.
My point was there likely won't be any lost sales/transactions from not implementing the automatic card type detection. In the future that may not be true if it catches on and becomes standard.
It's almost certainly less work to implement this than to figure out if it's worth bothering or not.
The fact that your credit card has been issued by Mastercard, Visa or American Express is not necessarily related to the method of payment. While this is true for chip-less cards, it is not for cards which embeds a chip.
The Europay Mastercard Visa (EMV) standard specifies how the chip should behave, and one of the features of these chip is to support multiple applications. Each application is tied to a specific method of payment and depends on your credit card issuer and your bank .
The form asking you to select between Mastercard, Visa, etc. does not asks you for the card issuer, which can indeed be deduced from the card number, but for the method of payment, even offline.
With chip cards this is (generally) automatically selected by the physical payment terminal, depending on the card and the terminal capabilities. For example, when I use my card in France, it use the "CB (Carte Bleue)" application, common to all (or most) card issued in France, but if I use my card in the USA it will use the Mastercard application which is understood by both my card and the payment terminal. The application ID is printed on the ticket.
Offline, there is no mean to know the list of applications supported by your card which tells how the payment system should behave, so it needs to asks you. Most people will use the card issuer's method whose logo is printed on the card (Mastercard, Visa, etc.), but other methods could be available.
It is really frequent in multiple countries to have a payment method different from the card issuer's one, even if both could work to fulfill your payment (see Zhang Weiwu's answer related to China).
Depending on the payment method you choose, the payment system will have an according behavior (e.g. two-step authentication, ...).
You realize, of course, that it is impossible to make a chip-based payment merely by entering the number printed on the card, and so all of the material about chip-based payment is irrelevant to the question, right?
My point was on the variety of possible payment methods available with a single credit card, with the chip's applications as an illustration of this behavior on physical terminals.
It sends a signal on which payment methods you're accepting. Arguably, it could be equally well-accomplished by displaying the logos, but this way the customer who tends to ignore any extra information and immediately proceeds to fill in the numbers won't be told "Sorry, we don't accept Discover round here" after they've gone through the whole process of pulling the card out and entering the numbers in.
Many of the answers I've seen have been very enlightening but I want to throw another angle based on my own experience.
Many forms which are prevented to the user to collect money need to be signed off by banks and financial institutions involved. These often have very strict guidelines surrounding layout and format of the fields. Any deviation from this layout will prevent them from endorsing (or sometimes accepting payments) from your application.
As such a standard template is often kept.
That makes sense, do you have evidence that banks want to sign off on payment pages? Can you link to it?
I don't I'm afraid - I had a quick google but I'm afraid I couldn't find any to hand. I'm simply going from projects I've worked on previously. I'll try and track some down.
Good idea, I'd like to see an example but I'm sure it's out there somewhere. Banks or more specifically card processors can be very picky about situations where a physical card isn't taken as payment. I've even run into an issue where we couldn't put the word "BETA" next to a logo due to the card processor's terms.
For many sites it might be lazyness/cargo culting.
But for many the real answer is so they can charge credit card fees. We can't tell the difference between a Visa credit card or a a Visa debit card (same for all brands) based on the card number itself, so we have to rely on the users telling us.
As ever, follow the money.
Edit: I've designed at least three checkout systems for multi-million user websites. This is the reason it's been included, much as I'd like to be able to get rid of it...
Edit2: Stackoverflow question on how you can't tell debit apart from credit cards https://stackoverflow.com/questions/1479363/how-tell-the-difference-between-a-debit-card-and-a-credit-card
It is possible to distinguish between Visa and Visa debit/delta based on the number… it’s just difficult. And while I like your conspiracy theory, in actual fact the reason people ask for it is that they have to pass it to their card processor (see @Daniel’s answer, above).
@alastair Sorry, miss-read your comment - how do you distinguish between a credit card and debit card?
Sadly, the answer is that you need a database of IIN numbers, which is hard to get. The American Bankers Association is responsible for distributing it, and probably won’t give it to you. But it *is* possible.
There’s also Wikipedia’s IIN list, which is useful but, of course, incomplete and potentially out of date.
So we have a partial, unreliable, or unavailable method of distinguishing debit or credit cards, which isn't a viable real-world solution and leaves us with the fact that this *is* why many stores ask customers to select their card type.
Most *stores* don’t charge credit card fees, so no, I disagree. Mostly people only need to distinguish VISA, Mastercard and AMEX, and only so they can pass the field to their card processor.
One final comment: there are also commercial BIN/IIN database providers, some of whom are used by big-name websites for this purpose. I won’t link to them here since I have no experience with any of them (use Google if interested), but they certainly claim their databases can distinguish debit and credit cards.
Since writing that last comment, I stumbled across this document, published by Barclaycard (UK), which might be helpful to others trying to obtain an authoritative list of BIN ranges (including for credit/debit card tests): http://ask.barclaycard.co.uk/business/allfaqs/1_accepting_payments/bin_range