From c09677cab29d84fb0cda9bec51b2cbf672ea3933 Mon Sep 17 00:00:00 2001 From: Shane McCarron Date: Mon, 26 Sep 2016 10:29:45 -0500 Subject: [PATCH] Use 'user agent' all the time The spec was inconsistent in the use of browser vs user agent. This change switches over to user agent everywhere except in the definition itself, where it is appropriate to describe a user agent as a browser or other... --- index.html | 60 +++++++++++++++++++++++++++--------------------------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/index.html b/index.html index 38ec31b..b93af79 100644 --- a/index.html +++ b/index.html @@ -125,7 +125,7 @@

Introduction

  • How the user agent invokes a payment app, communicates input/response data with it, and returns the response data to the underlying Payment Request API.

    • Payment apps may be implemented in a variety of ways: as Web applications, native operating system applications, - browser extensions, built-in user agent components, interface-less Web services, or a combination. + user agent extensions, built-in user agent components, interface-less Web services, or a combination. This specification does not cover every aspect of communication on every platform.

    The Web Payments Working Group has used the term "mediator" to refer to the software (here, the user agent) that carries out the activities defined in this @@ -327,7 +327,7 @@

    Decoupling and Trust

  • 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.
    • -
  • 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.
    • +
  • 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 user agents make use of this information, only provide guidance to user agent makers about taking into account both merchant and user preferences.
  • Here are preferences the system might support:
    • -
  • The browser can use this information in conjunction with user preferences to: +
  • The user agent can use this information in conjunction with user preferences to: @@ -410,7 +410,7 @@

    Payment App Matching

    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 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 +

    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.
    • @@ -420,8 +420,8 @@

    User Experience

    @@ -1250,7 +1250,7 @@

    Payment App Invocation

    Payment apps are invoked when a payee requests a payment by calling PaymentRequest.show() and the user selects a payment app (or has one implicitly selected by previously established - user preferences). If the user selects a browser-based payment + user preferences). If the user selects a user agent-based payment app to service the request, the service worker corresponding to that application receives an event with the PaymentAppRequestData containing information about the payment @@ -1316,12 +1316,12 @@

    Upon receiving a payment request by way of PaymentRequest.show() and subsequent user selection of a - browser-based payment app, the user agent MUST run + user agent-based payment app, the user agent MUST run the following steps or their equivalent:

    1. Let registration be the service worker - registration corresponding to the browser-based payment app + registration corresponding to the user agent-based payment app selected by the user.
    2. If registration is not found, reject the Promise that @@ -1372,7 +1372,7 @@

      worker is allowed to open a window.

      - The actual rendering of a payment app window is a browser + The actual rendering of a payment app window is a user agent implementation detail. While opening an entirely new window is possible, it is more likely that the contents will be rendered in a way that makes it more obvious that the interactions pertain to the payment @@ -1611,7 +1611,7 @@

      Data Validation

      Private Browsing Mode

        -
      • When the Payment Request API is invoked in a "private browsing mode," the browser should launch browser-based payment apps in a private context. This will generally prevent sites from accessing any previously-stored information. In turn, this is likely to require either that the user log in to the payment app or re-enter payment instrument details.
        • +
      • When the Payment Request API is invoked in a "private browsing mode," the user agent should launch user agent-based payment apps in a private context. This will generally prevent sites from accessing any previously-stored information. In turn, this is likely to require either that the user log in to the payment app or re-enter payment instrument details.