From 5d074101c9ff0b7c1dcc290a4eac840ffcfb47a3 Mon Sep 17 00:00:00 2001 From: Tommy Thorsen Date: Wed, 15 Mar 2017 12:47:21 +0100 Subject: [PATCH] Run the spec through HTML5-Tidy. --- index.html | 1775 ++++++++++++++++++++++++++-------------------------- 1 file changed, 882 insertions(+), 893 deletions(-) diff --git a/index.html b/index.html index e5848f5..55c95b4 100644 --- a/index.html +++ b/index.html @@ -2,10 +2,11 @@ Payment Handler API - - - - + + - + -
-

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 defines capabilities that enable Web applications - to handle payment requests.

-

- We have changed the title of this specification but left the identifier as-is. We are likely to want to assign it a new URL prior to FPWD. -

-
-
-

The Web Payments Working Group maintains - a list of all bug reports that the group has not yet addressed. - This draft highlights some of the pending issues that are still to - be discussed in the working group. No decision has been taken on - the outcome of these issues including whether they are valid. Pull - requests with proposed specification text for outstanding issues - are strongly encouraged.

-
-
-

Introduction

- -

The Web Payments Working Group seeks to streamline payments on the Web to - help reduce "shopping cart abandonment" and make it easier to deploy - new payment methods on the Web. It has published the Payment Request - API [[!PAYMENT-REQUEST-API]] as a standard way to initiate payment - requests from E-Commerce Web sites and applications.

- -

A payment app is a Web application that manages - payment requests on behalf of the user by supporting one or more - payment methods. To enable a Web application to handle payment requests, - this specification defines:

- - - -

This specification does not address how software built with - operating-system specific mechanisms (e.g., "native mobile - apps") handle payment requests.

-
- -
-

- This specification defines one class of products: -

+
+

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 defines capabilities that enable Web + applications to handle payment requests.

+

We have changed the title of this specification + but left the identifier as-is. We are likely to want to assign + it a new URL prior to FPWD.

+
+
+

The Web Payments Working Group maintains a + list of all bug reports that the group has not yet + addressed. This draft highlights some of the pending issues + that are still to be discussed in the working group. No + decision has been taken on the outcome of these issues + including whether they are valid. Pull requests with proposed + specification text for outstanding issues are strongly + encouraged.

+
+
+

Introduction

+

The Web Payments Working Group seeks to streamline payments + on the Web to help reduce "shopping cart abandonment" and make + it easier to deploy new payment methods on the Web. It has + published the Payment Request API [[!PAYMENT-REQUEST-API]] as a + standard way to initiate payment requests from E-Commerce Web + sites and applications.

+

A payment app is a Web + application that manages payment requests on behalf of the user + by supporting one or more payment methods. To enable a Web + application to handle payment requests, this specification + defines:

+
    +
  • How origins (i.e., Web sites) request permission to + handle payment requests on the user's behalf.
    • +
  • How origins register their support for different payment + methods with the user agent.
    • +
  • How origins provide information to faciliate the display + of payment options for selection by the user.
    • +
  • How user agents invoke and exchange data with payment + handlers from an origin.
    • +
+

This specification does not address how software built with + operating-system specific mechanisms (e.g., "native mobile + apps") handle payment requests.

+
+
+

This specification defines one class of products:

-
Conforming user agent
-
-

- A user agent MUST behave as described in this specification - in order to be considered conformant. In this specification, user agent means a Web - browser or other interactive user agent as defined in [[!HTML5]]. -

-

- User agents MAY implement algorithms given in this - specification in any way desired, so long as the end result is - indistinguishable from the result that would be obtained by the - specification's algorithms. -

-

- A conforming Payment Handler API user agent MUST also be a - conforming implementation of the IDL fragments - of this specification, as described in the - “Web IDL” specification. [[!WEBIDL]] -

- - -
+
Conforming user agent
+
+

A user agent MUST behave as described in this + specification in order to be considered conformant. In this + specification, user agent means a Web browser or + other interactive user agent as defined in + [[!HTML5]].

+

User agents MAY implement algorithms given in this + specification in any way desired, so long as the end result + is indistinguishable from the result that would be obtained + by the specification's algorithms.

+

A conforming Payment Handler API user agent MUST also be + a conforming implementation of the IDL fragments + of this specification, as described in the “Web IDL” + specification. [[!WEBIDL]]

+ +
-
-
-

Dependencies

-

This specification relies on several other underlying specifications.

+
+
+

Dependencies

+

This specification relies on several other underlying + specifications.

-
Payment Request API
-
The terms - PaymentRequest, PaymentResponse, - and - user accepts the payment request algorithm - are defined by the - Payment Request API specification [[!PAYMENT-REQUEST-API]].
-
HTML5
-
The terms global object,origin, queue a task, - browsing context, top-level browsing - context, structured clone, - event handler, event handler event type, - trusted event, - and current settings object are defined by - [[!HTML5]].
-
ECMA-262 6th Edition, The ECMAScript 2015 Language - Specification
-
The term Promise is defined by [[!ECMA-262-2015]]. -
-
DOM4
-
-

DOMException and the following DOMException types - from [[!DOM4]] are used:

- - - - - - - - - - - - - - - - - - - - - -
TypeMessage (optional)
AbortErrorThe operation was aborted
InvalidStateErrorThe object is in an invalid state
SecurityErrorThe operation is only supported in a secure context
OperationErrorThe operation failed for an operation-specific reason.
-
-
WebIDL
-
-

The following DOMException types from [[!WEBIDL]] are used:

- - - - - - - - - -
TypeMessage (optional)
NotAllowedErrorThe request is not allowed by the user agent or the - platform in the current context.
-
-
Secure Contexts
-
The terms secure context is defined by the Secure - Contexts specification [[!POWERFUL-FEATURES]].
-
URL
-
The URL concept and URL parser are - defined in [[!WHATWG-URL]].
-
Fetch
-
The terms Fetch, Request, Request Body, Request - Method, Header List, Response, - Context and Network Error are defined in - [[!FETCH]].
-
Service Workers
-
The terms - service worker - service worker registration, - active worker, - installing worker, - waiting worker, - handle functional event, - extend lifetime promises, - and - scope URL - are defined in [[SERVICE-WORKERS]].
+
Payment Request API
+
The terms PaymentRequest, + PaymentResponse, and user accepts the payment + request algorithm are defined by the Payment Request + API specification [[!PAYMENT-REQUEST-API]].
+
HTML5
+
The terms global object,origin, + queue a task, browsing context, + top-level browsing context, structured + clone, event handler, event handler + event type, trusted event, and current + settings object are defined by [[!HTML5]].
+
ECMA-262 6th Edition, The ECMAScript 2015 Language + Specification
+
The term Promise is defined by + [[!ECMA-262-2015]].
+
DOM4
+
+

