diff --git a/index.html b/index.html index 4cbb476..5b80e65 100644 --- a/index.html +++ b/index.html @@ -83,14 +83,14 @@
-

The Payment Request API [[!PAYMENT-REQUEST-API]] provides +

Payment Request API [[!PAYMENT-REQUEST-API]] provides a standard way to initiate payment requests from Web pages and applications. User agents implementing that API prompt the user to select a way to handle the payment request, after which the user agent returns a payment response to the originating site. This specification adds payment apps to that user experience. It defines how users - register payment apps with user agents, how user agents support the display of + register payment apps with user agents, how user agents present information about payment apps the user can select to handle the payment request, how the user selects a payment app, and how communication takes place between user agents and payment apps to fulfill the requirements of the @@ -119,17 +119,15 @@

Introduction

This specification defines:

-

Payment apps may be implemented in a variety of ways: as Web applications, native operating system applications, - 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 - specification (matching, information display, etc.).

+ +

Payment apps may be implemented in a variety of ways: as Web applications, native operating system applications, + user agent extensions, built-in user agent components, interface-less Web services, or a combination. The scope of this specification is Web-based payment apps, which are implemented as service workers.

@@ -310,155 +308,114 @@

Dependencies

Payment App Model and Design Considerations

-

This section (which may be temporary) intends to help build shared understanding of the capabilities and limitations of the specified model.

+

This section describes the capabilities and limitations of this specification in functional terms.

General Considerations

Decoupling and Trust

-

Registration and Unregistration

+

Identification

+
+
+

Registration and Unregistration

+
-

Payment App Identification

- -
-
-

Payment App Matching

+
-

User Experience

+

Payment App Matching and Selection

Payment App Invocation and Response

-
-
-

Network Considerations

-
+

Definitions

Payment App Implementation Technology
native payment app
a payment app built with the operating system default technology stack that uses non-Web technologies.
-
ignored payment app
+
ignored payment app
An app that the user has configured to not be displayed, or that the user agent ignores for security reasons.
@@ -531,11 +488,7 @@

Payment App Selection States

recommended payment app
-
a payment app suggested by the payee or user agent 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. -

