Edited specification to remove notions of open/proprietary #70
Conversation
Issue 67 was about lack of definitions of proprietary and open; w3c#67 Those terms were not necessary for the specification, so it was edited to remove the concepts.
| <li> Users may choose to use "open" or "proprietary" payment methods, so the payment app ecosystem must support both. Users must be able to register payment apps of their choosing. We expect the user to have greater choice of third party payment apps for open payment methods than for proprietary payment methods. Examples of open payment methods include card payment and SEPA credit transfer.</li> | ||
| <li> For privacy, the design should limit information about the user's environment available to merchant without user consent. That includes which payment apps the user has registered. For open payment methods, the merchant should not receive information about which payment app the user selected to pay unless the user consents to share that information. See <a href="https://github.com/w3c/browser-payment-api/issues/224">issue 224</a> for discussion about how merchant may track progress of a push payment.</li> | ||
| <li> Although decoupling relieves merchants of implementing some aspects of the checkout experience, one consequence is that they give up some degree of control. This was already the case for proprietary payment methods, but for open payment methods such as cards, merchants (or their PSPs) will be entrusting some portion of data collection to third party payment apps.</li> | ||
| <li> User choice of payment apps that support a given payment method will depend on the payment method. For example, there may only be one app authorized to support a payment method owned by a company, while there may be many apps that support basic credit card payments or credit transfers.</li> |
There was a problem hiding this comment.
Proposed:
User choice of payment apps that support a given payment method will depend on the method and, specifically, if that method has a manifest that limits the apps that are allowed to process payment requests for that method.
| <li> Although decoupling relieves merchants of implementing some aspects of the checkout experience, one consequence is that they give up some degree of control. This was already the case for proprietary payment methods, but for open payment methods such as cards, merchants (or their PSPs) will be entrusting some portion of data collection to third party payment apps.</li> | ||
| <li> User choice of payment apps that support a given payment method will depend on the payment method. For example, there may only be one app authorized to support a payment method owned by a company, while there may be many apps that support basic credit card payments or credit transfers.</li> | ||
| <li> For privacy, the design should limit information about the user's environment available to merchant without user consent. That includes which payment apps the user has registered. The merchant should not receive information about which payment app the user selected to pay unless the user consents to share that information; of course when there is only one payment app for a given payment method that information is already publicly known. See <a href="https://github.com/w3c/browser-payment-api/issues/224">issue 224</a> for discussion about how merchant may track progress of a push payment.</li> | ||
| <li> Although decoupling relieves merchants of implementing some aspects of the checkout experience, one consequence is that they give up some degree of control. This was already the case for some payment methods, but for traditional card payments, merchants (or their PSPs) will be entrusting some portion of data collection to third party payment apps.</li> |
There was a problem hiding this comment.
Propose:
some portion of data collection to the browser or third party payment apps.
| @@ -397,7 +397,7 @@ | |||
| <li> A PAI should include origin information. This origin information may be used in a variety of ways: | |||
| <ul> | |||
| <li> The origin information could enable user agents to provide the user with useful services when the user is browsing a site with the same origin (e.g., putting that payment app at the top of a list or otherwise highlighted).</li> | |||
| <li> For a "proprietary" payment method with an associated origin, the user agent can do some (security) checks by comparing the origin of the payment method and the payment app.</li> | |||
| <li> For a payment method with an associated origin, the user agent can do some (security) checks by comparing the origin of the payment method and the payment app.</li> | |||
There was a problem hiding this comment.
Propose:
For a payment method with an associated origin, and in the absence of a manifest, the user agent can do some (security) checks by comparing the origin of the payment method and the payment app.
| @@ -1048,7 +1048,7 @@ | |||
|
|
|||
| <p>For the display of recommended payment apps:</p> | |||
| <ul> | |||
| <li>The user agent <span class='rfc2119'>SHOULD</span> display recommended payment apps.</li> | |||
| <li>The user agent <span class='rfc2119'>SHOULD</span> display recommended payment apps and configuration to not display recommended payment apps.</li> | |||
There was a problem hiding this comment.
This sentence doesn't really make sense.
Propose:
display recommended payment apps and allow user configuration to not display recommended payment apps
|
I liked your suggestions and pushed some updates as follows: I don't think we should assume a manifest is the only mechanism here, so I've tweaked your suggestions to speak about payment method owner authorization (which, for example, might Ian |
I think we should be explicit so that anything other than relationships between method and app managed by a manifest are outside our scope... E.g.: Assuming there is some other mechanism for payment method X's owners to manage the relationship between their X and payment apps (like a special agreement with browser vendors that Y app is the preferred app for their payment method and Y and Z must never appear together). If the behaviour that the browsers implement doesn't match what we have specified then they are not conforming to the spec. But, if the spec only defines behaviour for when a manifest is the source of the method/app relationship then they can implement these custom behaviours without being non-conforming. |
-issue 224 re push payments -issue 37 re cancelation (and discussion of UA retry)
- Per discussion 30 Nov 2016 [1], alignment of manifest members with Web App Manifest, a link to issue 69, and a note about needing further discussion about the alignment. [1] https://www.w3.org/2016/11/30-apps-minutes#item03
See minutes: https://www.w3.org/2016/11/30-apps-minutes#item05 * Support for selection of options is now required. * Changed language from “display” to “enable selection”
label field was changed to name field in PaymentAppOption.idl and PaymentAppManifest.idl and also required keyword was added. spec list: https://w3c.github.io/webpayments-payment-apps-api/#payment-app-options https://w3c.github.io/webpayments-payment-apps-api/#payment-app-manifest w3c/payment-handler#70 BUG=661608 Review-Url: https://codereview.chromium.org/2562873002 Cr-Commit-Position: refs/heads/master@{#439192}
Issue 67 was about lack of definitions of proprietary and open;
#67
Those terms were not necessary for the specification, so it was edited
to remove the concepts.