You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Another option is to return a list of cards that match, instead of null. That way you could, for example, highlight both Visa and Visa Electron until it’s clear which one it is. But it would be a breaking change — some implementations expect null if a single card hasn’t been matched.
A solution to that would be to return null by default, and provide an option to return a list of matched cards instead.
Actually, this can’t be done without introducing breaking changes.
For example, cards starting with 50 are Maestro cards. But cards starting with 5019 are Dankort. As you can see all Dankort cards will also match Maestro.
The way it’s solved currently, is the card ranges are sorted with more specific first: Dankort is more specific (5019) than Maestro (50) so it’s a match.
The only solution I can think of is to return a list of all matched cards. Then, you can decide how to present it in the UI (for example highlight all matched cards, or don’t highlight any until only 1 is matched).
The problem is this is a breaking change. The library historically returned only a single card — never a list — so granted, there is code out there that will break.
I think it shouldn't dim Visa Electron until you've typed enough of the number to rule it out (e.g. 40 could be either Visa). Via http://www.reddit.com/r/programming/comments/21uf5h/how_to_correctly_detect_credit_card_type/cggwbg1
The text was updated successfully, but these errors were encountered: