Re: [w3c/browser-payment-api] supportedMethods (URL and enums) (#464)

> On 20 Mar 2017, at 11:59 pm, ianbjacobs <notifications@github.com> wrote:
> 
> @marcoscaceres and @domenic,
> 
> Good catch.
> 
> The Payment Method Identifer talks about string matching, and distinguishes the enum v. URL case.
> 

Sure, it needs a little overhaul tho.

The enum needs to be defined. The algorithm for comparison needs a little love too. 

> In addition, in the URL case, that spec talks about how the URLs are used to fetch payment method manifest files; we are still working those:
> https://w3c.github.io/webpayments/proposals/Payment-Manifest-Proposal.html
> 

This might be overstepping a bit... just trying to solve for Payment Requests. 

> For the "match" requirements of Payment Request API, would it be possible to point to the definitions of matching in Payment Request API?
> 
It's undefined right now I think. 
> The Payment Method Manifest proposal also plays a role in matching - the user agent fetches the file (in the case of a URL PMI) and determines, for example, which origins are authorized to serve payment apps for that payment method.
> 

This is all out of scope right now (as far as this issue is concerned). 

> I suggest that we raise as a separate issue: How does the payment method manifest file change Payment Request API?
> 
It shouldn't change anything right now to the level you are proposing. I'm just concerned with defining a union of an enum and USVString.

We can look at manifests etc. after. 
> Ian
> 
> —
> 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/browser-payment-api/issues/464#issuecomment-287754216