From f17221097d5b71d07091af0d6665c6d924616ba8 Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Fri, 5 Aug 2016 12:22:40 -0500 Subject: [PATCH 1/7] Addition of new design considerations Taken from https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#design-consider ations --- index.html | 67 ++++++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 60 insertions(+), 7 deletions(-) diff --git a/index.html b/index.html index bcdd74d..e4271dc 100644 --- a/index.html +++ b/index.html @@ -258,7 +258,7 @@

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 (which maypaym be temporary) intends to help build shared understanding of the capabilities and limitations of the specified model.

General Considerations

    @@ -268,19 +268,66 @@

    General Considerations

    (e.g., for payment app registration or invocation).
+
+

Decoupling and Trust

+
    +
  • A goal of this system is to decouple the payment methods used to pay from the software (payment apps) that implement those payment methods. By decoupling, merchants (and their payment service providers) can lower the cost of creating a checkout experience, users can have more choice in the software they use to pay, and payment app providers can innovate without imposing an integration burden on merchants.
    • +
  • Users may choose to use "open" or "proprietary" payment methods, so the payment app ecosystem must support both. Users must be able to register payment apps of their choosing. We expect the user to have greater choice of third party payment apps for open payment methods than for proprietary payment methods. Examples of open payment methods include card payment and SEPA credit transfer.
    • +
  • For privacy, the design should limit information about the user's environment available to merchant without user consent. That includes which payment apps the user has registered. For open payment methods, the merchant should not receive information about which payment app the user selected to pay unless the user consents to share that information.
    • +
  • Although decoupling relieves merchants of implementing some aspects of the checkout experience, one consequence is that they give up some degree of control. This was already the case for proprietary payment methods, but for open payment methods such as cards, merchants (or their PSPs) will be entrusting some portion of data collection to third party payment apps, without knowing which app the user will select.
    • +
  • We recognize, therefore, a tension between user preferences (e.g., registered payment apps, ordering of display of payment apps, etc.) and merchant preferences (e.g., control of the user experience previously implemented in a Web page, ordering of payment apps, presence of merchant's own payment app, etc.).
    • +
  • The design should address this tension by enabling the merchant to express preferences for both payment methods and payment apps. The design should not constrain how browsers make us of these preferences, only provide guidance to browser vendors about taking into account both merchant and user preferences.
    • +
  • Here are preferences the system might support: +
      +
    • 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)
      • +
    • Recommended payment apps (payment apps the merchant prefers, but others may be used)
      • +
    • Accepted payment apps (payment apps the merchant accepts, and no others may be used). Note that this is the status quo since merchants either accept card information through UI that they control, or they redirect users to payment service providers with whom they have existing relationships. Note that if we allow merchants to restrict payment apps that might end up requiring the customer to install multiple payment apps for the same payment method, which would complicate the user experience for the same payment method.
      • +
    +
    • +
  • The browser uses this information in conjunction with user preferences to: +
  • Filter matching payment apps (in the case of accepted payment apps)
    • +
  • Display matching payment apps (according to merchant preferred payment method order)
    • +
  • Display recommended payment apps (according to merchant recommended payment app order)
    • +
+ + +

