Re: [w3c/payment-request] Modifiers and [[serializedModifierData]] not actually used anywhere. (#753)

This feature of filtering on specific card networks and card products is difficult and inconsistently implemented across the industry. As @marcoscaceres has pointed it, the place to solve for it is probably in privileged payment handlers where (in the case of ApplePay, for example) the payment instrument (card number) is being tokenised and in that process, there's a direct channel for that enrolment which allow extra data like card product identifiers to be passed. Even then, tokenisation has fragmented the established BIN ranges for card products and networks - there has been some discussion of doing essentially PAN level card product identification but in practice this might require an extra step in any card process (the simplest way of imagining this is by thinking about an additional call to the gateway/PSP/acquirer when a card is inserted in a terminal or a PAN is entered into a form, where the response is simply "this is the kind of card that is represented by the PAN").

IMO, the best we can do in the generic `basic-card` case is to check against static BIN tables (each browser or other payment handler implementing their own solution) and then to handle any errors gracefully, the two major cases being:
1. False positive: filter prevents some card from being presented as a choice to the user (solved by a "where's my card?" flow in the browser/handler,
1. False negative: card credential goes back in the payment response which the merchant cannot or will not accept (catered for on the merchant side with a payment failed, please try again message. The merchant may not actually know that they cannot accept that particular combination of network/product type - it depends on the richness of the API they are consuming from their provider)

As @adrianhopebailie already said, I think the broader feature of filters is useful but might have got lost a little in the focus on `basic-card`

-- 
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/payment-request/issues/753#issuecomment-415008247