DOMException and the following DOMException + types from [[!DOM4]] are used:

+ + + + + + + + + + + + + + + + + + + + + +
TypeMessage (optional)
AbortErrorThe operation was aborted
InvalidStateErrorThe object is in an invalid state
SecurityErrorThe operation is only supported in a secure + context
OperationErrorThe operation failed for an operation-specific + reason.
+
+
WebIDL
+
+

The following DOMException types from [[!WEBIDL]] are + used:

+ + + + + + + + + +
TypeMessage (optional)
NotAllowedErrorThe request is not allowed by the user agent or the + platform in the current context.
+
+
Secure Contexts
+
The terms secure context is defined by the + Secure Contexts specification [[!POWERFUL-FEATURES]].
+
URL
+
The URL concept and URL parser are + defined in [[!WHATWG-URL]].
+
Fetch
+
The terms Fetch, Request, + Request Body, Request Method, Header List, + Response, Context and Network + Error are defined in [[!FETCH]].
+
Service Workers
+
The terms service worker + service worker registration, active + worker, installing worker, waiting + worker, handle functional event, extend + lifetime promises, and scope URL are defined in + [[SERVICE-WORKERS]].
-
-
-

Overview of Handling Payment Requests

- -

In this document we envision the following flow:

- -
    - -
  1. An origin requests permission from the user to handle payment - requests for a set of supported payment methods. For example, - a user visiting a retail or bank site may be prompted to register - a payment handler from that origin. The user agent is not required to - prompt the user to grant permission - to the origin for each new supported payment method. A origin's - capabilities may thus evolve without requiring additional user - consent.
    2. - -
  2. To handle payments, an - origin has at least one and possibly many service worker - registrations. A service worker registration has zero or one - payment handler. -
    3. - -
  3. Registration associates with each payment handler: -
      -
    • A list of supported payment methods.
      • -
    • [Optionally] the conditions under which the handler supports a given payment method; these "capabilities" play a role in matching computations.
      • -
    • Information for organizing the display and grouping of Options - supported by the payment handler.
      • -
    -
    4. - -
  4. When the merchant calls Payment Request API - (e.g., when the user pushes a button on a checkout page), the - user agent computes a list of matching payment handlers, comparing - the payment methods accepted by the user with those supported - by registered payment handlers. For payment methods that support - additional filtering, merchant and payment handler capabilities are - compared as part of determining whether there is a match.
    5. - -
  5. The user agent displays matching payment handlers, displaying - and grouping Options according to information (labels and - icons) provided at registration or otherwise available from - the Web app.
    6. - -
  6. When the user selects an Option, the user agent fires the - paymentrequest event in the service worker whose registration - included the payment handler that provided that Option. The - paymentrequest event includes some information from the PaymentRequest - (defined in [[!PAYMENT-REQUEST-API]]) - as well as additional information (e.g., origin and selected Option). -
  7. Once activated, the payment handler performs whatever steps are - necessary to authenticate the user, process the payment, and return - payment information to the payee. If interaction with the user - is necessary, the payment handler can open a window - for that purpose.
    8. - -
  8. The user agent receives a response asynchronously once the - user has authorized payment. The response becomes the +
+
+

Overview of Handling Payment Requests

+

In this document we envision the following flow:

+
    +
  1. An origin requests permission from the user to handle + payment requests for a set of supported payment methods. For + example, a user visiting a retail or bank site may be + prompted to register a payment handler from that origin. The + user agent is not required to prompt the user to grant + permission to the origin for each new supported payment + method. A origin's capabilities may thus evolve without + requiring additional user consent.
    2. +
  2. To handle payments, an origin has at least one and + possibly many service worker registrations. A service worker + registration has zero or one payment handler.
    3. +
  3. Registration associates with each payment handler: +
      +
    • A list of supported payment methods.
      • +
    • [Optionally] the conditions under which the handler + supports a given payment method; these "capabilities" + play a role in matching computations.
      • +
    • Information for organizing the display and grouping + of Options supported by the payment handler.
      • +
    +
    4. +
  4. When the merchant calls Payment Request API (e.g., when + the user pushes a button on a checkout page), the user agent + computes a list of matching payment handlers, comparing the + payment methods accepted by the user with those supported by + registered payment handlers. For payment methods that support + additional filtering, merchant and payment handler + capabilities are compared as part of determining whether + there is a match.
    5. +
  5. The user agent displays matching payment handlers, + displaying and grouping Options according to information + (labels and icons) provided at registration or otherwise + available from the Web app.
    6. +
  6. When the user selects an Option, the user agent fires the + paymentrequest event in the service worker whose registration + included the payment handler that provided that Option. The + paymentrequest event includes some information from the + PaymentRequest (defined in [[!PAYMENT-REQUEST-API]]) as well + as additional information (e.g., origin and selected + Option).
    7. +
  7. Once activated, the payment handler performs whatever + steps are necessary to authenticate the user, process the + payment, and return payment information to the payee. + If interaction with the user is necessary, the payment + handler can open a window for that purpose. +
    8. +
  8. The user agent receives a response asynchronously once + the user has authorized payment. The response becomes the PaymentResponse (of [[!PAYMENT-REQUEST-API]]).
    9. -
- -

This specification does not address activities outside this flow, including:

-
    -
  • how the user establishes an account with an origin that provides payment services.
    • -
  • how an origin authenticates a user.
    • -
  • how communication takes place between the payee server and the payee Web application, or between a payment app origin and other parties.
    • -
- -

Thus, an origin will rely on many other Web technologies defined - elsewhere for lifecycle management, security, user authentication, - user interaction, and so on.

- -
- -
-

- Payment Handler Registration -

+ +

This specification does not address activities outside this + flow, including:

+
    +
  • how the user establishes an account with an origin that + provides payment services.
    • +
  • how an origin authenticates a user.
    • +
  • how communication takes place between the payee server + and the payee Web application, or between a payment app + origin and other parties.
    • +
+

Thus, an origin will rely on many other Web technologies + defined elsewhere for lifecycle management, security, user + authentication, user interaction, and so on.

+
+
+

Payment Handler Registration

-

- Extensions to the ServiceWorkerRegistration interface -

-

- The Service Worker specification defines a ServiceWorkerRegistration interface - [[!SERVICE-WORKERS]], which this specification extends. -

