- From: Tommy Thorsen <notifications@github.com>
- Date: Tue, 01 Nov 2016 02:51:52 -0700
- To: w3c/webpayments-methods-card <webpayments-methods-card@noreply.github.com>
- Message-ID: <w3c/webpayments-methods-card/issues/19@github.com>
I've been playing around with making a proof-of-concept payment app that does basic card payment, and one issue I've run into is that it's not trivial to know the type of a card. This means that it's hard for the payment app to behave correctly, if the payee passes a list of card types in BasicCardRequest.supportedTypes. The dealing with BasicCardRequest.supportedNetworks is relatively trivial, as the network can be trivially deduced from the card number. The card type, however is hard to deduce without resorting to keeping a complete database of IINs (like the one that can be found here: [https://github.com/binlist/data](https://github.com/binlist/data)). That's a solution I'd rather not do, as it's hard to keep this list of IINs complete and up-to-date. Another solution could be to have the user select the type of card from a drop-down list. This would probably work, at least in the cases where the user does not pick the wrong type. It is, however, quite uncommon to have a field like this in a card credential input form, so it creates a little bit of added friction between the user-agent and the user, that I'd rather avoid if I could. Is the BasicCardRequest.supportedTypes absolutely necessary? Could we cut it from the specification? If not, could we specify what happens if the type for a card is unknown? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webpayments-methods-card/issues/19
Received on Tuesday, 1 November 2016 09:52:49 UTC