[wiki] Why not use URL-based payment methods for each SRC system?

[adrianhopebailie]

From interoperability:

"We want to create a single SRC payment method that works across multiple SRC systems (e.g., card brand). Because a merchant may not accept payments through all SRC systems, the merchant must be able to indicate which SRC systems it accepts so that the browser can show corresponding payment handlers."

What does a "single SRC payment method" mean? Given that the next sentence implies that merchants will need to have explicit relationships with each SRC system what does a single SRC payment method provide? Is it simply a common data model?

If that is the case, our architecture explicitly supports the use case of merchants expressing a relationship to a payment system through URL-based payment methods where the payment systems is also the owner of the origin used in the URL.

Why is there an aversion to using URL-based payment methods for each SRC system?

[ianbjacobs]

Hi @adrianhopebailie,

Here is my understanding (and I can add this to the wiki if useful):

• I though instinctively that each SRC system owner would want to leverage the payment method manifest to whitelist certified payment handlers. However, after discussion with the card brands, apparently that is not something that the card brands want to do. They do not want to publish payment method manifests.
• At that point, I believe there is little semantic difference between "one PMI with supportedNetworks" versus "N PMIs without supportedNetworks." The former requires W3C (or someone else) to maintain a registry, but we are already doing that. The former is much easier to write and remember. It also conveys more strongly "There is a single payment method" which is, as I understanding, a strong message the card brands wish to send.

I am not yet sure whether the "one PMI" will be a short string or a URL. However, either way, I think the above reasoning still holds.

[adrianhopebailie]

However, after discussion with the card brands, apparently that is not something that the card brands want to do. They do not want to publish payment method manifests.

NOT needing a feature of URL-based methods is orthogonal to the issue of whether or not to use the less-appropriate short-string based system.

"one PMI with supportedNetworks" versus "N PMIs without supportedNetworks."

I disagree. When you use a short string identifier and define a data model for it then you are requiring browsers to explicitly implement validation for that data model and continue to update their code to support the changing registry.

The former requires W3C (or someone else) to maintain a registry, but we are already doing that.

This doesn't take away the need for browsers to do maintenance work whenever this registry changes.

We have done this once on the assumption that the registry will seldom if ever change and get deprecated along with basic-card in the end anyway.