Re: [w3c/webpayments-payment-apps-api] Addition of new design considerations (#19)

> +<li>    A goal of this system is to decouple the payment methods used to pay from the software (payment apps) that implement those payment methods. By decoupling, merchants (and their payment service providers) can lower the cost of creating a checkout experience, users can have more choice in the software they use to pay, and payment app providers can innovate without imposing an integration burden on merchants.</li>
> +<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.</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, without knowing which app the user will select.</li>
> +<li>    We recognize, therefore, a tension between user preferences (e.g., registered payment apps, ordering of display of payment apps, etc.) and merchant preferences (e.g., control of the user experience previously implemented in a Web page, ordering of payment apps, presence of merchant's own payment app, etc.).</li>
> +<li>    The design should address this tension by enabling the merchant to express preferences for both payment methods and payment apps. The design should not constrain how browsers make us of these preferences, only provide guidance to browser vendors about taking into account both merchant and user preferences.</li>
> +<li>    Here are preferences the system might support:
> +  <ul>
> +<li>        Accepted payment methods (payment methods the merchant accepts, and no others may be used; part of payment request API)</li>
> +<li>        Preferred payment methods (merchant-specified order part of payment request API)</li>
> +<li>        Recommended payment apps (payment apps the merchant prefers, but others may be used)</li>
> +<li>        Accepted payment apps (payment apps the merchant accepts, and no others may be used). Note that this is the status quo since merchants either accept card information through UI that they control, or they redirect users to payment service providers with whom they have existing relationships. Note that if we allow merchants to restrict payment apps that might end up requiring the customer to install multiple payment apps for the same payment method, which would complicate the user experience for the same payment method.</li>
> +  </ul>
> +</li>
> +<li> The browser uses this information in conjunction with user preferences to:
> +     <li>   Filter matching payment apps (in the case of accepted payment apps)</li>

matching payment apps are also filtered based on accepted payment methods

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments-payment-apps-api/pull/19/files/f17221097d5b71d07091af0d6665c6d924616ba8#r73843135