diff --git a/index.html b/index.html index 74834ab..95dd084 100644 --- a/index.html +++ b/index.html @@ -355,8 +355,15 @@

Registration and Unregistration

Note: Registration is not necessarily a prerequisite to be able to use other types of payment apps (e.g., native payment apps). -
  • In this specification, payment app registration starts with service worker registration. Once the user consents to the registration, the payment app provides information to the browser about enabled payment methods (and potentially other information collectively called the "payment app manifest"); this is used for matching with payee-accepted payment methods. At this point, the payment app is registered with the user agent. Note: Registration does not refer to how the user establishes a relationship with the payment app provider, for example by setting up an account with that provider.
    • -
  • This specification does not require that the payment app manifest be independently addressable (e.g., in a file on the Web). See a issue 48.
    • +
  • In this specification, payment app registration starts with service + worker registration. Once the user consents to the registration, the + payment app provides information to the browser about enabled payment + methods and associated information; this is used for matching with + payee-accepted payment methods. At this point, the payment app is + registered with the user agent. Note: Registration + does not refer to how the user establishes a + relationship with the payment app provider, for example by setting up an + account with that provider.
  • We expect registrations to happen at various times (e.g., outside and inside of checkout), and with differing levels of user consent to modify their configuration within the user agent. In general, explicit consent should not be required while the user is within the context of the payment request UI. Here are some examples: @@ -380,7 +387,7 @@
  • When the user agent presents a recommended (unregistered) payment app for selection by the user, it uses merchant-provided information.
  • In the case where the user has already registered a recommended payment app, the user agent may use merchant-provided information to complement information available from the - payment app manifest or to present that payment app for + payment app or to present that payment app for selection in some special manner. Note: The Working Group is still discussing the display of information in the case @@ -611,10 +618,157 @@ 

           interface PaymentAppManager {
-        Promise<void> setManifest(PaymentAppManifest manifest);
-        Promise<PaymentAppManifest> getManifest ();
+        attribute PaymentAppOptions options;
+        attribute PaymentWallets wallets;
       };
    +
    +
    options attribute
    +
    + This attribute allows manipulation of payment options associated with a + payment app. To be presented to the user as part of the payment request + flow, payment apps 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 apps 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 apps is completley optional. If payment apps 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);
+          Promise<sequence<DOMString>>  keys();
+          Promise<boolean>              has(DOMString optionKey);
+          Promise<void>                 set(DOMString optionKey,
+                                              PaymentAppOption details);
+      };
+
    +

    + Where it appears, The optionKey parameter is a unique + identifier for the option; it will be passed to the payment app 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;
+        sequence<DOMString> enabledMethods;
+        object capabilities;
+      };
+
    +
    +
    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 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 app 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);
+          Promise<sequence<DOMString>>  keys();
+          Promise<boolean>              has(DOMString walletKey);
+          Promise<void>                 set(DOMString walletKey,
+                                              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 +

    + 
    +      dictionary WalletDetails {
+          required DOMString name;
+          sequence<ImageObject> icons;
+          required sequence<DOMString> optionKeys;
+      };
+
    +
    +
    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 +
    +
    +

    @@ -899,43 +1014,55 @@ 

              navigator.serviceWorker.register('/exampleapp.js')
          .then(function(registration) {
-           return registration.paymentAppManager.setManifest({
-             name: "ExampleApp",
-             icons: [
-                {
-                  src: "icon/lowres.webp",
-                  sizes: "48x48",
-                  type: "image/webp"
-                },{
-                  src: "icon/lowres",
-                  sizes: "48x48"
-                } ]
-             options: [
-               {
-                 name: "Visa ending ****4756",
-                 id: "dc2de27a-ca5e-4fbd-883e-b6ded6c69d4f",
-                 enabledMethods: ["basic-card"]
-               },
-               {
-                 name: "My Bob Pay Account: john@example.com",
-                 id: "c8126178-3bba-4d09-8f00-0771bcfd3b11",
-                 enabledMethods: ["https://bobpay.com/"]
-               },
-               {
-                 name: "Add new credit/debit card to ExampleApp",
-                 id: "new-card",
-                 enabledMethods: ["basic-card"]
+           registration.paymentAppManager.options.set(
+             "dc2de27a-ca5e-4fbd-883e-b6ded6c69d4f",
+             {
+               name: "Visa ending ****4756",
+               enabledMethods: ["basic-card"],
+               capabilities: {
+                 supportedNetworks: ['visa'],
+                 supportedTypes: ['credit']
                }
-             ],
-             canHandle: function (methodData, details) {
-               // TODO: Code here to return mapping from payment option IDs
-               // to methodData option indices.
-             }
-           });
-         }).then(function() {
-           console.log("Installed payment app from /paymentapp.js"); // Success!
-         }).catch(function(error) {
-           console.log(error);
+             });
+
+           registration.paymentAppManager.options.set(
+             "c8126178-3bba-4d09-8f00-0771bcfd3b11",
+             {
+               name: "My Bob Pay Account: john@example.com",
+               enabledMethods: ["https://bobpay.com/"]
+             });
+
+           registration.paymentAppManager.options.set(
+             "new-card",
+             {
+               name: "Add new credit/debit card to ExampleApp",
+               enabledMethods: ["basic-card"],
+               capabilities: {
+                 supportedNetworks:
+                   ['visa','mastercard','americanexpress','discover'],
+                 supportedTypes: ['credit','debit','prepaid']
+               }
+             });
+
+           registration.paymentAppManager.wallets.set(
+             "12a1b7e5-16c0-4c09-a312-9b191d08517b",
+             {
+               name: "Acme Bank Personal Accounts",
+               icons: [
+                        { src: "icon/lowres.webp",
+                          sizes: "48x48",
+                          type: "image/webp"
+                        },
+                        { src: "icon/lowres",
+                          sizes: "48x48"
+                        }
+                      ],
+               optionKeys: [
+                   "dc2de27a-ca5e-4fbd-883e-b6ded6c69d4f",
+                   "c8126178-3bba-4d09-8f00-0771bcfd3b11",
+                   "new-card"
+                 ]
+             });
          });

    @@ -948,8 +1075,15 @@

    Payment App Matching

    +

    + This section is obsolete. The current proposal involves folding + the payment app matching (based on the entries in + PaymentAppOption.capabilities) into the base Payment Request + specification. +

    - When the mediator calculates acceptedMethods during the + + When the user agent calculates acceptedMethods during the process of running the steps for the PaymentRequest.show() method, the means of determining whether a registered payment app should be made available for user selection is computed by @@ -960,7 +1094,7 @@

    Payment App Matching

  • For each PaymentAppOption option in the - payment app's PaymentAppManifest, add all entries in + payment app's PaymentAppManager.options, add all entries in option.enabledMethods to registeredMethods.
    • @@ -1051,6 +1185,7 @@

    Payment App Matching

    corresponding PaymentAppOption. +

    @@ -1190,7 +1325,7 @@

  • For each PaymentAppOption option in the - payment app's PaymentAppManifest, add all entries in + payment app's PaymentAppManager.options, add all entries in option.enabledMethods to registeredMethods.
    • @@ -1255,8 +1390,8 @@

  • For each PaymentAppOption option in the - payment app's PaymentAppManifest, add all entries in - option.enabledMethods to + payment app's PaymentAppManager.options, add all + entries in option.enabledMethods to registeredMethods.