Re: [w3c/webpayments-payment-apps-api] Revisiting payment app filtering (#96)

> On 25 Jan 2017, at 8:01 pm, Tommy Thorsen <notifications@github.com> wrote:
> 
> can you give an example of a question that the browser cannot answer with data it has, but can be answered by executing code?
> 
> The browser is not able to answer questions regarding the contents of the data fields in PaymentMethodData and PaymentDetailsModifier dictionaries. The structure of the contents of these fields are proprietary, and only known by the payee (the merchant) and the payment provider (the one that owns the payment app).
> 
> An example of what the contents of the data field might be, can be found in the Basic Card Payment specification. Here, information about the supported networks ("visa", "amex", "mastercard", etc) and the type of card ("credit", "debit", etc) is supplied in the data field.
> 
> Is the canHandle() mechanism an absolute and fundamental requirement that we can't do without?
> 

I believe it is. The Service Worker or object that the Service Worker gets representing the PaymentRequest must be able to handle all the method calls: .canMakePayment(), .abort(), .updateWith(), etc.

> As I've said above, I'm not a great fan of this, and I feel that it shouldn't be necessary for the merchant to ask this question, as long as he
> 
Or she:) 
> can supply a fallback option in the form of a recommended payment app to ensure that the user isn't presented with a dead end in the payment request UI.
> 
I don't think we should do the recommended payment app thing - the merchant can recommend whatever they like (or fall back to basic card).
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 


-- 
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-payment-apps-api/issues/96#issuecomment-275062076