Re: [w3c/payment-handler] interaction with payment methods doesn't appear to be defined (#249)

Hi @dbaron,

Agreed: we will need to fix the definition so that it is not definition by example. 

In previous discussions it was proposed [1] that we identify the "capability matching"
parts of request data explicitly. Along with various proposals to "standardize" the
expression of capabilities in payment method specs, some hoped that explicit labeling
of filters would make it easier to automate capability matching in future payment method
specs. Those proposals did not gain traction with browser vendors. 

The current expectation to my understanding is this:

1) No URL-identified payment methods have requested capability matching.
2) Multiple W3C payment methods have requested capability matching. That makes sense because the W3C payment methods generally seek to abstract across multiple similar systems, so up-front filtering continues to appear as a way to maximize the changes of a good user experience in matched payment handlers.
3) At least Google has said "We will look at each W3C payment method and decide whether to implement it." Part of the implementation will include capability matching. 
4) The current proposal around payment handlers is that for URL-identified payment methods capability matching will happen in the payment handler, and for W3C-defined payment methods it will happen in the browser.
5) We anticipate, therefore, that browser implementers will know which data is to be used for filtering by reading the payment method specs.

See also: pull request #170 (canMakePaymentEvent)

[1] https://github.com/w3c/webpayments/issues/170

-- 
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-handler/issues/249#issuecomment-365634216