+

Extensions to the ServiceWorkerRegistration + interface

+

The Service Worker specification defines a + ServiceWorkerRegistration interface + [[!SERVICE-WORKERS]], which this specification extends.

         partial interface ServiceWorkerRegistration {
           readonly attribute PaymentAppManager paymentAppManager;
         };
-
-
-

- PaymentAppManager interface -

+
+
+

PaymentAppManager interface

       interface PaymentAppManager {
         attribute PaymentAppOptions options;
         attribute PaymentWallets wallets;
       };
-
-
options attribute
-
- This attribute allows manipulation of payment options associated with a - payment handler. To be presented to the user as part of the payment request - flow, payment handlers must have at least one registered payment option, and - that option needs to match the payment methods and required capabilities - specified by the payment request. -

Is "options" the right term here? We don't want this to - get conflated with "PaymentOptions" in the payment request - specification. Other alternatives might be "instruments" or "accounts." -

-
-
wallets attribute
-
- This attribute allows payment handlers to group payment options together and - provide a name and icon for such a group (e.g., to group together - "business account" payment instruments separately from "personal - account" payment instruments). The use of this grouping mechanism - by payment handlers is completely optional. If payment handlers use this - grouping mechanism, then matching payment options that do not appear - in any groups should still be presented to users by the browser for - selection. -
-
-
-
-

- PaymentAppOptions interface -

- 
+      

+        
options attribute

+        

+          This attribute allows manipulation of payment options
+          associated with a payment handler. To be presented to the
+          user as part of the payment request flow, payment
+          handlers must have at least one registered payment
+          option, and that option needs to match the payment
+          methods and required capabilities specified by the
+          payment request.
+          
Is "options" the right term here? We
+          don't want this to get conflated with "PaymentOptions" in
+          the payment request specification. Other alternatives
+          might be "instruments" or "accounts."

+        

+        
wallets attribute

+        
This attribute allows payment handlers to group payment
+        options together and provide a name and icon for such a
+        group (e.g., to group together "business account" payment
+        instruments separately from "personal account" payment
+        instruments). The use of this grouping mechanism by payment
+        handlers is completely optional. If payment handlers use
+        this grouping mechanism, then matching payment options that
+        do not appear in any groups should still be presented to
+        users by the browser for selection.

+      

+
+
+

PaymentAppOptions interface

+ 
       interface PaymentAppOptions {
           Promise<boolean>              delete(DOMString optionKey);
           Promise<PaymentAppOption> get(DOMString optionKey);
@@ -396,19 +377,16 @@ 

                                               PaymentAppOption details);
       };
-

- Where it appears, The optionKey parameter is a unique - identifier for the option; it will be passed to the payment handler to - indicate the PaymentAppOption selected by the user. -

-

TODO: flesh out details after the WG reaches general - consensus on the shape of this API.

-
-
-

- PaymentAppOption dictionary -

- 
+      
Where it appears, The optionKey parameter is
+      a unique identifier for the option; it will be passed to the
+      payment handler to indicate the PaymentAppOption
+      selected by the user.

+      
TODO: flesh out details after the WG reaches
+      general consensus on the shape of this API.

+
+
+

PaymentAppOption dictionary

+ 
       dictionary PaymentAppOption {
         required DOMString name;
         sequence<ImageObjects> icons;
@@ -418,43 +396,36 @@
name member
+
The name member is a string that + represents the label for this payment option as it is + usually displayed to the user.
+
icons member
+
The icons member is an array of image + objects that can serve as iconic representations of the + payment option when presented to the user for + selection.
+
enabledMethods member
- The name member is a string that represents the - label for this payment option as it is usually displayed - to the user. -
-
icons member
-
- The icons member is an array of image objects that - can serve as iconic representations of the payment - option when presented to the user for selection. -
- -
enabledMethods member
-
- The enabledMethods - member lists the payment method identifiers of the - payment methods enabled by this option. -
-
capabilities member
-
- The capabilities - member contains a list of payment-method-specific capabilities - that this payment handler is capable of supporting for this option. - For example, for the basic-card payment method, - this object will consist of an object with two fields: one for - supportedNetworks, and another for - supportedTypes. -
-
-
-
-

- PaymentWallets interface -

- 
+          The enabledMethods
+          member lists the payment method identifiers of the
+          payment methods enabled by this option.
+        
+        
capabilities member

+        
The capabilities
+        member contains a list of payment-method-specific
+        capabilities that this payment handler is capable of
+        supporting for this option. For example, for the
+        basic-card payment method, this object will
+        consist of an object with two fields: one for
+        supportedNetworks, and another for
+        supportedTypes.

+      
+
+
+

PaymentWallets interface

+ 
       interface PaymentWallets {
           Promise<boolean>              delete(DOMString walletKey);
           Promise<WalletDetails> get(DOMString walletKey);
@@ -464,18 +435,13 @@ 

                                               WalletDetails details);
       };
- -

- Where it appears, The walletKey parameter is a unique - identifier for the wallet. -

-

TODO: flesh out details after the WG reaches general - consensus on the shape of this API.

-
-
-

- WalletDetails interface -

+

Where it appears, The walletKey parameter is + a unique identifier for the wallet.

+

TODO: flesh out details after the WG reaches + general consensus on the shape of this API.

+
+
+

WalletDetails interface

       dictionary WalletDetails {
           required DOMString name;
@@ -485,30 +451,23 @@
name member
-
- The name member is a string that represents the - label for this wallet as it is usually displayed - to the user. -
-
icons member
-
- The icons member is an array of image objects - that can serve as iconic representations of the wallet when - presented to the user for selection. -
- -
optionKeys member
-
- TODO -
-
-
-
-

- Registration Example -

-

The following example shows how to register a payment handler:

- 
+        
The name member is a string that
+        represents the label for this wallet as it is usually
+        displayed to the user.

+        
icons member

+        
The icons member is an array of image
+        objects that can serve as iconic representations of the
+        wallet when presented to the user for selection.

+        
optionKeys member

+        
TODO

+      
+
+
+

Registration Example

+

The following example shows how to register a payment + handler:

+ 
          navigator.serviceWorker.register('/exampleapp.js')
          .then(function(registration) {
            registration.paymentAppManager.options.set(
@@ -562,96 +521,123 @@ 

              });
          });
-

- The Editors will update the payment method identifier syntax in this - and other examples to align with [[!METHOD-IDENTIFIERS]], once a final - format has been agreed upon. -

-
- -
-
-

Origin and Option Display for Selection

-

