From 2f8fe2253a59d3f60881da61f87263e18c883778 Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Thu, 8 Sep 2016 14:49:13 -0500 Subject: [PATCH 1/4] Small tweaks - Add link to https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#user-experience -descriptions - Add more examples of app ordering based on comments people have made. --- index.html | 19 +++++++------------ 1 file changed, 7 insertions(+), 12 deletions(-) diff --git a/index.html b/index.html index 7b58201..e21888c 100644 --- a/index.html +++ b/index.html @@ -719,10 +719,7 @@

Selectable App Information Display

-

- Which of these scenarios do we expect to support through the set of technologies, and should we seek to harmonize - the user experience across them? -

+

We have identified a number of user experiences that we would like to harmonize. Just a few examples here:

  1. User has no registered payment apps.
  2. User has apps with supported but no enabled payment methods.
    3. @@ -731,10 +728,6 @@

    Selectable App Information Display

  3. User agent wishes to recommend a payment app that supports a payment method for which the user does not currently have a supporting payment app.
-

- Current ideas for supporting 4 and 5 include (1) using the "recommended payment apps" approach of this - spec (2) using payment method identifiers to designated recommended payment apps. -

@@ -742,11 +735,13 @@

Examples of Ordering of Selectable Payment Apps

The following are examples of user agent display behavior.

From c63fd4bf74de8c192994ce83f9de3e0f6234f52e Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Thu, 8 Sep 2016 15:04:27 -0500 Subject: [PATCH 2/4] Updates regarding service worker approach Putting more links and notes in the spec about the forthcoming service worker approach --- index.html | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/index.html b/index.html index e21888c..c6c4ada 100644 --- a/index.html +++ b/index.html @@ -545,6 +545,10 @@

Payment App Registration, Updates and Unregistration

See issue 20 about whether we should have two identifiers (or one) and expectations for dereferencing.

+

+ See discussion about how to organize registration data. Can or should it be part of a "payment method" manifest? What is relationship to appmanifest for specifying icons, etc.? +

+

The PaymentOption dictionary

@@ -573,7 +577,10 @@ 
The PaymentOption dictionary
-

PaymentApp.register()

+

PaymentApp.register()

+ +

This section will need to be updated in light of issue 33 and the draft proposal from Adam Roach.

+

The register method is used to register, update, or unregister a payment app with a user agent.

@@ -761,11 +768,8 @@

Payment App Invocation, Display and Response

invoking the payment app, providing the request data to the payment app, and returning the payment app response through the Payment Request API.

-

- This specification defines an HTTP-based mechanism to provide data to the payment app. Payment apps may use - a variety of mechanisms to handle the incoming data, including server-side processing, or client-side interception - of the HTTP message by a ServiceWorker. -

+

This specification will describe a service worker approach to launching apps; see issue 33 and the draft proposal from Adam Roach. +

The Working Group should discuss how to capture good practice for payment app development, with examples that illustrate common payment flows, different platforms, etc.. A public resource (e.g., on github) could foster contributions of good practice information from the developer community.

Payment App Request Data

@@ -781,15 +785,11 @@

Payment App Request Data

Payment App Invocation

-

- The Working Group is still discussing how to invoke payment apps (e.g., via an HTTP POST to - request_url or by executing a piece of JS provided at registration). The following - algorithm assumes an HTTP POST approach. -

-

- The payment app is invoked by the user agent making an HTTP request to the app's request_url - acording to the following algorithm: -

+

+ This section will need to be updated in light of issue 33 and the draft proposal from Adam Roach.

+ +

The following algorithm is to be replace.

