Commerce Payment provides a CreditCard class, which defines a number of known card types with basic property validation criteria. In working on the Braintree integration module, it appears they return a broader universe of possible card types, including the following which are not currently defined in Payment:

solo
switch
laser
carte blanche
unknown

To my knowledge, the first two are commonly encountered in the field (they're debit cards, but still "plastic.") The Carte Blanche brand was bought by Diners Club and appears to run on their network, now, however it's unknown if gateways still return the card type as a distinct entry when run as a "Diners Club Carte Blanche" card.

Also not sure what the maintainers' approach is regarding unknown card types. At current, a payment method must specify a valid name from the CreditCard class to work, so it's likely we'll need to expand the universe and possibly handle edge cases.

Comments

bradjones1 created an issue. See original summary.

bradjones1’s picture

bradjones1
Primary language English
CreditAttribution: bradjones1 as a volunteer commented
Issue summary: View changes

Removed maestro from list, it's already included.

bojanz’s picture

bojanz CreditAttribution: bojanz at Centarro commented

Solo, Switch, Laser no longer exist:
https://en.wikipedia.org/wiki/Solo_(debit_card)
https://en.wikipedia.org/wiki/Switch_(debit_card)
https://en.wikipedia.org/wiki/Laser_(debit_card)

Carte Blanche has been phased out in favor of regular Dinners Club cards:
https://en.wikipedia.org/wiki/Diners_Club_International#Carte_Blanche

Keep in mind that the CreditCard class is used only for validating numbers of onsite gateways that transfer credit card details to the site (Authorize.net, PayPal Payments Pro). For gateways such as Stripe or Braintree, the code is never invoked, cause these solutions perform their own JS validation. So not handling "unknown" types is not a huge problem for now. We basically have two options, add an alter hook, or keep adding credit card types as they come along (I believe Elo and Dankort are the only real ones not covered right now).

bradjones1’s picture

bradjones1
Primary language English
CreditAttribution: bradjones1 as a volunteer commented

Agreed on all counts, and thanks for the links to Solo/Switch... not being European I was going on some (fading) memories.

How about just a Symfony event, since those are more Drupal 8-y than a hook?

mglaman’s picture

mglaman
Primary language English
Location WI, USA
CreditAttribution: mglaman at Centarro commented

What if we implemented a resolver like service for identifying the cards - like we do price and such. Default is CreditCard class. Then someone can easily extend without invoking a whole event system and propagation.

bojanz’s picture

bojanz CreditAttribution: bojanz at Centarro commented

Too much complexity for a few missing cart types. Nothing prevents us from adding Elo and Dankort today.

niko-’s picture

niko- CreditAttribution: niko- as a volunteer commented

Hi, do we have any progress here?
For example I need Payment Card type MIR for my payment method how can I add it?
The descriptor I think should be (in current notation)

      'mir' => [
        'id' => 'mir',
        'label' => new TranslatableMarkup('Mir'),
        'number_prefixes' => ['2200–2204'],
      ],

I think that resolver is too much complexity and looks like in this resolver we should return sumething like descriptor above.
Maybe we can make this part of core pluggable using .CreditCardType.yml files as it more intended for such kind of desctiption

niko-’s picture

niko- CreditAttribution: niko- as a volunteer commented
Title: Implement more card types » Make card types plugable
niko-’s picture

niko- CreditAttribution: niko- as a volunteer commented

Or let's add all active payment card types, list is here https://en.wikipedia.org/wiki/Payment_card_number (I know that wiki is bad source but I can't found better one)