After applying the matching algorithm defined in Payment Request API, - the user agent displays a list of matching origins for the user to make - a selection. This specification includes a limited number of display - requirements; most user experience details are left to user agents.

- -
-

Ordering of Payment Handlers

-
    -
  • The user agent MUST favor user-side order preferences (based on user configuration or behavior) over payee-side order preferences.
    • -
  • The user agent MUST display matching payment handlers in an order that corresponds to the order of supported payment methods provided by the payee, except where overridden by user-side order preferences.
    • -
  • The user agent SHOULD allow the user to configure the display of matching payment handlers to control the ordering and define preselected defaults.
    • -
- -

The following are examples of payment handler ordering:

-
    -
  • For a given Web site, display payment handlers in an order that reflects usage patterns for the site (e.g., a frequently used payment handler at the top, or the most recently used payment handler at the top).
    • -
  • Enable the user to set a preferred order for a given site or for all sites.
    • -
  • If the origin of the site being visited by the user matches the origin of a payment handler, show the payment handler at the top of the list.
    • -
-
- -
-

Display of Options

-

The user agent MUST enable the user to select any displayed Option.

- -
    -
  • At a minimum, we expect user agents to display an icon and label for each matching origin to help the user make a selection.
    • -
  • In some contexts (e.g., a desktop browser) it may be possible to improve the user experience by offering additional detail to the user. For example, if the user's "bank.com" origin knows about two credit cards (thus, two potential responses to the same payment method "basic-card"), the user agent could display each credit card's brand and the last four digits of the card to remind the user which cards the origin knows about.
    • -
- -

Issue 98. There has been pushback to always requiring display of options (e.g., on a mobile devices). User agents can incrementally show options. Or user agents can return an empty option ID and it becomes the payment app's responsibility to display options to the user.

-
- -
-

Grouping of Options

- -

At times, the same origin may wish to group options with - greater flexibility and granularity than merely "by origin." These - use cases include:

-
    -
  • White label wallets - one origin provides wallet services for multiple vendors
    • -
  • Multiple user profiles with a single provider (e.g., business wallet vs personal wallet)
    • -
  • Multiple instruments held with a single provider
    • -
- -

A Wallet is a grouping of Options for - display purposes.

- -

To enable developers to build payment apps in a variety of - ways, we decouple the registration (and subsequent display) of - Options from how payment handlers respond to paymentrequest - events. However, the user agent is responsible for communicating - the user's selection in the event.

+

The + Editors will update the payment method identifier syntax in + this and other examples to align with + [[!METHOD-IDENTIFIERS]], once a final format has been agreed + upon.

+
- - -
-

Selection of Options

- -

Users agents may wish to enable the user to select individual displayed Options. The payment handler would receive information about the selected option and could take action, potentially eliminating an extra click (first open the payment app then select the option).

- -

Issue 98. Should we require that, if displayed, individual Options must be selectable? Or should we allow flexibility that Options may be displayed, but selecting any one invokes all registered payment handlers? One idea that has been suggested: the user agent (e.g., on a mobile device) could first display the app-level icon/logo. Upon selection, the user agent could display the Options in a submenu.

+
+

Origin and Option Display for Selection

+

After applying the matching algorithm defined in Payment + Request API, the user agent displays a list of matching origins + for the user to make a selection. This specification includes a + limited number of display requirements; most user experience + details are left to user agents.

+
+

Ordering of Payment Handlers

+
    +
  • The user agent MUST favor + user-side order preferences (based on user configuration or + behavior) over payee-side order preferences.
    • +
  • The user agent MUST + display matching payment handlers in an order that + corresponds to the order of supported payment methods + provided by the payee, except where overridden by user-side + order preferences.
    • +
  • The user agent SHOULD + allow the user to configure the display of matching payment + handlers to control the ordering and define preselected + defaults.
    • +
+

The following are examples of payment handler + ordering:

+
    +
  • For a given Web site, display payment handlers in an + order that reflects usage patterns for the site (e.g., a + frequently used payment handler at the top, or the most + recently used payment handler at the top).
    • +
  • Enable the user to set a preferred order for a given + site or for all sites.
    • +
  • If the origin of the site being visited by the user + matches the origin of a payment handler, show the payment + handler at the top of the list.
    • +
+
+
+

Display of Options

+

The user agent MUST enable + the user to select any displayed Option.

+
    +
  • At a minimum, we expect user agents to display an icon + and label for each matching origin to help the user make a + selection.
    • +
  • In some contexts (e.g., a desktop browser) it may be + possible to improve the user experience by offering + additional detail to the user. For example, if the user's + "bank.com" origin knows about two credit cards (thus, two + potential responses to the same payment method + "basic-card"), the user agent could display each credit + card's brand and the last four digits of the card to remind + the user which cards the origin knows about.
    • +
+

+ Issue 98. There has been pushback to always requiring + display of options (e.g., on a mobile devices). User agents + can incrementally show options. Or user agents can return an + empty option ID and it becomes the payment app's + responsibility to display options to the user.

+
+
+

Grouping of Options

+

At times, the same origin may wish to group options with + greater flexibility and granularity than merely "by origin." + These use cases include:

+
    +
  • White label wallets - one origin provides wallet + services for multiple vendors
    • +
  • Multiple user profiles with a single provider (e.g., + business wallet vs personal wallet)
    • +
  • Multiple instruments held with a single provider
    • +
+

A Wallet is a grouping of Options + for display purposes.

+

To enable developers to build payment apps in a variety of + ways, we decouple the registration (and subsequent display) + of Options from how payment handlers respond to + paymentrequest events. However, the user agent is responsible + for communicating the user's selection in the event.

+
+
+

Selection of Options

+

Users agents may wish to enable the user to select + individual displayed Options. The payment handler would + receive information about the selected option and could take + action, potentially eliminating an extra click (first open + the payment app then select the option).

+

+ Issue 98. Should we require that, if displayed, + individual Options must be selectable? Or should we allow + flexibility that Options may be displayed, but selecting any + one invokes all registered payment handlers? One idea that + has been suggested: the user agent (e.g., on a mobile device) + could first display the app-level icon/logo. Upon selection, + the user agent could display the Options in a submenu.

+
- -
- - -
-

Payment Handler Invocation, Display and Response

-

- Once the user has selected an Option, the user agent - fires a paymentrequest event with a Payment App Request, - and uses the subsequent Payment App Response to create a PaymentReponse - for [[!PAYMENT-REQUEST-API]]. -

-
-

Payment App Request

- The payment app request is conveyed using the following - dictionary: - 
+  

+    
Payment Handler Invocation, Display and Response