+
  1. Let payment request be the string that is the outcome of the steps to prepare the payment app request data. From 8b66374552ea2da3f7b57cb03d028b6edc9c6745 Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Thu, 8 Sep 2016 15:22:08 -0500 Subject: [PATCH 3/4] Registration, recommended app cleanup - Based on observation from Rouslan, clarified that registration may happen through other means than this API - Editorial cleanup (merchant-recommended => payee-recommended) - Removed concept of user agent-recommended apps for now --- index.html | 49 ++++++++++++++++++++++++------------------------- 1 file changed, 24 insertions(+), 25 deletions(-) diff --git a/index.html b/index.html index c6c4ada..3f22e76 100644 --- a/index.html +++ b/index.html @@ -283,7 +283,7 @@

    Decoupling and Trust

  2. Here are preferences the system might support:
    • Accepted payment methods (payment methods the merchant accepts, and no others may be used; part of payment request API)
      • -
    • Preferred payment methods (merchant-specified order part of payment request API)
      • +
    • Preferred payment methods (payee-specified order part of payment request API)
    • Recommended payment apps (payment apps the merchant prefers, but others may be used)
    3. @@ -301,33 +301,33 @@

    Registration and Unregistration

    • 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 +
    • Registration is not a prerequisite for using a payment app. In particular, a user - should be able to pay with a merchant-recommended payment app + should be able to pay with a payee-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. - The user agent stores this information for subsequent actions (e.g., when matching merchant-accepted payment methods). In this - 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.
      • +
    • When registration is desired it might happen in a variety of ways: +
        +
      • This working group will define a user agent primitive available for all types of payment apps.
        • +
      • Native apps and browsers may have platform-specific ways to achieve the same (or similar) result.
        • +
      +
    • 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 additional user action or consent.
        • -
      • When the browser recommends a payment app and the user selects it, registration can happen in that moment without - additional user action or consent. (There is an expectation that the display of browser-recommended apps will differ - 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.
        • +
      • When the user installs native payment app, registration could happen either through platform-specific mechanisms (or through this standard API) without additional user action beyond installation.
      • 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.
      • +
    • During registration as defined in this specification, + information about enabled payment methods and available payment options is provided to the user agent. + The user agent stores this information for subsequent actions (e.g., when matching payee-accepted payment methods). In this + 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 browsers to distinguish themselves in how they balance different ease of registration and security.
    • It is important for merchants and users to be able to trust the authenticity of payment apps. A starting point is to rely on origin information (e.g., if a payment app is registered on a Web site). In contexts where origin binding is not available (e.g., potentially in the case of recommended payment apps) other mechanisms should be considered to help establish authenticity (e.g., invocation-time confirmation of a digital signature of a claimed origin).
      • @@ -349,15 +349,14 @@

      Payment App Identification

      Payment App Matching

      • When the user invokes the Payment Request API (e.g., by "pushing the Buy button"), the user agent - computes the intersection between merchant-accepted payment methods and user-registered payment methods. It + computes the intersection between payee-accepted payment methods and user-registered payment methods. It does this by comparing Payment Request API data (from the payee) and data provided during registration, invoking the comparison algorithm defined in the Payment Method Identifier specification. The result is a list of matching payment options and recommended payment apps.
      • Using information provided during registration (e.g., an app name or icon),the user agent displays matching - payment options for selection by the user. The user agent may also display merchant-specified or user agent-specified recommended payment apps, which are + payment options for selection by the user. The user agent may also display payee-recommended payment apps, which are displayed distinctly for the user. This mechanism is intended to support use cases such as a merchant - recommending their own payment app to the user, or the user agent helping the user find payment apps that are - relevant for a transaction but that the user has not yet registered or enabled. + recommending their own payment app to the user, or a payment app that they trust for a proprietary payment method.

        The user agent may offer features to facilitate selection (e.g., launch a chosen payment app or option every time the user wants to pay at a given Web site); those features lie outside the scope of this specification.

      • The user selects a payment option to make a payment. The user may also select a recommended payment app.
        • @@ -379,7 +378,7 @@

        User Experience

        Payment App Invocation and Response

        • Based on information provided at registration, the user agent "launches" the payment app and provides it with - input data drawn from the Payment Request API.
          • + input data drawn from the Payment Request API. See issue 24 for information about launching the payment app in a secure context.
        • The user may interact with the payment app in a variety of ways to authorize payment, cancel the transaction, or carry out other activities supported by the payment app. This specification does not address payment app behavior other than accepting requests and returning responses to the user agent.
          • @@ -453,10 +452,10 @@

          Payment App Selection States

        recommended payment app
        -
        a payment app suggested by the payee or user agent to be registered and used to handle a specific payment request. +
        a payment app suggested by the payee that may be used to handle a specific payment request.

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

        + Inclusion might involve small changes to payment request API. The group has also discussed the idea of user agent-recommended payment apps, for example, when the user agent is aware of an app for a proprietary payment method. The current specification does not provide for user agent-recommended apps but could be extended to do so.

        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).
        @@ -742,7 +741,7 @@

        Examples of Ordering of Selectable Payment Apps

        The following are examples of user agent display behavior.

        • Display a user-configured preferred payment app at the top of a list of matching payment apps.
          • -
        • Display a merchant-recommended app that the user has also registered at the top of a list.
          • +
        • Display a payee-recommended app that the user has also registered at the top of a list.
        • Enable the user to set a default payment app for a Web site, and display that payment at the top of a list for that site.
        • Enable the user to set a default payment app for a Web site (e.g., the payment app distributed by that retailer), and display that payment at the top of a list for that @@ -864,7 +863,7 @@

          Payment App Display

          MUST render this content for the user.

            -
          1. The user agent MUST render the Response in a new secure context.
            2. +
          2. The user agent MUST render the Response in a new secure context. See issue 24.
          3. The user agent MUST make the PaymentApp.respond() method available to the page that is rendered.
          From 07d00bfba57017e8eb5f8ce0918d6a4106bfb882 Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Thu, 8 Sep 2016 16:40:27 -0500 Subject: [PATCH 4/4] More issue hooks --- index.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/index.html b/index.html index 3f22e76..7cd5b9b 100644 --- a/index.html +++ b/index.html @@ -316,10 +316,10 @@

          Registration and Unregistration

          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 - additional user action or consent.
            • + additional user action or consent. See notes from Rouslan on registration upon selection of recommended payment app.
          • When the user installs native payment app, registration could happen either through platform-specific mechanisms (or through this standard API) without additional user action beyond installation.
          • 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.
            • + consent from the user. See notes from Rouslan on gating registration on user activation.
        • During registration as defined in this specification, @@ -327,7 +327,7 @@

          Registration and Unregistration

          The user agent stores this information for subsequent actions (e.g., when matching payee-accepted payment methods). In this 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.
          • + by re-calling the registration API. (See issue 36.)
        • We expect browsers to distinguish themselves in how they balance different ease of registration and security.
        • It is important for merchants and users to be able to trust the authenticity of payment apps. A starting point is to rely on origin information (e.g., if a payment app is registered on a Web site). In contexts where origin binding is not available (e.g., potentially in the case of recommended payment apps) other mechanisms should be considered to help establish authenticity (e.g., invocation-time confirmation of a digital signature of a claimed origin).
          • @@ -336,7 +336,7 @@

          Registration and Unregistration

          Payment App Identification

            -
          • For recommended payment apps we will need payment app identifiers (PAIs).
            • +
          • For recommended payment apps we will need payment app identifiers (PAIs). See discussion around issue 35.
          • 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).
              • @@ -545,7 +545,7 @@

              Payment App Registration, Updates and Unregistration

              - See discussion about how to organize registration data. Can or should it be part of a "payment method" manifest? What is relationship to appmanifest for specifying icons, etc.? + See issue 33 and discussion about how to organize registration data. Can or should it be part of a "payment method" manifest? What is relationship to appmanifest for specifying icons, etc.?