The spec currently specifies:

dictionary PaymentMethodData {
    required sequence<DOMString> supportedMethods;
};

But those are not actually strings: they are either enums (e.g., "basic-card") or USVStrings for URLs. This causes problems when doing URL comparisons as required by the Payment Method Identifiers spec (which calls into the URL spec).

+1: they are enums or restricted strings for URLs.

They need to be parsed into URLs at some point. Does the spec not say when that happens?

It doesn't look like it. I was expecting it maybe in "Process payment methods" during construction of PaymentRequest.

Related: w3c/webpayments-method-identifiers#20

@marcoscaceres and @domenic,

Good catch.

The Payment Method Identifer talks about string matching, and distinguishes the enum v. URL case.
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

For the "match" requirements of Payment Request API, would it be possible to point to the definitions of matching in Payment Request API?

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.

I suggest that we raise as a separate issue: How does the payment method manifest file change Payment Request API?

Ian

@marcoscaceres,

You wrote "it needs a little overhaul tho."

That would be great. Can that be done for discussion on Thursday?
At the payment manifest discussion this week I'd like to talk about the
dependencies (PR API and payment method manifest) and whether, for example,
where the additional third party payment app matching semantics implied by the manifest
file are specified.

Ian

@marcoscaceres,

"We can probably have those discussions without needing any spec changes."

Agreed.

For the other discussion on "should we go to CR" it would be nice to see the changes. However, even if they are not ready yet, we will see them as of the CfC.
Ian

My main concern is defining when URLs are parsed (and thus when errors are thrown for bad URLs). The actual type in the IDL is not important; DOMString is fine instead of a union, as there will be no observable difference (USVString conversion would need to happen anyway at URL parsing time).

I concur.

This fees like a CR issue, but feel free to remove if not.