Payment Method Manifest spec - should enable country specific app discovery

[kayakalan]

Problem: The https://w3c.github.io/webpayments/proposals/Payment-Manifest-Proposal.html doesn't appear to enable User Agents to discover which app to discover and instantiate for payment handlers that have country specific versions. (Samsung Pay, for instance, has a different .apk for different markets: US, KR, etc.) Input/Analysis:

1. There are different country/market indicators that could come from different players (device, browser/userAgent, merchant), which might be used to help determine which app to instantiate - but there are problems with each of them.
2. Different globe travelers have varying interests in using different country versions of an app.
3. A common way to express countries would be needed, and to embed them in the payment manifest file.

[ianbjacobs]

Hi @kayakalan,

Would you be able to expand on the use cases in more detail? Here are some questions and thoughts that occurred to me:

• Where will the browser get the country information used to make a determination? Will it depend on the user's browsing context, the transaction context, or something else?

• I think one way to dispatch by country without adding data to the manifest file would be to publish different payment method identifiers: https://example.com/bobpay https://example.com/bobpay-kr

  I don't claim that's a good design, but it might be useful as a backup.

• The revised proposal [1] has a supported_origins field for delegating authority. I am guessing there are times when delegation might vary by country.

So it might make sense to be able to scope manifest blobs by country. But I am still interested in how the browser learns what the relevant country is, and look forward to your additional info.

Ian

[1] https://github.com/zkoch/zkoch.github.io/blob/master/pmi-v2.md

[rsolomakhin]

@ianbjacobs 's different payment method names per country proposal sounds good. Another trick is to serve different versions of the manifest files based on the client's IP address range.

Chrome does not have a good way to detect its own country, so I would stay away from defining country information in the manifest file format. I suggest to use a server-side solution.

[ianbjacobs]

@rsolomakhin,

So there are two topics: a) How the browser determines the appropriate country. You mentioned client IP address range. I want to see if that aligns with the use case @kayakalan has in mind.

b) How the browser dispatches based on that info.

You wrote: "Chrome does not have a good way to detect its own country, so I would stay away from defining country information in the manifest file format. I suggest to use a server-side solution."

Putting country information in the manifest file would not be how Chrome detects the user's country. It would be how Chrome, given country information (somehow) could then selectively interpret manifest data.

Ian

[rsolomakhin]

It would be how Chrome, given country information (somehow) could then selectively interpret manifest data.

This is the problem: Chrome does not have a good way to determine its own country.

[ianbjacobs]

@rsolomakhin,

I don't think I understand your comment yet. Here is what I am thinking (assuming, for a moment, that the manifest file includes some bits for Alan's use cases):

1) The user clicks on the Buy button. If the browser doesn't yet know what the RelevantCountry is for the session, the browser determines the RelevantCountry (e.g., by IP address). 2) The browser parses the list of payment methods provided by the merchant. For those that are URLs, the browers fetches the manifest files (if not cached). 3) The browser parses the manifest file, which includes blocks of data labeled by country. Suppose the manifest file BNF looks something like this (apologies for my lousy BNF):

    countryBlock ::= [countryIdentifiers] dataBlock
    countryIdentifiers ::= countryIdentifer ["," countryIdentifier]*

The file works like this (again, making this up for discussion):

• Any dataBlock that is not prefixed by a country label applies to any country.
• Any dataBlock that is not prefixed by one or more country labels only applies when there's a match with the RelevantCountry.
• First rule wins in case of overlap.

4) Using that algorithm, the browser determines the relevant rules and applies them. Applying them means a few things: a) Only authorized payment apps should be included in canMakePayment() and show() computations. b) The browser fetches icons, etc. based on data in the payment method manifest file.

When you say "Chrome does not have a good way to determine its own country," I'm not sure how that applies to the manifest file. Chrome would need to get information about the RelevantCountry (a process to be determined) and compare to the payment method owner's specs in the payment method manifest file.

Ian

[rsolomakhin]

the browser determines the RelevantCountry (e.g., by IP address).

This is difficult to do reliably in Chrome.

[ianbjacobs]

@rsolomakhin wrote "[determine RelevantCountry] ... is difficult to do reliably in Chrome."

Ok. This is where I'd like to hear more what @kayakalan has in mind.

Ian

[marcoscaceres]

As @rsolomakhin said, determining the country needs to be done server side or by the application (not the browser) needs to ask the user beforehand.

[kayakalan]

I believe we can close this issue now. I agree with the constraints expressed and the current spec facilitates enabling a list of apps / packages / signatures that support W3C. A company could put entries in the list that are market specific - and expect the user to have installed the one that is relevant for their market.