From 8d58055f551c80183d94450e5e6dbfbdd99472f2 Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Wed, 16 Nov 2016 13:18:02 -0600 Subject: [PATCH 1/8] Edited specification to remove notions of open/proprietary Issue 67 was about lack of definitions of proprietary and open; https://github.com/w3c/webpayments-payment-apps-api/issues/67 Those terms were not necessary for the specification, so it was edited to remove the concepts. --- index.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/index.html b/index.html index 49c3120..d5d9c11 100644 --- a/index.html +++ b/index.html @@ -324,9 +324,9 @@

General Considerations

Decoupling and Trust

From b852c8a5d6ad63e7799f8e305d57770a4f7b7105 Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Wed, 16 Nov 2016 13:21:47 -0600 Subject: [PATCH 2/8] Issue 59 edit: UA should support config to not display recommended payment apps --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index d5d9c11..7c4f245 100644 --- a/index.html +++ b/index.html @@ -1048,7 +1048,7 @@

Selectable App Information Display

For the display of recommended payment apps:

From 9dbafcf49dd8ffdcfb9c8ef4f6aa6ea06148af61 Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Wed, 16 Nov 2016 13:32:08 -0600 Subject: [PATCH 3/8] Add a note about whether displayItems is missing and also about top-level transaction ID --- index.html | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/index.html b/index.html index 7c4f245..49901c8 100644 --- a/index.html +++ b/index.html @@ -1135,6 +1135,10 @@

Payment App Request Data

total field of the PaymentDetails provided when the corresponding PaymentRequest object was instantiated. +
Is the specification missing the top level "displayItems"? +
+
Keep an eye on issue 287. If the user agent generates a transaction ID, that ID must be passed to the payment app. If the merchant provides the transaction ID, that ID is already available through methodData. +
modifiers attribute
This sequence of PaymentDetailsModifier dictionaries From 50d5bb25534b78b6a69544b49797ab85d2133461 Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Wed, 16 Nov 2016 22:27:03 -0600 Subject: [PATCH 4/8] Editorial changes based on AHB comments --- index.html | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/index.html b/index.html index 49901c8..dda84f9 100644 --- a/index.html +++ b/index.html @@ -324,9 +324,9 @@