+    
Once the user has selected an Option, the user agent fires a
+    paymentrequest event with a Payment App Request, and
+    uses the subsequent Payment App Response to create a
+    PaymentReponse for [[!PAYMENT-REQUEST-API]].

+    

+      
Payment App Request
The payment app request is
+      conveyed using the following dictionary:
+      
       dictionary PaymentAppRequest {
         DOMString origin;
         sequence<PaymentMethodData> methodData;
@@ -660,401 +646,378 @@ 
Payment App Request

         DOMString optionId;
       };
     

-    

-      
origin attribute

-      

-        This attribute a string that indicates the origin of the
-        payee web page. It MUST be formatted according to the
-        "Unicode
-        Serialization of an Origin" algorithm defined in section 6.1 of
-        [[!RFC6454]].
-      

-      
methodData attribute

-      

-        This attribute contains PaymentMethodData
-        dictionaries containing the payment method identifiers for the
-        payment methods that the web site accepts and any associated
-        payment method specific data.
-        It is populated from the
-        PaymentRequest using the Method Data Population Algorithm
-        defined below.
-      

-      
total attribute

-      

-        This attribute indicates the total amount being requested for payment.
-        It is initialized with a structured clone of the
-        total field of the PaymentDetails provided
-        when the corresponding PaymentRequest object was instantiated.
-      

-      
displayItems

-      

-	The sequence of line items optionally provided by the payee. 
-        It is initialized with a structured clone of the
-        displayItems field of the PaymentDetails provided
-        when the corresponding PaymentRequest object was instantiated.
-      

-      
modifiers attribute

-      

-        This sequence of PaymentDetailsModifier dictionaries
-        contains modifiers for particular payment method identifiers (e.g.,
-        if the payment amount or currency type varies based on a
-        per-payment-method basis).  It is populated from the
-        PaymentRequest using the Modifiers Population Algorithm
-        defined below.
-      

-      
optionId attribute

-      

-        This attribute indicates the PaymentAppOption selected by
-        the user. It corresponds to the id field provided during
-	registration.
-      

-    

-
-    
See issue 91 for discussion about the inclusion of line items in the Payment App Request.

-    
-    

-      

-        Method Data Population Algorithm
-      

-      

-        To initialize the value of the methodData, the user agent
-        MUST perform the following steps or their equivalent:
-      

-      
    
-        
  1. 
-          Set registeredMethods to an empty set.
-        
    2. 
-        
  2. 
-          For each PaymentAppOption option in the
-          payment handler's PaymentAppManager.options, add all entries in
-          option.enabledMethods to
-          registeredMethods.
-        
    3. 
-        
  3. 
-          Create a new empty Sequence.
-        
    4. 
-        
  4. 
-          Set dataList to the newly created Sequence.
-        
    5. 
-        
  5. 
-          For each item in
-          PaymentRequest@[[\methodData]] in the
-          corresponding payment request, perform the following steps:
-          
      
-            
    1. 
-               Set inData to the item under consideration.
-            
      2. 
-            
    2. 
-              Set commonMethods to the set intersection of
-              inData.supportedMethods
-              and registeredMethods.
-            
      3. 
-            
    3. 
-              If commonMethods is empty, skip the remaining substeps
-              and move on to the next item (if any).
-            
      4. 
-            
    4. 
-              Create a new PaymentMethodData object.
-            
      5. 
-            
    5. 
-              Set outData to the newly created
-              PaymentMethodData.
-            
      6. 
-            
    6. 
-              Set outData.supportedMethods to
-              a list containing the members of commonMethods.
-            
      7. 
-            
    7. 
-              Set outData.data to a structured clone of
-              inData.data.
-            
      8. 
-            
    8. 
-              Append outData to dataList.
-            
      9. 
-          
    
-          
  6. 
-            Set methodData to dataList.
+      
    
+        
    origin attribute
    
+        
    
+          This attribute a string that indicates the origin
+          of the payee web page. It MUST be formatted
+          according to the "Unicode
+          Serialization of an Origin" algorithm defined in
+          section 6.1 of [[!RFC6454]].
+        
    
+        
    methodData attribute
    
+        
    
+          This attribute contains PaymentMethodData
+          dictionaries containing the payment method
+          identifiers for the payment methods that the
+          web site accepts and any associated payment method
+          specific data. It is populated from the
+          PaymentRequest using the Method Data Population
+          Algorithm defined below.
+        
    
+        
    total attribute
    
+        
    
+          This attribute indicates the total amount being requested
+          for payment. It is initialized with a structured
+          clone of the total field of the
+          PaymentDetails provided when the
+          corresponding PaymentRequest object was
+          instantiated.
+        
    
+        
    displayItems
    
+        
    
+          The sequence of line items optionally provided by the
+          payee. It is initialized with a structured clone
+          of the displayItems field of the
+          PaymentDetails provided when the
+          corresponding PaymentRequest object was
+          instantiated.
+        
    
+        
    modifiers attribute
    
+        
    
+          This sequence of PaymentDetailsModifier
+          dictionaries contains modifiers for particular payment
+          method identifiers (e.g., if the payment amount or
+          currency type varies based on a per-payment-method
+          basis). It is populated from the PaymentRequest
+          using the Modifiers Population Algorithm defined
+          below.
+        
    
+        
    optionId attribute
    
+        
    
+          This attribute indicates the PaymentAppOption
+          selected by the user. It corresponds to the
+          id field provided during registration.
+        
    
+      
    
+      
    See 
+      issue 91 for discussion about the inclusion of line items
+      in the Payment App Request.
    
+      
    
+        
    Method Data Population Algorithm
    
+        
    To initialize the value of the methodData,
+        the user agent MUST perform the following steps or their
+        equivalent:
    
+        
      
+          
    1. Set registeredMethods to an empty
+          set.
      2. 
+          
    2. For each PaymentAppOption option in
+          the payment handler's
+          PaymentAppManager.options, add all entries
+          in option.enabledMethods to 
+            registeredMethods.
           
      3. 
-      
    
-    
    
-    
    
-      
    
-        Modifiers Population Algorithm
-      
    
-      
    
-        To initialize the value of the modifiers, the user agent
-        MUST perform the following steps or their equivalent:
-      
    
-      
      
-        
    1. 
-          Set registeredMethods to an empty set.
-        
      2. 
-        
    2. 
-          For each PaymentAppOption option in the
-          payment handler's PaymentAppManager.options, add all
-          entries in option.enabledMethods to
-          registeredMethods.
-        
      3. 
-        
    3. 
-          Create a new empty Sequence.
-        
      4. 
