From d5977207c5c7056cc909256c6c84b60794dc960a Mon Sep 17 00:00:00 2001 From: Rouslan Solomakhin Date: Tue, 14 Feb 2017 13:06:33 -0500 Subject: [PATCH] Define payment option filtering algorithm. Define the algorithm for filtering the payment options in the payment app. These payment options are used to invoke the payment app that the user selects. --- index.html | 75 +++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 55 insertions(+), 20 deletions(-) diff --git a/index.html b/index.html index 4a1c2cda..3b886804 100644 --- a/index.html +++ b/index.html @@ -628,30 +628,21 @@

  • Return acceptPromise and perform the remaining steps in parallel.
    • -
  • For each paymentMethod in - request.[[\serializedMethodData]]: -
      -
    1. Consult the appropriate payment apps to see if they - support any of the payment method identifiers given by the - first element of the paymentMethod tuple, passing - along the data string given by the second element of the tuple in - order to help them determine their support. -
      2. -
    -
    • -
  • If this consultation produced no supported method of paying, then - reject acceptPromise with a "NotSupportedError" - DOMException, and abort this algorithm. +
  • Let matchingOptions be the result of running the + filter payment options algorithm.
    • +
  • If matchingOptions is empty, then reject + acceptPromise with a "NotSupportedError" + DOMException, and abort this algorithm.

  • Otherwise, show a user interface to allow the user to interact - with the payment request process, using those payment apps - and payment methods which the above step identified as - feasible. The user agent MAY show payment methods in the order - given by supportedMethods, but SHOULD prioritize the - preference of the user when presenting payment methods and - applications. + with the payment request process, using those payment apps, + matchingOptions, and payment methods which the + above step identified as feasible. The user agent MAY show payment + methods in the order given by supportedMethods, but + SHOULD prioritize the preference of the user when presenting + payment methods and applications.

    The payment app should be sent the appropriate data from @@ -2342,6 +2333,50 @@

    • +
    +

    + Filter payment options algorithm +

    +

    + The filter payment options + algorithm runs when user agent presents the user with the + collection of payment options available for selection. It MUST run the + following steps: +

    +
      +
    1. Let matchingOptions be an empty list.
      2. +
    2. Let request be the PaymentRequest object that + the user is interacting with. +
    3. For each requestMethod in + request.[[\serializedMethodData]]: +
        +
      1. Let filters be requestMethod.data + members whose values are lists of strings.
        2. +
      2. For each option of the installed + payment apps: +
          +
        1. Let optionMatch be true.
          2. +
        2. For filterName in the keys of + requestMethod: +
            +
          1. If option.capabilities does not have key + filterName, set optionMatch to + false.
            2. +
          2. Otherwise, if the intersection of + filters[filterName] and + option.capabilities[filterName] is empty, set + optionMatch to false.
            3. +
          +
          3. +
        3. If optionMatch is true, add option + to matchingOptions.
          4. +
        +
        3. +
      +
      4. +
    4. Return matchingOptions.
      5. +
    +