search

w3c / payment-method-id

Payment Method Identifiers specification
https://w3c.github.io/payment-method-id/
Other
23 stars 20 forks source link

Should a payment method identifier that is a URL bind that payment method to a single payment app or origin? #12

Closed adrianhopebailie closed 7 years ago

adrianhopebailie commented 8 years ago

Related to @zkoch 's proposal and also #11

If a payment method identifier is a URL does that URL point to a machine readable resource that allows the browser to establish a connection between that method and multiple apps from different origins OR does the url enforce a 1-to-1 mapping of the payment method to a payment app from the same origin.

This connection could be for the sake of security (only certain apps can be registered as supporting that method) or bootstrapping (the browser can suggest apps to the user to register during checkout).

cc @adamroach

rsolomakhin commented 8 years ago

I think there should be a machine readable resource at the URL that determines whether

  1. any payment app can handle this type of payment, or
  2. only certain payment apps can handle this type of payment.

That way the owner of the URL is in control of their own engineering and business decisions.

zkoch commented 8 years ago

I don't understand this issue. Is anyone arguing for a "url enforce a 1-to-1 mapping of the payment method to a payment app from the same origin"?

In my proposal discussing proprietary payment methods (and their respective origins) I say:

It is oftentimes the case, though not always, that there is a 1:1 mapping between a proprietary payment method and its corresponding payment application (e.g. only the PayPal application can process a PayPal payment).

and

By default, third party payment apps other than those associated with the identifying origin cannot claim to offer support for these payment methods

I'm saying the dominant use case of the existing ecosystem is, in most cases, a 1:1 mapping between method and app. There are exceptions and we should plan for these exceptions (for, by example, letting these relationships be defined in the manifest file). But we should design with sensible defaults.

adrianhopebailie commented 8 years ago

By default, third party payment apps other than those associated with the identifying origin cannot claim to offer support for these payment methods

This implies a 1-to-1 mapping, or at least prevents anyone publishing an app at a different origin to the origin in the payment method identifier.

Real world example: this prevents bestbuy.com publishing a payment app that claims to support the paypal.com payment method.

zkoch commented 8 years ago

Real world example: this prevents bestbuy.com publishing a payment app that claims to support the paypal.com payment method.

No, it doesn't. And I address this exact use case in the proposal:

For example, let's say that BobPay is a proprietary payment method, but BobPay has struck a deal with AlicePay to also allow AlicePay to return back valid BobPay payment responses. We could define a mechanism to support this within the manifest file located at bobpay.xyz/pay

By default is the key word here.

adrianhopebailie commented 8 years ago

What the proposal says is that browsers should do two things with proprietary payment method identifiers:

  1. By default, only allow payment apps from the same origin as the origin of the payment method
  2. Get the manifest file that the URL points to and process this to decide what origins can publish payment apps supporting this payment method

Issue 1: If we do this we are overloading the payment method identifier. It is an identifier of the payment method, a pointer to the payment method manifest and it's used to decide what origin payment apps can come from. That's just bad design.

Issue 2: This default behavior is very dangerous, not least because the manifest based behaviour is still very hand-wavy, but by making this the default, and easier to do than publishing a manifest, we are pushing the market in this direction.

The separation between apps and methods has always been a key part of our architecture because it ensures fair competition between payment app publishers and this means better experiences for users.

By pushing the market toward closed systems for the sake of easier implementation by app publishers we are ignoring the Priority of Constituencies (user > author > implementor > spec).

Payment method owners that want to limit payment apps to only their origin should do so the same way as those that want to open their payment method up to others, put the limits in a manifest.

Put differently, we shouldn't be proposing a design that makes it easier to create closed systems than open ones.

ianbjacobs commented 7 years ago

Closing this with the answer "no". The payment method manifest file defines mechanisms to allow for multiple apps from multiple origins: https://w3c.github.io/webpayments/proposals/Payment-Manifest-Proposal.html