How to Correctly Detect Credit Card Type
creditcardjs.com
creditcardjs.com
I'm afraid this is not completely accurate at all. There are many credit card IINs and those are just a very few and will not work with some international cards (including international visa cards). Those numbers are issued by the American Bankers Association - in accordance to ISO 7812. They are not attached to a credit card flag, but to a company and a single company can have only one IIN. What happens is that Visa is composed of many companies in many countries, that's why they have many IINs which may or may not start with the same numbers, there are no strict rules about that.
The number this website calls 'prefix' is actually named IIN and it's composed of 6 characters, not 4 (nor 2 or 3). They are disposed in groups of 4 for a variety of reasons and no issuer owns whole lots of IINs.
The only completely correct way to detect a credit card is to just contact ABA to obtain a list of issued IINs.
This is what an issued IIN looks like, we also have many:
https://drive.google.com/file/d/0B-Sa2A0cesh4eDVMY3NwQ3ZEVlZ...
I also built a thing to help me parse those numbers (ruby):
https://www.fazenda.sp.gov.br/sped/downloads/GUIA_PRATICO_DA...
Some systems are very sensitive to transient data and pretty much needs to store all of it, depending on how you plan to use that data later it can add a good number of tables to your software.
For example, if I have a business here in Japan, I doubt I could easily charge a card issued by your company (I'll be happy to be proven wrong).
Ps: brasileiro aqui.
The general idea is this: IIN is issued to visa branches around the world each branch can only have one IIN. Problem is, visa is not the only issuer of visa cards. Many banks and financial institutions can also issue in lieu of visa and have their own IINs as they please. My visa credit card starts with 2 because it was issued by an airline under a mileage program. I never had problem using it online but most websites won't show the correct card type.
Merchants are not charged according to a card type, the charges applied to merchants have nothing to do with visa. Visa is only doing processing service for a bank. Banks are the ones who charges merchants and pay visa a percentage of the fee the bank charges you. Because banks can't handle the volume of merchants, they usually have gateways or other companies to do that for them.
My company also issue visa cards and we use the same IIN: 6371.
For example of the extra detail that is really involved, see: http://en.wikipedia.org/wiki/List_of_Issuer_Identification_N... - e.g. 504837 is ATM only despite looking like a MasterCard.
Card identification also occasionally changes - Diners was bought by MasterCard, Visa used to be 13 digits, etc.
I'd be really wary of hard-coding this anywhere. If it passes the Luhn algorithm and the first digit is ok, consider just passing it on to your processor and seeing if it gets approved. Add a black list of known-not-to-be-valid prefixes if you'd like. But a whitelist of valid prefixes will break one day without warning while also not really being the full list of valid prefixes you think it is.
If you really need to be doing this, you can pay for a regular feed from a processor, but the only use case I've ever seen for truly needing that was to identify debit cards by number.
I've had cashiers force through faked manual auths on 19 digit private bank debit cards, which I assume is fraud disguised as incompetence. But I think dealing with a few weird cases (with proper auditing in place) is better than declining a legit card because they expanded the valid prefixes and your code wasn't updated.
MasterCard didn't acquire Diners, it was just a partnership where Diners cards were branded as MasterCard and processed through MasterCard's network. Later Discover acquired Diners, and now they're processed through Discover's network.
But fair point - brand prefixes occasionally change, and if you hardcode them they'll eventually become out of date.
People are just typing them directly off the card, let them type them. Don't force them to deal with large and annoying select boxes. Stripe checkout[1] is a good example of how to do it (though by no means were they the first to do this, just a popular example).
(Sometimes it's weird with a list of states, where it might be sorted by the state abbreviation while showing the state name or vice versa.)
I know what card I have, you telling me "Yep that's a VISA card" isn't really that helpful. Yes, I might enter the first four digits wrong and see the wrong card icon light up may help me a little, but aren't I just as likely to enter the last 12 digits wrong. In the case of VISA you're pretty much just telling me "Yep, that first one is a 4".
It's a valid thing to say, and a valid thing for you to detect and notify the user about. You know, before they finish typing everything else they have to type in.
As to why it can't be detected and just neither asked nor shown, it's handy to show people where the CVV2 number is, and how many digits, as many people don't understand what it is even after repeated use. You'd be surprised how often I call in a food order with my Amex and have them tell me it's a 3 digit number on the back of the card. Even someone who takes CC numbers all day doesn't know that an Amex's CVV2 is a 4 digit number on the front, so you can't expect average Joe Amex user to know better.
Also it's nice to group the digits properly when I'm typing them in. So it's nice to have a form at least detect it, even for me.
[1] http://ecommerce.shopify.com/c/shopify-discussion/t/heads-up...
It might be better to let the customer pick their card type, that you could also better inform them that you do not accept their card type.
Using a complicated one line regular expression to do all the magic is fun, but its a nightmare to maintain and figure out how it works later on.
I did some quick searching and didn't find it... I wonder how they implement a key search in the inversion map. I assume you do something like populate a tree with the range transition points and then you can search in O(log n).
A search on the tree would have to find the node with the highest value that was <= the requested value, or the lowest value that was >= the requested value.
I assume the work of constructing the tree would have to be amortized over multiple searches to make it worth the effort. Could you do better than O(n) without building a tree?
In creditcardjs.com's case, they have overlapping ranges, which means you can possibly return multiple values for a given key.
Gizmodo (strangely) posted an interesting article on how on credit card numbers work: http://gizmodo.com/how-credit-card-numbers-work-1493331190
From the comments here I believe that some more work is needed for the card detection, however, to 'roll your own' with your employer paying? Could cost more than $299.
Personally I think there is a lot to be said for basic checking and having a drop-down for the card type with the accepted card types spelt out for people. Oh, and with a Paypal option for those that don't like putting their card details into random websites.
Correct me if I'm wrong, but it just seems like a user-friendly form with client side validation. You still need to integrate it with a payment processor, hook it into your checkout process where you capture delivery, billing and order information.
I also think it's not worth $299, especially when each license is per-website only.