Registration and Unregistration

    -
  • 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.
    • +
  • + We expect registrations will happen at various times (e.g., outside and inside of checkout): 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.
      • +
    • When the browser recommends a payment app and the user selects it, registration can happen in that moment without additional user action. (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.
      • +
    • Users visiting a Web site (e.g., merchant or bank) may wish to explicitly register payment apps.
      • +
    +
    • +
  • + At the same time, the system should not modify the user's environment or share user data without the user's consent. Consent may be provided in a number of ways that can be streamlined (e.g., registration of a native payment app can happen when the native app is installed; when only one payment app matches merchant-accepted data, the browser can launch the app directly instead of requiring additional user selection; etc.) +
  • 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. We expect payment apps to update the information that a user agent has stored about them + registration information. In this proposal, payment apps to update the information that a user agent has stored about them by re-calling the registration API.
+
+

Payment App Identification

+
    +
  • For both "recommended" and "accepted" payment apps, we will need payment app identifiers (PAIs).
    • +
  • A PAI should include origin information. This origin information may be used in a variety of ways: +
      +
    • The origin information could enable browsers to provide the user with useful services when the user is browsing a site with the same origin (e.g., putting that payment app at the top of a list or otherwise highlighted).
      • +
    • For a "proprietary" payment method with an associated origin, the browser can do some (security) checks by comparing the origin of the payment method and the payment app.
      • +
    +
  • +
  • A PAI should allow for granularity (e.g., payment app versioning); we should consider URLs.
    • +
+

Payment App Matching

    @@ -315,13 +362,19 @@

    Payment App Invocation and Response

    authorized payment. The response becomes the response of the Payment Request API.
+
+

User Experience

+
    +
  • The system should minimize user interaction for payment app registration, payment app selection, and payment credentials selection.
    • +
+

Network Considerations

  • This specification only describes communication between the user agent and the payment app. This includes an asynchronous mechanism for a payment app to return a payment response to the user agent. This specification - does not address scenarios where the user agent does not receive the response (e.g., due to a crash our - network outage).
    • + does not (yet) address scenarios where the user agent does not receive the response (e.g., due to a crash our + network outage). Question: Should we recommend asynchronous communication between payment app and servers it talks to?
  • This specification does not address communication between the payee server and the payee Web app, or between the payment app and other parties (e.g., the payment app distibutor, or directly to the merchant).
From 1d44da093e48f2ebc1607ec7cbfec4c04fe41511 Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Mon, 8 Aug 2016 13:02:30 -0500 Subject: [PATCH 2/7] Small changes based on Shane and AHB feedback * Fixed link to issues list * Added two links to issue 224 (about push payments). Did this rather than create a new issue about async communications. * Two typos fixed --- index.html | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/index.html b/index.html index e4271dc..401e6e3 100644 --- a/index.html +++ b/index.html @@ -92,8 +92,7 @@ underlying Payment Request API.

-

The Web Payments Working Group maintains +

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 @@ -258,7 +257,7 @@

Dependencies

Payment App Model and Design Considerations

-

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

+

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

General Considerations

    @@ -273,7 +272,7 @@

    Decoupling and Trust

    • A goal of this system is to decouple the payment methods used to pay from the software (payment apps) that implement those payment methods. By decoupling, merchants (and their payment service providers) can lower the cost of creating a checkout experience, users can have more choice in the software they use to pay, and payment app providers can innovate without imposing an integration burden on merchants.
    • Users may choose to use "open" or "proprietary" payment methods, so the payment app ecosystem must support both. Users must be able to register payment apps of their choosing. We expect the user to have greater choice of third party payment apps for open payment methods than for proprietary payment methods. Examples of open payment methods include card payment and SEPA credit transfer.
      • -
    • For privacy, the design should limit information about the user's environment available to merchant without user consent. That includes which payment apps the user has registered. For open payment methods, the merchant should not receive information about which payment app the user selected to pay unless the user consents to share that information.
      • +
    • For privacy, the design should limit information about the user's environment available to merchant without user consent. That includes which payment apps the user has registered. For open payment methods, the merchant should not receive information about which payment app the user selected to pay unless the user consents to share that information. See issue 224 for discussion about how merchant may track progress of a push payment.
    • Although decoupling relieves merchants of implementing some aspects of the checkout experience, one consequence is that they give up some degree of control. This was already the case for proprietary payment methods, but for open payment methods such as cards, merchants (or their PSPs) will be entrusting some portion of data collection to third party payment apps, without knowing which app the user will select.
    • We recognize, therefore, a tension between user preferences (e.g., registered payment apps, ordering of display of payment apps, etc.) and merchant preferences (e.g., control of the user experience previously implemented in a Web page, ordering of payment apps, presence of merchant's own payment app, etc.).
    • The design should address this tension by enabling the merchant to express preferences for both payment methods and payment apps. The design should not constrain how browsers make us of these preferences, only provide guidance to browser vendors about taking into account both merchant and user preferences.
      • @@ -373,8 +372,8 @@

      Network Considerations

      • This specification only describes communication between the user agent and the payment app. This includes an asynchronous mechanism for a payment app to return a payment response to the user agent. This specification - does not (yet) address scenarios where the user agent does not receive the response (e.g., due to a crash our - network outage). Question: Should we recommend asynchronous communication between payment app and servers it talks to?
        • + does not (yet) address scenarios where the user agent does not receive the response (e.g., due to a crash or + network outage). Question: Should we recommend asynchronous communication between payment app and servers it talks to? See issue 224.
      • This specification does not address communication between the payee server and the payee Web app, or between the payment app and other parties (e.g., the payment app distibutor, or directly to the merchant).
      From aff65602670af089e2cbdd26faa155e5580644fb Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Mon, 8 Aug 2016 13:08:22 -0500 Subject: [PATCH 3/7] Small fixes based on AHB comments --- index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index 401e6e3..e8541a5 100644 --- a/index.html +++ b/index.html @@ -286,7 +286,7 @@

      Decoupling and Trust

    • The browser uses this information in conjunction with user preferences to:
    • Filter matching payment apps (in the case of accepted payment apps)
      • -
    • Display matching payment apps (according to merchant preferred payment method order)
      • +
    • Display matching payment apps (according to matching payment methods, according to merchant accepted payment method order)
    • Display recommended payment apps (according to merchant recommended payment app order)
    @@ -301,7 +301,7 @@

    Registration and Unregistration

  • When the merchant recommends a payment app and the user selects it, registration can happen in that moment without additional user action.
  • When the browser recommends a payment app and the user selects it, registration can happen in that moment without additional user action. (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.
    • -
  • Users visiting a Web site (e.g., merchant or bank) may wish to explicitly register payment apps.
    • +
  • Users visiting a Web site (e.g., merchant or bank) may wish to explicitly register a payment app outside of the context of checkout.
  • @@ -310,7 +310,7 @@

    Registration and Unregistration

  • 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 to update the information that a user agent has stored about them + registration information. In this proposal, payment apps update the information that a user agent has stored about them by re-calling the registration API.
    • From 36802cb7c88b3b1f8d07b3ff819747021440a05b Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Mon, 8 Aug 2016 15:32:25 -0500 Subject: [PATCH 4/7] More cleanup and harmonization MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * General editing * Added definition of accepted payment app * Deleted sentence about HTTP -based mechanism since we are moving to JS (but didn’t update the spec part itself). * Added more ideas about optimized user experience * Added payment_app_id alongside request_url. Thus, request_url does not have to serve two purposes: one can identify the app one way (for installation, filtering, etc.) and use another URL to identify an endpoint for processing. Furthermore, we may be moving away from that processing model so the request_url is at risk (I think). * Moved some network failure design considerations to earlier in the document --- index.html | 106 +++++++++++++++++++++++++---------------------------- 1 file changed, 50 insertions(+), 56 deletions(-) diff --git a/index.html b/index.html index e8541a5..9672b20 100644 --- a/index.html +++ b/index.html @@ -275,18 +275,19 @@

    Decoupling and Trust

  • For privacy, the design should limit information about the user's environment available to merchant without user consent. That includes which payment apps the user has registered. For open payment methods, the merchant should not receive information about which payment app the user selected to pay unless the user consents to share that information. See issue 224 for discussion about how merchant may track progress of a push payment.
  • Although decoupling relieves merchants of implementing some aspects of the checkout experience, one consequence is that they give up some degree of control. This was already the case for proprietary payment methods, but for open payment methods such as cards, merchants (or their PSPs) will be entrusting some portion of data collection to third party payment apps, without knowing which app the user will select.
  • We recognize, therefore, a tension between user preferences (e.g., registered payment apps, ordering of display of payment apps, etc.) and merchant preferences (e.g., control of the user experience previously implemented in a Web page, ordering of payment apps, presence of merchant's own payment app, etc.).
    • -
  • The design should address this tension by enabling the merchant to express preferences for both payment methods and payment apps. The design should not constrain how browsers make us of these preferences, only provide guidance to browser vendors about taking into account both merchant and user preferences.
    • +
  • The design should address this tension by enabling the merchant to express preferences for both payment methods and payment apps. The design should not constrain how browsers make use of these preferences, only provide guidance to browser vendors about taking into account both merchant and user preferences.
  • Here are preferences the system might support:
    • 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)
    • Recommended payment apps (payment apps the merchant prefers, but others may be used)
      • -
    • Accepted payment apps (payment apps the merchant accepts, and no others may be used). Note that this is the status quo since merchants either accept card information through UI that they control, or they redirect users to payment service providers with whom they have existing relationships. Note that if we allow merchants to restrict payment apps that might end up requiring the customer to install multiple payment apps for the same payment method, which would complicate the user experience for the same payment method.
      • +
    • Accepted payment apps (payment apps the merchant accepts, and no others may be used). Note that this is the status quo since merchants either accept card information through UI that they control, or they redirect users to payment service providers with whom they have existing relationships. Note that if we allow merchants to restrict payment apps that might end up requiring the customer to register multiple payment apps for the same payment method, which would complicate the user experience for the same payment method.
  • The browser uses this information in conjunction with user preferences to: +
    • Filter matching payment apps (in the case of accepted payment apps)
      • -
    • Display matching payment apps (according to matching payment methods, according to merchant accepted payment method order)
      • +
    • Display matching payment apps (according to matching payment methods, expressed as merchant preferred order)
    • Display recommended payment apps (according to merchant recommended payment app order)
    • @@ -301,7 +302,7 @@

    Registration and Unregistration

  • When the merchant recommends a payment app and the user selects it, registration can happen in that moment without additional user action.
  • When the browser recommends a payment app and the user selects it, registration can happen in that moment without additional user action. (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.
    • -
  • Users visiting a Web site (e.g., merchant or bank) may wish to explicitly register a payment app outside of the context of checkout.
    • +
  • Users visiting a Web site (e.g., merchant or bank) may be invited to register a payment app outside of the context of checkout.
  • @@ -323,14 +324,13 @@

    Payment App Identification

  • 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).
  • For a "proprietary" payment method with an associated origin, the browser can do some (security) checks by comparing the origin of the payment method and the payment app.
    • -
  • A PAI should allow for granularity (e.g., payment app versioning); we should consider URLs.

    • Payment App Matching

      -
    • When the user invokes the Payment Request API (by, for example, "pushing the Buy button"), the user agent +
    • 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 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 @@ -342,8 +342,19 @@

      Payment App Matching

      relevant for a transaction but that the user has not yet registered or enabled.

      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. If the user selected a recommended payment app, behavior - depends on whether the payment app is unregistered or registered.
      • +
    • The user selects a payment option to make a payment. The user may also select a recommended payment app.
      • +
    +
    +
    +

    User Experience

    +
      +
    • The system should minimize user interaction for payment app registration, payment app selection, and payment credentials selection. Ideas include: +
        +
      • When only one payment app matches, the browser does not require user selection to launch it.
        • +
      • The browser displays payment options for direct selection by the user, avoiding the need for the user to make a second selection within the payment app context. The payment app provides the browser with sufficient information to display payment options. It is still possible to launch the payment app upon selection of a payment option, and in some cases the payment app may return a response without further user interaction, depending on the nature of the payment method.
        • +
      +
      • +
    • It is likely that this specification will include guidance rather than requirements about specific user experience optimizations.
    @@ -351,9 +362,6 @@

    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.
      • -
    • This specification defines an HTTP-based mechanism for providing input data to the payment app. In some - systems, payment apps may bypass this mechanism entirely, but that behavior lies outside the scope of this - specification.
    • 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.
      • @@ -361,19 +369,19 @@

      Payment App Invocation and Response

      authorized payment. The response becomes the response of the Payment Request API.
    -
    -

    User Experience

    -
      -
    • The system should minimize user interaction for payment app registration, payment app selection, and payment credentials selection.
      • -
    -

    Network Considerations

      -
    • This specification only describes communication between the user agent and the payment app. This includes an - asynchronous mechanism for a payment app to return a payment response to the user agent. This specification - does not (yet) address scenarios where the user agent does not receive the response (e.g., due to a crash or - network outage). Question: Should we recommend asynchronous communication between payment app and servers it talks to? See issue 224.
      • +
    • This specification only describes communication between the + user agent and the payment app. This includes an + asynchronous mechanism for a payment app to return a payment + response to the user agent. This specification does not + (yet) address scenarios where the user agent does not + receive the response (e.g., due to a crash or network + outage). Network failure may be especially problematic in the + case of a push payment; see issue 224, and so the Working Group is considering whether the specification should include a standard way to learn how to query a component for payment state information. For example, many systems use backchannel communications, so one idea is for the payee to provide a callback URL. This would allow (but not require) the payment app to communicate with the payee server until such time as all parties are satisfied they share the same view of the payment response. An alternative would be to provide the payment app and the user agent a channel so that communication continues until all aprties are satisfied they share the same view of the payment response. This might involve caching payment responses.
      • +
    +
  • This specification does not address communication between the payee server and the payee Web app, or between the payment app and other parties (e.g., the payment app distibutor, or directly to the merchant).
    • @@ -432,7 +440,12 @@

    Payment App Selection States

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

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

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

    +
    displayed payment app
    A matching payment app or recommended payment app with at least one selectable payment option (i.e. presented by the browser for user selection).
    @@ -509,11 +522,15 @@

    Payment App Registration, Updates and Unregistration

    Payment apps are registered with the user agent through a call to the register() method of the API. The input to the registration process consists of:

      -
    1. a request_url which uniquely identifies the app and is - the endpoint for the user agent to submit payment requests
      2. +
    2. a payment_app_id, a URL that identifies the app.
      3. +
    3. a request_url which identifies the + endpoint where the user agent submits payment requests.
    4. a sequence of PaymentOption dictionaries to provide information displayed to the user to facilitate payment app selection.
    + + +

    The PaymentOption dictionary

    @@ -544,22 +561,23 @@ 
    The PaymentOption dictionary
    
     
    
         
    PaymentApp.register()
    
         
    
-            The register method may be called if the web page wishes to register a
-            payment app with the user agent, update the registered information about an already registered
-            payment app or unregister a payment app.
+            The register method is used to register, update, or unregister a payment app with a user agent.
         
    
         
    
-            Payment apps are uniquely identifed by their request_url. To update the payment options
+            Payment apps are uniquely identifed by their payment_app_id. To update the payment options
             offered by a registered payment app, a website calls register() using the same
-            request_url as was used when registering the app and pass in the new sequence of options. To
+            payment_app_id as was used when registering the app and pass in the new sequence of options. To
             unregister a payment app the website calls register() with an empty sequence of options.
         
    
 
     partial interface PaymentApp {
-    static Promise<void> register (URLString request_url, sequence<PaymentOption> payment_options);
+    static Promise<void> register (URLString payment_app_id, URLString request_url, sequence<PaymentOption> payment_options);
 };
 
    
         
    
+            
    payment_app_id parameter
    
+            
    An identifier for the payment app. If a payment app is already installed with the same request_url
+                    the registered payment options will be replaced with the new sequence of options provided.
    
             
    request_url parameter
    
             
    
                 
    
@@ -573,11 +591,6 @@ 
    PaymentApp.register()
    
                     to register the payment app.
                 
    
 		
    Native apps could be registered from Web pages, thus allowing the association of an origin to a native app.
    
-                
    
-                    The request_url is also the unique identifier for the payment app.
-                    If a payment app is already installed with the same request_url
-                    the registered payment options will be replaced with the new sequence of options provided.
-                
    
             
    
             
    payment_options parameter
    
             
    
@@ -642,17 +655,13 @@ 
    PaymentApp.register()
    
                });
    -

    - We need to confirm the registration approach we wish to take. HTTP or JavaScript? What is the role of service - workers? -

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

    Payment App Matching

    -
    +

    We anticipate that the Payment Method Identifier specification will define the PMI matching algorithm. This specification will explain how to invoke that algorithm using data available from the Payment Request API input @@ -834,22 +843,7 @@

    Payment App Invocation

    that is set in the response.

    -

    Communication mail fail at various points in the flow, including between server and payment app:

    -
      -
    • Payment server to payment app
      • -
    • Payment app to user agent
      • -
    • Payee Web app to payee server
      • -
    -

    - What sort of guarantees should we endeavor to provide, if any, for any of these points in the flow? If, for examle, a proof of payment is lost - along the communication flow, then, for instance, a merchant might not shiop goods. Some observations: -

    -
      -
    • Today, backchannel communications are often used (e.g., between payment server and payee server).
      • -
    • The payee could provide a callback URL (identified as such in a standard way). This would allow (but not require) the payment app to communicate with the payee server until such time as all parties are satisfied they share the same view of the payment response.
      • -
    • An alternative is to ensure that the payment app and the user agent have a channel so that communication continues until all aprties are satisfied they share the same view of the payment response. This might involve caching payment responses.
      • -
    • What happens in Payment Request API if the user agent closes before the promise resolves?
      • -
    +

    Communication mail fail at various points in the flow; see design considerations for some ideas for managing this.

    From 19e474f5c528e3cddfc8485a62e5d60d112675cf Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Mon, 8 Aug 2016 15:57:33 -0500 Subject: [PATCH 5/7] Cleanup language about filtering per AHB --- index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index 9672b20..70beece 100644 --- a/index.html +++ b/index.html @@ -286,8 +286,8 @@

    Decoupling and Trust

  • The browser uses this information in conjunction with user preferences to:
      -
    • Filter matching payment apps (in the case of accepted payment apps)
      • -
    • Display matching payment apps (according to matching payment methods, expressed as merchant preferred order)
      • +
    • Filter payment apps (to matching payment methods and accepted payment apps)
      • +
    • Order payment apps (according to merchant specified order)
    • Display recommended payment apps (according to merchant recommended payment app order)
    • From 32df56067853b0482b492f92ef9857cf7fe37b06 Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Tue, 9 Aug 2016 12:02:10 -0500 Subject: [PATCH 6/7] Add pointer to issue 20; add IJ as editor --- index.html | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/index.html b/index.html index 70beece..8ae59ce 100644 --- a/index.html +++ b/index.html @@ -31,6 +31,11 @@ company: "Shopify", companyURL: "https://shopify.com" }, + { name: "Ian Jacobs", + url: "http://www.w3.org/People/Jacobs/", + company: "W3C", + companyURL: "https://www.w3.org/" + }, ], useExperimentalStyles: true, @@ -529,8 +534,10 @@

    Payment App Registration, Updates and Unregistration

    dictionaries to provide information displayed to the user to facilitate payment app selection. +

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

    -

    The PaymentOption dictionary

    
From 4eb8828c4e1cc9544a138be5667d5eeb0ce1c858 Mon Sep 17 00:00:00 2001
From: Ian Jacobs 
Date: Tue, 9 Aug 2016 12:03:22 -0500
Subject: [PATCH 7/7] Add pointer to issue 1

---
 index.html | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 8ae59ce..0b39653 100644
--- a/index.html
+++ b/index.html
@@ -286,7 +286,11 @@ 
    Decoupling and Trust
    
 
  •         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)
    • 
 
  •         Recommended payment apps (payment apps the merchant prefers, but others may be used)
    • 
-
  •         Accepted payment apps (payment apps the merchant accepts, and no others may be used). Note that this is the status quo since merchants either accept card information through UI that they control, or they redirect users to payment service providers with whom they have existing relationships. Note that if we allow merchants to restrict payment apps that might end up requiring the customer to register multiple payment apps for the same payment method, which would complicate the user experience for the same payment method.
    • 
+
  •         Accepted payment apps (payment apps the merchant accepts, and no others may be used). Note that this is the status quo since merchants either accept card information through UI that they control, or they redirect users to payment service providers with whom they have existing relationships. Note that if we allow merchants to restrict payment apps that might end up requiring the customer to register multiple payment apps for the same payment method, which would complicate the user experience for the same payment method.
+    
    
+    See issue 1 about whether we should including filtering on accepted payment apps.
+  
    
+
    • 
   
 
 
  •  The browser uses this information in conjunction with user preferences to: