From 06cd7c1bdcca34ec903494db39cf68b9e81fb183 Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Wed, 10 Aug 2016 13:46:46 -0500 Subject: [PATCH 1/2] Removed concept of accepted payment app Per 10 Aug discussion at payment app task force call --- index.html | 27 +++++++-------------------- 1 file changed, 7 insertions(+), 20 deletions(-) diff --git a/index.html b/index.html index 32dff1c..9c14508 100644 --- a/index.html +++ b/index.html @@ -278,24 +278,18 @@

Decoupling and Trust

  • 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.
  • 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.
  • 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 issue 224 for discussion about how merchant may track progress of a push payment.
    • -
  • 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.
    • -
  • 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.).
    • -
  • 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 use of these preferences, only provide guidance to browser vendors about taking into account both merchant and user preferences.
    • -
  • Here are preferences the system might support: +
  • 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.
    • +
  • The design therefore includes support for merchants to recommend payment apps and suggest the ordering of payment methods. The design should endeavor not to constrain how browsers make use of this information, only provide guidance to browser makers about taking into account both merchant and user preferences.
    • +
  • Here are preferences the system might support:
    • -
  • The browser uses this information in conjunction with user preferences to: +
  • The browser can use this information in conjunction with user preferences to: @@ -338,7 +332,7 @@

    Registration and Unregistration

    Payment App Identification

      -
    • For both "recommended" and "accepted" payment apps, we will need payment app identifiers (PAIs).
      • +
    • For recommended payment apps we will need payment app identifiers (PAIs).
    • A PAI should include origin information. This origin information may be used in a variety of ways:
      • The origin information could enable browsers 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).
        • @@ -460,12 +454,6 @@

        Payment App Selection States

        The Working Group has not yet agreed that the system should support recommended payment apps. Inclusion might involve small changes to payment request API.

        -
        accepted payment app
        -
        a payment app accepted by the payee. When the payee specifies one or more accepted payment apps, this is a signal that the payee only accepts these payment apps, and thus any matching is limited to these payment apps. -

        - The Working Group has not yet agreed that the system should support accepted payment apps. - Inclusion might involve small changes to payment request API.

        -
        displayed payment app
        A matching payment app or recommended payment app with at least one selectable payment option (i.e. presented by the browser for user selection).
        @@ -603,8 +591,7 @@

        PaymentApp.register()

        request_url parameter

        - The request_url is a string that - represents the request URL, which is the URL that accepts + The request_url identifies a service that accepts payment request messages via HTTP POST.

        From e90e796c58f5cecf3c7ca5a286577d18cfae32de Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Wed, 10 Aug 2016 14:01:44 -0500 Subject: [PATCH 2/2] Editorial adjustments to section on registration * based on discussion at 10 August payment app task force call --- index.html | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/index.html b/index.html index 9c14508..88e921d 100644 --- a/index.html +++ b/index.html @@ -299,7 +299,13 @@

        Decoupling and Trust

        Registration and Unregistration

          -
        • The user registers a payment app with the user agent, which provides developers with primitives for this +
        • Registration provides a way for browsers + to remain aware of the user's payment apps across transactions.
          • +
        • This design should not require registration as a + prerequisite for using a payment app. In particular, a user + should be able to pay with a merchant-recommended payment app + that the user has not yet registered.
          • +
        • When registration is desired, the user registers a payment app with the user agent, which provides developers with primitives for this purpose. For example, when using a Web-based payment app, the user can push a button to register the payment app. When using a native app, the native app can open a Web page that supports registration.
        • During registration, information about enabled payment methods and available payment options is provided to the user agent. @@ -307,8 +313,8 @@

          Registration and Unregistration

          proposal, there are no requirements for a payment app to be able to respond to user agent queries for updated registration information. In this proposal, payment apps update the information that a user agent has stored about them by re-calling the registration API.
          • -
        • We expect registrations will happen at various times (e.g., outside and inside of checkout), and with differing levels of - user consent to modify their configuration within the user agent. A general rule is that explicit consent is not required +
        • We expect registrations to happen at various times (e.g., outside and inside of checkout), and with differing levels of + user consent to modify their configuration within the user agent. In general, explicit consent should not be required while the user is within the context of the payment request UI. Here are some examples:
          • When the merchant recommends a payment app and the user selects it, registration can happen in that moment without @@ -318,15 +324,10 @@

            Registration and Unregistration

            from the display of merchant-recommended apps).
          • When the user installs native payment app, registration can happen as part of the app installation process and requires consent through the user agent it triggers the registration through.
            • -
          • Users visiting a Web site (e.g., merchant or bank) may wish to explicitly register payment apps and requires explicit +
          • Users visiting a Web site (e.g., merchant or bank) may wish to explicitly register payment apps, which would require explicit consent from the user.
          • -
        • Registration is not required to invoke a payment app or process a response. If a payment app is included in the list of - recommended apps provided by the merchant and the user selects it during the checkout process then the app is not required - to register itself with the user agent, it can still walk the user through the payment process that it provides and in the - end provide a payment response to the user agent.
          • -