General Considerations

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.
    • -
  • User choice of payment apps that support a given payment method will depend on the payment method. For example, there may only be one app authorized to support a payment method owned by a company, while there may be many apps that support basic credit card payments or credit transfers.
    • +
  • User choice of payment apps that support a given payment method will depend in part on the willingness of the payment method owner to license implementations (e.g., via a manifest other mechanism). For example, there may only be one app authorized to support a payment method owned by a company, while there may be many apps that support basic credit card payments or credit transfers.
  • 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. The merchant should not receive information about which payment app the user selected to pay unless the user consents to share that information; of course when there is only one payment app for a given payment method that information is already publicly known. 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 some payment methods, but for traditional card payments, merchants (or their PSPs) will be entrusting some portion of data collection to third party payment apps.
    • +
  • 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 some payment methods, but for traditional card payments, merchants (or their PSPs) will be entrusting some portion of data collection to the browser or third party payment apps.
  • The design therefore includes support for merchants to recommend payment apps and suggest the ordering of payment methods. The design should endeavor not to constrain how user agents make use of this information, only provide guidance to user agent makers about taking into account both merchant and user preferences.
  • Here are preferences the system might support:
      @@ -397,7 +397,7 @@

      Payment App Identification

    • A PAI should include origin information. This origin information may be used in a variety of ways:
      • The origin information could enable user agents 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 payment method with an associated origin, the user agent can do some (security) checks by comparing the origin of the payment method and the payment app.
        • +
      • For a payment method with an associated origin, the user agent can do some (security) checks by comparing the origin of the payment method and any authorized payment app.
    • A PAI should allow for granularity (e.g., payment app versioning) in the form of constrained URLs. Note: The Working Group is discussing a constrained syntax for payment method identifiers (e.g., origin, case-sensitive path, no trailing slash) and we should consider aligning with that preference.
    @@ -1048,7 +1048,7 @@

    Selectable App Information Display

    For the display of recommended payment apps:

      -
    • The user agent SHOULD display recommended payment apps and configuration to not display recommended payment apps.
      • +
    • The user agent SHOULD display recommended payment apps and allow configuration to not display recommended payment apps.
    • The user agent MUST distinguish recommended payment apps from registered payment apps.
    • The user agent SHOULD display any merchant-recommended apps in the order specified by the payee.
    From 7553f82cd9c45fe38e04f08efc2aaf9c79ad4f1f Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Wed, 23 Nov 2016 09:00:10 -0600 Subject: [PATCH 5/8] Add link to two issues -issue 224 re push payments -issue 37 re cancelation (and discussion of UA retry) --- index.html | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index dda84f9..72ad059 100644 --- a/index.html +++ b/index.html @@ -1520,6 +1520,9 @@

    Payment App Response

    PaymentRequest.show().

    +

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

    +

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

           paymentRequestEvent.respondWith(new Promise(function(accept,reject) {
@@ -1538,8 +1541,7 @@ 
    Payment App Response
    
      
    
        Some payment methods might require a back channel to guarantee payment
-       response delivery (especially push payment methods).  Should it be part
-       of the generic portion of paymentRequest and paymentResponse? [Ed Note:
+       response delivery (especially push payment methods). See issue 224. [Ed Note:
        the "complete()" attribute of the "PaymentResponse" interface would serve
        this purpose quite cleanly.]
      
    

From 2802cb0b716dcb2dde29d95bdf5c4f14f15dc08e Mon Sep 17 00:00:00 2001
From: Ian Jacobs 
Date: Thu, 1 Dec 2016 13:42:30 -0600
Subject: [PATCH 6/8] Update manifest data for consistent with Web App Manifest

- Per discussion 30 Nov 2016 [1], alignment of manifest members with
Web App Manifest, a link to issue 69, and a note about needing further
discussion about the alignment.

[1] https://www.w3.org/2016/11/30-apps-minutes#item03
---
 index.html | 77 ++++++++++++++++++++++++++----------------------------
 1 file changed, 37 insertions(+), 40 deletions(-)

diff --git a/index.html b/index.html
index 257addf..d506df9 100644
--- a/index.html
+++ b/index.html
@@ -753,8 +753,8 @@
  • Register the payment app with the user agent for future use, - associating manifest's label and - icon set with the payment app for user reference. + associating manifest's name and + icons set with the payment app for user reference.
  • For each PaymentAppOption present in the @@ -763,7 +763,7 @@

  • Add a new payment option to the payment app's registration, associating it with the PaymentAppOption - label and icon fields. + name and icons fields.
  • For each payment method indicated in the @@ -826,30 +826,24 @@

    PaymentAppManifest interface

    +

    Issue 69: The Payment Apps Task Force has a goal of alignment with the draft Web App Manifest specification for data used to display payment app and options for selection by the user. More work is necessary to determine whether the Payment App API should reference (part of) the Web App Manifest specification, import definitions while that specification remains a draft, or define new terms.

           dictionary PaymentAppManifest {
-        DOMString label;
-        DOMString? icon;
-        sequence<PaymentAppOption> options;
+        required DOMString name;
+        sequence<ImageObject> icons;
+        required sequence<PaymentAppOption> options;
       };
    -
    label member
    +
    name member
    - The label member is a string that represents the + The name member is a string that represents the label for this payment app as it is usually displayed to the user.
    -
    icon member
    +
    icons member
    - The iconmember defines an icon for this - payment app as it is usually displayed to the user. -
    -
    - Need to define how an icon would be represented in this data. - Url? Data URL? Size options? Web - App Manifest may be used for inspiration. + The icons member is an array of image objects that can serve as iconic representations of the payment app when presented to the user for selection.
    options member
    @@ -880,26 +874,24 @@ 

           dictionary PaymentAppOption {
-        DOMString label;
-        DOMString? icon;
-        DOMString id;
+        required DOMString name;
+        sequence<ImageObjects> icons;
+        required DOMString id;
         sequence<DOMString> enabledMethods;
       };
    -
    -
    label member
    -
    - The label member is a string that represents the - label for this option as it is usually displayed to the user - when selecting a payment app. +
    +
    name member
    +
    + The name member is a string that represents the + label for this payment app as it is usually displayed + to the user.
    -
    icon member
    -
    - Need to define how an icon would be represented in this data. - Url? Data URL? Size options? Web - App Manifest may be used for inspiration. +
    icons member
    +
    + The icons member is an array of image objects that can serve as iconic representations of the payment app when presented to the user for selection.
    +
    id member
    The id member is an identifier, unique @@ -938,24 +930,29 @@

    navigator.serviceWorker.register('/exampleapp.js') .then(function(registration) { return registration.paymentAppManager.setManifest({ - label: "ExampleApp", - icon: "...", + name: "ExampleApp", + icons: [ + { + "src": "icon/lowres.webp", + "sizes": "48x48", + "type": "image/webp" + },{ + "src": "icon/lowres", + "sizes": "48x48" + } ] options: [ { - label: "Visa ending ****4756", - icon: "...", + name: "Visa ending ****4756", id: "dc2de27a-ca5e-4fbd-883e-b6ded6c69d4f", enabledMethods: ["basic-card#visa"] }, { - label: "My Bob Pay Account: john@example.com", - icon: "...", + name: "My Bob Pay Account: john@example.com", id: "c8126178-3bba-4d09-8f00-0771bcfd3b11", enabledMethods: ["https://bobpay.com/"] }, { - label: "Add new credit/debit card to ExampleApp", - icon: "...", + name: "Add new credit/debit card to ExampleApp", id: "new-card", enabledMethods: [ "basic-card#visa", From 0176dfb5ee84c087109149d024989d83eefd1cf3 Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Thu, 1 Dec 2016 15:18:30 -0600 Subject: [PATCH 7/8] Updates to options based on 30 nov 2016 discussion MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit See minutes: https://www.w3.org/2016/11/30-apps-minutes#item05 * Support for selection of options is now required. * Changed language from “display” to “enable selection” --- index.html | 37 ++++++++++++++++--------------------- 1 file changed, 16 insertions(+), 21 deletions(-) diff --git a/index.html b/index.html index d506df9..4de6aca 100644 --- a/index.html +++ b/index.html @@ -425,7 +425,7 @@

    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 user agent does not require user selection to launch it.
      • -
    • The user agent displays payment options for direct selection by the user. For example, instead of merely displaying information about a payment app that supports cards, the user agent could display some representation of individual registered cards. If the user can select an option directly, that could contribute to reducing the total number of required user actions. Within the payment apps task force, it has been suggested that this specification support payment apps providing payment option information to user agents, but that user agents would have discretion whether to display it.
      • +
    • The user agent displays payment options for direct selection by the user. For example, instead of merely displaying information about a payment app that supports cards, the user agent could display some representation of individual registered cards. If the user can select an option directly, that could contribute to reducing the total number of required user actions.
  • It is likely that this specification will include guidance rather than requirements about specific user experience optimizations.
    • @@ -769,7 +769,7 @@

    For each payment method indicated in the PaymentAppOption's enabledMethods field, associate the payment option and the payment app - with the payment method for future use. + with the payment method.

    • @@ -861,10 +861,6 @@

    is to prepend the payment app name, e.g., "ExampleApp Visa ending in ***4756". However, when only one app is installed, the text "ExampleApp" is redundant.

    -

    It may be simpler for implementers to remove payment options - from this spec. A medium level of complexity is to specify - payment options, but give user agents choice of whether payment - options are supported.

@@ -896,15 +892,15 @@

The id member is an identifier, unique within the PaymentAppManifest, that will be passed to the - payment app to indicate which PaymentAppOption the user - selected. + payment app to indicate the PaymentAppOption selected + by the user.
enabledMethods member
The enabledMethods member lists the payment method identifiers of the - payment methods enabled by this option. + payment methods enabled by this option. When the merchant has provided a filter, it may be necessary to provide additional information about conditions under which the payment method is enabled.
@@ -1022,28 +1018,27 @@

Payment App Selection

Selectable App Information Display

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

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

- The output of the payment method matching algorithm will be a list of matching payment apps from registered - payment apps and a list of recommended payment apps. The user agent will present this list of payment apps to the user - so they can select how they want to handle the payment request. + The output of the payment method matching algorithm will be a list of matching payment apps and options from registered + payment apps, and a list of recommended payment apps. The user agent will present this list of payment apps to the user for selection.

-

For the display of matching payment apps:

+

For matching payment apps:

    -
  • The user agent MUST display any matching payment app. Note: See the definition of matching payment app, which excludes payment apps ignored due to user configuration or security issues.
    • +
  • The user agent MUST enable the user to select any matching payment app. Note: See the definition of matching payment app, which excludes payment apps ignored due to user configuration or security issues. Note also that the language here is about enabling selection rather than display — when the user agent displays only a subset of matching payment apps (e.g., the most recently used), the user must still be able to access other matching payment apps.
    • +
  • The user agent MUST enable the user to select any matching payment app options.
  • 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 apps 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 apps to control the ordering and define preselected defaults.
-

For the display of recommended payment apps:

+

For recommended payment apps:

  • The user agent SHOULD display recommended payment apps and allow configuration to not display recommended payment apps.
  • The user agent MUST distinguish recommended payment apps from registered payment apps.
    • @@ -1064,7 +1059,7 @@

    Selectable App Information Display

    Examples of Ordering of Selectable Payment Apps

    -

    The following are examples of user agent display behavior.

    +

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

    • For a given Web site, display payment apps in an order that reflects usage patterns for the site (e.g., a frequently used payment app at the top, or the most recently used payment app at the top).
    • Enable the user to set a preferred order for a given site or for all sites.
      • @@ -1147,8 +1142,8 @@

      Payment App Request Data

      optionId attribute
      - This attribute indicates which PaymentAppOption the user - selected. It corresponds to the id field provided during + This attribute indicates the PaymentAppOption selected by + the user. It corresponds to the id field provided during payment app registration.
      From e8c5304132e10713197f2bc0028f8d1798722825 Mon Sep 17 00:00:00 2001 From: Ian Jacobs Date: Mon, 12 Dec 2016 13:08:06 -0600 Subject: [PATCH 8/8] Added link to issue 73 https://github.com/w3c/webpayments-payment-apps-api/issues/73 --- index.html | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/index.html b/index.html index 4de6aca..474ab59 100644 --- a/index.html +++ b/index.html @@ -1415,9 +1415,8 @@

      user interaction for the purposes of determining whether the service worker is allowed to open a window.

      -

      - The actual rendering of a payment app window is a user agent - implementation detail. While opening an entirely new window is possible, +

      See issue 73. What is required for interoperability here in how the service worker can open a window? How much of the actual rendering of a payment app window is a user agent + implementation detail? While opening an entirely new window is possible, it is more likely that the contents will be rendered in a way that makes it more obvious that the interactions pertain to the payment transaction. This is an area for potential user agent experimentation @@ -1425,7 +1424,7 @@

      other types of windows can be distinguished based on the event type the user agent is using to grant permission to open a window.

      -

      The remainder of this section is a non-normative explanation of how +

      The remainder of this section is currently a non-normative explanation of how the service worker WindowClient class can be used to interact with users.