+
a payment app suggested by the payee or user agent that may be used to handle a specific payment request.
displayed payment app
A matching payment app or recommended payment app with at least one matching payment method (i.e., presented by the user agent for user selection).
selected payment app
@@ -741,7 +694,7 @@

  • - Let paymentMethods be a list of URLs from manifest section + Let paymentMethods be a list of identifiers from manifest section on supported payment methods. Ensure that the payment app is licensed to claim support for the payment methods (e.g., they are explicitly authorized, or the payment method imposes no constraints). Otherwise, reject with a DOMException whose name is "NotAllowedError" and terminate these steps.
    • @@ -937,22 +890,10 @@

    The enabledMethods member lists the payment method identifiers of the - payment methods enabled by this option. When the merchant has provided a filter, it may be necessary to provide additional information about conditions under which the payment method is enabled. + payment methods enabled by this option. See also the canHandl function, which enables payment app developers to specify in finer granularity the conditions under which the payment app supports a payment method.

    -
    -

    - Payment App Manifest Location -

    -

    Aside from ServiceWorker registration, it's useful for user agents to - download the payment app manifest from a well-defined location. This allows merchants to recommend payment apps via the payment app identifier.

    -
    - How to map payment app URL to the location of the manifest file? For example, how - to map https://bobpay.com to - https://bobpay.com/payment-manifest.json? -
    -

    Registration Example @@ -1008,47 +949,10 @@

    -
    -

    - Native App Registration -

    -

    - Information required for payment apps should be present in the payment - app manifest under an extension point. For example, - information for Android native payment apps may live under - "android" section of the app manifest. This specification does - not define the contents of native app descriptions. This is defined - elsewhere. -

    -

    - What else, if anything, should we say about registering native payment - apps? -

    -

    - Native payment apps on some platforms (e.g., on Android) can claim - ownership of their origins. To verify origin ownership, user agents need to - perform extra steps that are not defined in this specification. -

    -

    Payment App Matching

    -
    -

    - We anticipate that [[!METHOD-IDENTIFIERS]] will define the PMI matching algorithm. This - specification will explain how to invoke that algorithm using data available from the Payment Request API input - and payment method information aggregated from: -

    - -

    The Working Group should discuss:

    - -
    +

    When the mediator calculates acceptedMethods during the process of running the steps for the PaymentRequest.show() @@ -1158,20 +1062,13 @@

    Payment App Matching

    Payment App Selection

    Selectable App Information Display

    -

    - After matching the user agent will have a list of payment apps that the user can select to handle the - payment request. How will these are displayed and ordered, where do recommended apps - fit in to the order and how do we treat apps that are both registered and recommended? -

    -

    - What information is needed by the user agent to display selectable apps? This needs to be captured during registration. -

    The output of the payment method matching algorithm will be a list of matching payment apps and options from registered - payment apps, and a list of recommended payment apps. The user agent will present this list of payment apps to the user for selection. + payment apps, and a list of recommended payment apps. The user agent presents this list of displayed payment apps to the user for selection. The user agent MUST enable the user to select any displayed payment app.

    -

    For matching payment apps:

    - +
    +
    +

    Matching Payment Apps

    - -

    For recommended payment apps:

    +
    +
    +

    Recommended Payment Apps

    +
    What is the means by which the payee provides information about recommended payment apps in the call to payment request API? See issue 79.
    - -
    -

    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. -
    2. User has apps with supported but no enabled payment methods.
      3. -
    3. User has apps with supported and enabled payment methods.
      4. -
    4. Merchant wishes to recommend a payment app to the user.
      5. -
    5. 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.
      6. -
    -
    - -
    -

    Examples of Ordering of Selectable Payment Apps

    -

    The following are examples of user agent ordering of selectable payment apps.

    -
      -
    • For a given Web site, display payment apps in an order that reflects usage patterns for the site (e.g., a frequently used payment app at the top, or the most recently used payment app at the top).
      • -
    • Enable the user to set a preferred order for a given site or for all sites.
      • -
    • Display a payment app that is both registered by the user - and merchant-recommended at the top of a list.
      • -
    • Display a payment app that is both registered by the user - and corresponds to the origin of the site being visited at the top of a list.
      • -
    -
    -

    Selection by the User

    +

    User Experience Considerations

    +
    +

    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. +
    2. User has apps with supported but no enabled payment methods.
      3. +
    3. User has apps with supported and enabled payment methods.
      4. +
    4. Merchant wishes to recommend a payment app to the user.
      5. +
    5. 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.
      6. +
    +
    + +

    The following are examples of user agent ordering of selectable payment apps.

    @@ -1662,9 +1551,6 @@

    Payment App Response

    -

    - See issue 37 for discussion of payment app cancellation and also resulting user agent behavior. At the 23 November 2016 payment apps task force meeting, there was consensus that in case of payment app failure or cancelation, the user agent should not be prohibited from offering the user alternative matching payment apps.

    -

    The following example shows how to respond to a payment request:

           paymentRequestEvent.respondWith(new Promise(function(accept,reject) {
@@ -1680,13 +1566,12 @@ 
    Payment App Response
    
         });
       });
    -

    - Some payment methods might require a back channel to guarantee payment - response delivery (especially push payment methods). See issue 224. [Ed Note: - the "complete()" attribute of the "PaymentResponse" interface would serve - this purpose quite cleanly.] -

    + +

    + [[!PAYMENT-REQUEST-API]] defines a paymentRequestID + that parties in the ecosystem (including payment app providers + and payees) may use for reconciliation after network or other + failures.

    Example using HTTP POST

    @@ -1796,7 +1681,8 @@

    Secure Communications

    Payment App Authenticity