-        
    4. 
-          Set modifierList to the newly created
-          Sequence.
-        
      5. 
-        
    5. 
-          For each item in
+          
    6. Create a new empty Sequence.
      7. 
+          
    7. Set dataList to the newly created
+          Sequence.
      8. 
+          
    8. For each item in
+          PaymentRequest@[[\methodData]] in
+          the corresponding payment request, perform the following
+          steps:
+            
        
+              
      1. Set inData to the item under
+              consideration.
        2. 
+              
      2. Set commonMethods to the set
+              intersection of
+              inData.supportedMethods and
+              registeredMethods.
        3. 
+              
      3. If commonMethods is empty, skip the
+              remaining substeps and move on to the next item (if
+              any).
        4. 
+              
      4. Create a new PaymentMethodData
+              object.
        5. 
+              
      5. Set outData to the newly created
+              PaymentMethodData.
        6. 
+              
      6. Set
+              outData.supportedMethods to a
+              list containing the members of
+              commonMethods.
        7. 
+              
      7. Set outData.data to a structured
+              clone of inData.data.
+              
        8. 
+              
      8. Append outData to
+              dataList.
        9. 
+            
      
+          
      9. 
+          
    9. Set methodData to
+          dataList.
      10. 
+        
    
+      
    
+      
    
+        
    Modifiers Population Algorithm
    
+        
    To initialize the value of the modifiers,
+        the user agent MUST perform the following steps or their
+        equivalent:
    
+        
      
+          
    1. Set registeredMethods to an empty
+          set.
      2. 
+          
    2. For each PaymentAppOption option in
+          the payment handler's
+          PaymentAppManager.options, add all entries
+          in option.enabledMethods to 
+            registeredMethods.
+          
      3. 
+          
    3. Create a new empty Sequence.
      4. 
+          
    4. Set modifierList to the newly created
+          Sequence.
      5. 
+          
    5. For each item in
           PaymentRequest@[[\paymentDetails]].modifiers
-          in the corresponding payment request, perform the following steps:
-          
        
-            
      1. 
-               Set inModifier to the item under consideration.
-            
        2. 
-            
      2. 
-              Set commonMethods to the set intersection of
+          in the corresponding payment request, perform the
+          following steps:
+            
          
+              
        1. Set inModifier to the item under
+              consideration.
          2. 
+              
        2. Set commonMethods to the set
+              intersection of
               inModifier.supportedMethods
-              and registeredMethods.
-            
          3. 
-            
        3. 
-              If commonMethods is empty, skip the remaining substeps
-              and move on to the next item (if any).
-            
          4. 
-            
        4. 
-              Create a new PaymentDetailsModifier object.
-            
          5. 
-            
        5. 
-              Set outModifier to the newly created
-              PaymentDetailsModifier.
-            
          6. 
-            
        6. 
-              Set outModifier.supportedMethods to
-              a list containing the members of commonMethods.
-            
          7. 
-            
        7. 
-              Set outModifier.total to a structured
-              clone of inModifier.total.
-            
          8. 
-            
        8. 
-              Set outModifier.additionalDisplayItems
+              and registeredMethods.
          9. 
+              
        9. If commonMethods is empty, skip the
+              remaining substeps and move on to the next item (if
+              any).
          10. 
+              
        10. Create a new PaymentDetailsModifier
+              object.
          11. 
+              
        11. Set outModifier to the newly created
+              PaymentDetailsModifier.
          12. 
+              
        12. Set
+              outModifier.supportedMethods
+              to a list containing the members of
+              commonMethods.
          13. 
+              
        13. Set outModifier.total to
+              a structured clone of
+              inModifier.total.
+              
          14. 
+              
        14. Set
+              outModifier.additionalDisplayItems
               to a structured clone of
               inModifier.additionalDisplayItems.
-            
          15. 
-            
        15. 
-              Append outModifier to modifierList.
-            
          16. 
-          
        
-          
      3. 
-            Set modifiers to modifierList.
+              
        4. 
+              
      4. Append outModifier to
+              modifierList.
        5. 
+            
      
           
      6. 
-      
    
+          
  7. Set modifiers to
+          modifierList.
    8. 
+        

+      

     

-  

-  

-    
Invocation

     

-    

-      Extension to ServiceWorkerGlobalScope
-    

-      

-        The Service Worker specification defines a
-        ServiceWorkerGlobalScope interface [[!SERVICE-WORKERS]],
-        which this specification extends.
-      

-      
+      
Invocation

+      

+        
Extension to ServiceWorkerGlobalScope

+        
The Service Worker specification defines a
+        ServiceWorkerGlobalScope interface
+        [[!SERVICE-WORKERS]], which this specification extends.

+        
         partial interface ServiceWorkerGlobalScope {
           attribute EventHandler onpaymentrequest;
         };
       

-      

-        
onpaymentrequest attribute

-        

-          The onpaymentrequest attribute is an event handler
-          whose corresponding event handler event type is
-          paymentrequest.
-        

-      

-
-      
The PaymentRequestEvent interface represents a received
-      payment request.
-    

-    

-    

-      The paymentrequest Event
-    

-      

-        The PaymentRequestEvent represents a received payment
-        request.
-      

-      
+        

+          
onpaymentrequest attribute

+          

+            The onpaymentrequest attribute is an
+            event handler whose corresponding event
+            handler event type is paymentrequest.
+          

+        

+        
The PaymentRequestEvent interface represents a
+        received payment request.

+      

+      

+        
The paymentrequest Event

+        
The PaymentRequestEvent represents a received
+        payment request.

+        
       [Exposed=ServiceWorker]
       interface PaymentRequestEvent : ExtendableEvent {
         readonly attribute PaymentAppRequest appRequest;
         void respondWith(Promise<PaymentAppResponse>appResponse);
       };
       

-      

-        
appRequest attribute

-        

-          This attribute contains the payment app request associated
-          with this payment request.
-        

-        
respondWith method

-        

-          This method is used by the payment handler to provide a
-          PaymentAppResponse when the payment successfully completes.
-        

-      

-        

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

+        

+          
appRequest attribute

+          

+            This attribute contains the payment app request
+            associated with this payment request.
+          

+          
respondWith method

+          

+            This method is used by the payment handler to provide a
+            PaymentAppResponse when the payment successfully
+            completes.
+          

+        

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

         
    
           
  1. Let registration be the service worker
           registration corresponding to the payment handler
           selected by the user.
           
    2. 
-          
  2. If registration is not found, reject the Promise that
-            was created by PaymentRequest.show() with a
-            DOMException whose value "InvalidStateError" and
-            terminate these steps.
+          
  3. If registration is not found, reject the
+          Promise that was created by
+          PaymentRequest.show() with a
+          DOMException whose value
+          "InvalidStateError" and terminate these steps.
           
    4. 
-          
  4. Invoke the Handle Functional Event algorithm with a
-          service worker registration of registration and
-          callbackSteps set to the following steps:
+          
  5. Invoke the Handle Functional Event algorithm
+          with a service worker registration of
+          registration and callbackSteps set
+          to the following steps:
             
      
-              
    1. Set global to the global object that was provided
-                  as an argument.  
      2. 
-              
    2. Create a trusted event,
-                  e, that uses the
-                  PaymentRequestEvent interface, with the
-                  event type paymentrequest, which does not bubble,
-                  cannot be canceled, and has no default action.  
      3. 
+              
    3. Set global to the global object that
+              was provided as an argument.
      4. 
+              
    4. Create a trusted event, e, that
+              uses the PaymentRequestEvent
+              interface, with the event type
+              paymentrequest, which does not bubble,
+              cannot be canceled, and has no default action.
+              
      5. 
               
    5. Set the appRequest attribute of
-                  e to a new PaymentAppRequest instance,
-                  populated as described in
-                  .
+              e to a new PaymentAppRequest
+              instance, populated as described in .
               
      6. 
               
    6. Dispatch e to global.
      7. 
-              
    7. Wait for all of the promises in the extend lifetime
-                  promises of e to resolve.
      8. 
-              
    8. If the payment handler has not provided a payment app
-                  response as described in , reject the Promise that
-                  was created by PaymentRequest.show() with a
-                  DOMException whose value "OperationError".
+              
    9. Wait for all of the promises in the extend
+              lifetime promises of e to resolve.
+              
      10. 
+              
    10. If the payment handler has not provided a
+              payment app response as described in
+                , reject
+                the Promise that was created by
+                PaymentRequest.show() with a
+                DOMException whose value
+                "OperationError".
+              
      11. 
             
    
           
    6. 
         

+      

     

-  

-  

-  

-    Payment Handler Windows
-  

-
-  
An invoked payment handler may or may not need to display information
-    about itself or request user input. Some examples of potential
-    payment handler displays include:

-
-  
    
-    
  • The payment handler opens a window for the user to provide an authorization code.
    • 
-    
  • The payment handler opens a window that makes it easy for the user to confirm payment using default information for that site provided through previous user configuration.
    • 
-    
  • When first selected to pay in a given session, the payment handler
-      opens a window. For subsequent payments in the same session, the payment handler (through configuration) performs its duties without opening a window or requiring user interaction.
    • 
-  

-
-  
See issue 97 for discussion about opening window in a way that is consistent with payment flow and not confusing to the user. For example, there is consensus that in a desktop environment, a payment handler should not open a window in a new browser tab, as this is too dissociated from the checkout context.

-  
-  
User agents SHOULD display the origin of a running payment handler to the user.

-
-  

-  

-    
Payment App Response

-
-    The payment app response is conveyed using the following
-    dictionary:
-    
+    

+      
Payment Handler Windows

+      
An invoked payment handler may or may not need to display
+      information about itself or request user input. Some examples
+      of potential payment handler displays include:

+      
    
+        
  • The payment handler opens a window for the user to
+        provide an authorization code.
    • 
+        
  • The payment handler opens a window that makes it easy
+        for the user to confirm payment using default information
+        for that site provided through previous user
+        configuration.
    • 
+        
  • When first selected to pay in a given session, the
+        payment handler opens a window. For subsequent payments in
+        the same session, the payment handler (through
+        configuration) performs its duties without opening a window
+        or requiring user interaction.
    • 
+      

+      
See 
+      issue 97 for discussion about opening window in a way
+      that is consistent with payment flow and not confusing to the
+      user. For example, there is consensus that in a desktop
+      environment, a payment handler should not open a
+      window in a new browser tab, as this is too dissociated from
+      the checkout context.

+      
User agents SHOULD display the origin of a running payment
+      handler to the user.

+    

+    

+      
Payment App Response
The payment app response
+      is conveyed using the following dictionary:
+      
       dictionary PaymentAppResponse {
         DOMString methodName;
         object details;
       };
     

-    
methodName attribute

-    

-      The payment method identifier for the payment method
-      that the user selected to fulfil the transaction.
-    

-    
details attribute

-    

-      A JSON-serializable object that provides a  payment
-      method specific message used by the merchant to process the
-      transaction and determine successful fund transfer.
-    

-    
-    

-      The user agent receives a successful response from the payment handler
-      through resolution of the Promise provided to the respondWith
-      function of the corresponding PaymentRequestEvent dictionary.
-      The application is expected to resolve the Promise with a
-      PaymentAppResponse instance containing the
-      payment response. In case of user cancellation or error, the
-      application may signal failure by rejecting the Promise.
-    

-    

-      If the Promise is rejected, the user agent MUST run the payment app
-      failure algorithm. The exact details of this algorithm is left for
-      user agent implementers to decide on. Acceptable behaviors include,
-      but are not limited to:
-    

-    
    
-      
  • 
-        Letting the user try again, with the same payment handler or with a
-        different one.
-      
    • 
-      
  • 
-        Rejecting the Promise that was created by
-        PaymentRequest.show().
-      
    • 
-    

-    

-      If this Promise is successfully resolved, the user agent MUST run the
-      user accepts the payment request algorithm as defined in
-      [[!PAYMENT-REQUEST-API]], replacing steps 6 and 7 with these steps or
-      their equivalent:
-    

-    
    
-      
  1. 
-        Set appResponse to the PaymentAppResponse
-        instance used to resolve the
-        PaymentRequestEvent.respondWith Promise.
-      
    2. 
-      
  2. 
-        If appResponse.methodName is not present or
-        not set to one of the values from
-        PaymentRequestEvent.appRequest, run the payment app
-        failure algorithm and terminate these steps.
-      
    3. 
-      
  3. 
-        Create a structured clone of
-        appResponse.methodName
-        and assign it to
-        response.methodName.
-      
    4. 
-      
  4. 
-        If appResponse.details is not present, run the
-        payment app failure algorithm and terminate these steps.
-      
    5. 
-      
  5. 
-        Create a structured clone of
-        appResponse.details
-        and assign it to
-        response.details.
-      
    6. 
-    

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

-    
+      

+        
methodName attribute

+        

+          The payment method identifier for the payment
+          method that the user selected to fulfil the
+          transaction.
+        

+        
details attribute

+        

+          A JSON-serializable object that provides a
+          payment method specific message used by the
+          merchant to process the transaction and determine
+          successful fund transfer.
+        

+        

+          
The user agent receives a successful response from the
+          payment handler through resolution of the Promise
+          provided to the respondWith function of the
+          corresponding PaymentRequestEvent dictionary. The
+          application is expected to resolve the Promise with a
+          PaymentAppResponse instance containing the
+          payment response. In case of user cancellation or error,
+          the application may signal failure by rejecting the
+          Promise.

+          
If the Promise is rejected, the user agent MUST run
+          the payment app failure algorithm. The exact
+          details of this algorithm is left for user agent
+          implementers to decide on. Acceptable behaviors include,
+          but are not limited to:

+          
    
+            
  • Letting the user try again, with the same payment
+            handler or with a different one.
    • 
+            
  • Rejecting the Promise that was created by
+            PaymentRequest.show().
    • 
+          

+          
If this Promise is successfully resolved, the user
+          agent MUST run the user accepts the payment request
+          algorithm as defined in [[!PAYMENT-REQUEST-API]],
+          replacing steps 6 and 7 with these steps or their
+          equivalent:

+          
    
+            
  1. Set appResponse to the
+            PaymentAppResponse instance used to
+            resolve the
+            PaymentRequestEvent.respondWith
+            Promise.
+            
    2. 
+            
  2. If appResponse.methodName
+            is not present or not set to one of the values from 
+              PaymentRequestEvent.appRequest, run
+              the payment app failure algorithm and
+              terminate these steps.
+            
    3. 
+            
  3. Create a structured clone of
+            appResponse.methodName and
+            assign it to
+            response.methodName.
+            
    4. 
+            
  4. If appResponse.details is
+            not present, run the payment app failure
+            algorithm and terminate these steps.
+            
    5. 
+            
  5. Create a structured clone of
+            appResponse.details and assign
+            it to response.details.
+            
    6. 
+          

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

+          
       paymentRequestEvent.respondWith(new Promise(function(accept,reject) {
         /* ... processing may occur here ... */
         accept({
@@ -1068,26 +1031,30 @@ 
Payment App Response

         });
       });
     

-
-    

-      [[!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 of handling the paymentrequest event

-    

-      This example shows how to write a service worker that listens to the
-      paymentrequest event. When a payment request event is received, the
-      service worker opens a window in order to interact with the user.
-    

-
-
Per issue 97, we expect not to use clients.OpenWindow and instead await a proposal for a new openClientWindow method. We will need to update these examples.

-
-    
-    
+          
[[!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 of handling the paymentrequest
+      event

+      
This example shows how to write a service worker that
+      listens to the paymentrequest event. When a payment request
+      event is received, the service worker opens a window in order
+      to interact with the user.

+      
Per 
+      issue 97, we expect not to use
+      clients.OpenWindow and instead await a proposal for a new
+      openClientWindow method. We will need to update these
+      examples.

+      
       self.addEventListener('paymentrequest', function(e) {
         e.respondWith(new Promise(function(resolve, reject) {
           self.addEventListener('message', listener = function(e) {
@@ -1109,10 +1076,12 @@ 
Example of handling the paymentrequest event

         }));
       });
     

-    
Using the simple scheme described above, a trivial HTML page that is
-    loaded into the payment handler window to implement the basic
-    card scheme might look like the following:

-    
+      
Using the simple scheme described above, a trivial HTML
+      page that is loaded into the payment handler window to
+      implement the basic card scheme might look like the
+      following:

+      
 <html> <body> <form id="form">
 <table>
   <tr><th>Cardholder Name:</th><td><input name="cardholderName"></td></tr>
@@ -1148,50 +1117,70 @@ 
Example of handling the paymentrequest event

 });
 </script> </body> </html>
     

-
-  

-
-

-
-

-  
Security and Privacy Considerations

-  

-    
Information about the User Environment

-    
    
-      
  • The API does not share information about the user's registered payment handlers. Information from origins is only shared with the payee with the consent of the user.
    • 
-      
  • Similarly, user agents should not share payment request information with any payment handler until the user has selected that payment handler.
    • 
-    

-  

-  

-    
User Consent before Payment

-    
    
-      
  • One goal of this specification is to minimize the user interaction required to make a payment. At the same time, user agents must not permit combinations of configurations that would enable invoking Web sites to invoke payment request and receive payments silently.
    • 
-    

-  

-  

-    
Secure Communications

-    
    
-      
  • See Service Worker security considerations
    • 
-      
  • Payment method security is outside the scope of this specification and is addressed by payment handlers that support those payment methods.
    • 
-    

-  

-  

-    
Payment App Authenticity

-    
The Web Payments Working Group is also discussing
-      Payment App authenticity; see the (draft) Payment Method Manifest.

-  

-  

-    
Data Validation

-    
    
-      
  • Payees should validate that the data they have received through the paymentRequest API is what they expect (e.g., the total that was paid, etc.).
    • 
-    

+    

   

-  

-    
Private Browsing Mode

-    
    
-      
  • When the Payment Request API is invoked in a "private browsing mode," the user agent should launch payment handlers 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 origin or re-enter payment instrument details.
    • 
-    

+  

+    
Security and Privacy Considerations

+    

+      
Information about the User Environment

+      
    
+        
  • The API does not share information about the user's
+        registered payment handlers. Information from origins is
+        only shared with the payee with the consent of the
+        user.
    • 
+        
  • Similarly, user agents should not share payment request
+        information with any payment handler until the user has
+        selected that payment handler.
    • 
+      

+    

+    

+      
User Consent before Payment

+      
    
+        
  • One goal of this specification is to minimize the user
+        interaction required to make a payment. At the same time,
+        user agents must not permit combinations of configurations
+        that would enable invoking Web sites to invoke payment
+        request and receive payments silently.
    • 
+      

+    

+    

+      
Secure Communications

+      
+    

+    

+      
Payment App Authenticity

+      
The Web Payments Working Group is also
+      discussing Payment App authenticity; see the (draft) 
+      Payment Method Manifest.

+    

+    

+      
Data Validation

+      
    
+        
  • Payees should validate that the data they have received
+        through the paymentRequest API is what they expect (e.g.,
+        the total that was paid, etc.).
    • 
+      

+    

+    

+      
Private Browsing Mode

+      
    
+        
  • When the Payment Request API is invoked in a "private
+        browsing mode," the user agent should launch payment
+        handlers 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 origin or re-enter payment instrument details.
    • 
+      

+    

   

-