Skip to content
This repository was archived by the owner on Jan 10, 2018. It is now read-only.

Remove visaelectron from card brands. #244

Merged
merged 1 commit into from
Aug 23, 2016
Merged

Conversation

jenanwise
Copy link
Contributor

r? @dotch

Summary

Remove visaelectron from card brands.

This is a breaking change. I will increment the next release to 2.0.0.

Motivation

We don't differentiate other Visa-branded sub-Visa brands (e.g. "Visa Debit"),
there aren't clear public BIN range distinctions, and we had some false
positives (#243).

Users who really want to differentiate Visa Electron can add their own custom
ranges.

Testing

Removed test cases relating to Visa Electron.

We don't differentiate other Visa-branded sub-Visa brands (e.g. "Visa Debit"),
there aren't clear public BIN range distinctions, and we had some false
positives.

Users who really want to differentiate Visa Electron can add their own custom
ranges.

This is a breaking change.
@willisplummer
Copy link

Hey @jenanwise, I'm not sure that it makes sense to remove support for Visa Electron. Maestro is a sub-Mastercard in the same sense that Electron is sub-Visa, and in both cases, there are specific requirements about processing transactions on these cards (via 3d secure), so there's value in being able to distinguish them from the rest of their parent ranges.

more info on Maestro here: http://www.maestrocard.com/uk/

more info on 3d secure here: https://support.stripe.com/questions/does-stripe-support-3d-secure-verified-by-visa-mastercard-securecode

@jenanwise
Copy link
Contributor Author

There are a few different uses of client-side BIN->brand detection:

  • showing users a logo to confirm that the merchant recognizes their card
  • formatting the card number (e.g. amex vs visa)
  • restricting usage to a subset of card brands / other validation

Because perfect BIN data is not really publicly accessible, we have to balance the above needs with the cost of maintaining lossy mappings.

You are correct that Maestro is a sub-brand of Mastercard, but unlike Visa Electron, it:

  • has different length requirements than mastercard
  • has significantly different branding
  • has not had any recent significant BIN prefix clashes

In a perfect world, we'd have a 0kb magic map from BIN to brand+sub-brands, but that's obviously not feasible. So, we have to make tradeoffs, and for this case I'd rather err on including Visa Electron in Visa.

If detecting Visa Electron on the client is particularly important to you, and you have actionable BIN ranges, you should definitely extend $.payment.cards on your client!

I'm not sure I understand the 3dsecure comment. 3dsecure capabalities should probably be done at the server at the time of tokenization / whatever else your payment processor is doing, rather than being looked up statically on the client (again, due to lossy mappings).

@dotch
Copy link

dotch commented Aug 22, 2016

👍
Code looks good! And thanks for the detailed explanation.

@jenanwise jenanwise merged commit 96fb32d into master Aug 23, 2016
@jenanwise jenanwise deleted the jenan-remove-visa-electron branch August 23, 2016 16:19
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants