From 79d929fc5db6dca6f191710761e29a2c36c08c2f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marcos=20C=C3=A1ceres?= Date: Thu, 17 May 2018 18:22:52 +1000 Subject: [PATCH] editorial: relocate Algorithms section In order to do response.retry(), the Algorithms section needs to move to PaymentRequest. This is because the some algorithms are very specific to PaymentRequest. Eventually, we might end up with shared algorithms between PaymentRequest and PaymentResponse. --- index.html | 1201 ++++++++++++++++++++++++++-------------------------- 1 file changed, 605 insertions(+), 596 deletions(-) diff --git a/index.html b/index.html index 795e4fb4..04ab9021 100644 --- a/index.html +++ b/index.html @@ -1394,6 +1394,611 @@

+
+

+ PaymentRequest Algorithms +

+

+ When the internal slot [[\state]] of a PaymentRequest + object is set to "interactive", the user agent will + trigger the following algorithms based on user interaction. +

+
+

+ Shipping address changed algorithm +

+

+ The shipping address changed algorithm runs when the + user provides a new shipping address. It MUST run the following + steps: +

+
    +
  1. Let request be the PaymentRequest object that + the user is interacting with. +
    2. +
  2. + Queue a task on the user interaction task source to + run the following steps: +
      +
    1. +
      +

      + The redactList optionally gives user agents + the possibility to limit the amount of personal + information about the recipient that the API shares with + the merchant. +

      +

      + For merchants, the resulting PaymentAddress object + provides enough information to, for example, calculate + shipping costs, but, in most cases, not enough + information to physically locate and uniquely identify + the recipient. +

      +

      + Unfortunately, even with the redactList, + recipient anonymity cannot be assured. This is because in + some countries postal codes are so fine-grained that they + can uniquely identify a recipient. +

      +
      Let redactList be the empty list. + Optionally, set redactList to « "organization", + "phone", "recipient", "addressLine" ». +
      2. +
    2. Let address be the result of running the steps + to create a PaymentAddress from user-provided + input with redactList. +
      3. +
    3. Set the shippingAddress attribute + on request to address. +
      4. +
    4. Run the PaymentRequest updated algorithm with + request and "shippingaddresschange". +
      5. +
    +
    3. +
+
+
+

+ Shipping option changed algorithm +

+

+ The shipping option changed algorithm runs when the user + chooses a new shipping option. It MUST run the following steps: +

+
    +
  1. Let request be the PaymentRequest object that + the user is interacting with. +
    2. +
  2. + Queue a task on the user interaction task source to + run the following steps: +
      +
    1. Set the shippingOption attribute on + request to the id string of the + PaymentShippingOption provided by the user. +
      2. +
    2. Run the PaymentRequest updated algorithm with + request and "shippingoptionchange". +
      3. +
    +
    3. +
+
+
+

+ PaymentRequest updated algorithm +

+

+ The PaymentRequest updated algorithm is run by other + algorithms above to fire an event to indicate that a user + has made a change to a PaymentRequest called + request with an event name of name: +

+
    +
  1. If the request.[[\updating]] is true, then + terminate this algorithm and take no further action. Only one + update may take place at a time. The user agent SHOULD + ensure that this never occurs. +
    2. +
  2. If the request.[[\state]] is not set to + "interactive", then terminate this algorithm and take no + further action. The user agent user interface SHOULD ensure + that this never occurs. +
    3. +
  3. Let event be the result of creating an event using + PaymentRequestUpdateEvent. +
    4. +
  4. Initialize event's type attribute to name. +
    5. +
  5. + Dispatch + event at request. +
    6. +
  6. If + event.[[\waitForUpdate]] is true, disable any + part of the user interface that could cause another update event to + be fired. +
    7. +
+
+
+

+ User accepts the payment request algorithm +

+

+ The user accepts + the payment request algorithm runs when the user accepts the + payment request and confirms that they want to pay. It MUST + queue a task on the user interaction task source to + perform the following steps: +

+
    +
  1. Let request be the PaymentRequest object that + the user is interacting with. +
    2. +
  2. If the request.[[\updating]] is true, then + terminate this algorithm and take no further action. The user + agent user interface SHOULD ensure that this never occurs. +
    3. +
  3. If request.[[\state]] is not + "interactive", then terminate this algorithm and take no + further action. The user agent user interface SHOULD ensure + that this never occurs. +
    4. +
  4. If the requestShipping value of + request.[[\options]] is true, then if the + shippingAddress + attribute of request is null or if the shippingOption attribute of + request is null, then terminate this algorithm and + take no further action. The user agent SHOULD ensure that + this never occurs. +
    5. +
  5. Let response be a new PaymentResponse. +
    6. +
  6. Set the requestId + attribute value of response to the value of + request.[[\details]].id. +
    7. +
  7. Set the methodName + attribute value of response to the payment method + identifier for the payment method that the user selected + to accept the payment. +
    8. +
  8. Let handler be the payment handler selected + by the user. +
    9. +
  9. Set the details + attribute value of response to an object resulting from + running the handler's steps to respond to a payment + request. +
    10. +
  10. If the requestShipping value of + request.[[\options]] is false, then set the + shippingAddress + attribute value of response to null. Otherwise: +
      +
    1. Let redactList be the empty list. +
      2. +
    2. Let shippingAddress be the result of create a + PaymentAddress from user-provided input with + redactList. +
      3. +
    3. Set the shippingAddress attribute + value of response to shippingAddress. +
      4. +
    4. Set the shippingAddress attribute + value of request to shippingAddress. +
      5. +
    +
    11. +
  11. If the requestShipping value of + request.[[\options]] is true, then set the + shippingOption + attribute of response to the value of the shippingOption attribute of + request. Otherwise, set it to null. +
    12. +
  12. If the requestPayerName value of + request.[[\options]] is true, then set the + payerName attribute of + response to the payer's name provided by the user, or to + null if none was provided. Otherwise, set it to null. +
    13. +
  13. If the requestPayerEmail value of + request.[[\options]] is true, then set the + payerEmail attribute of + response to the payer's email address provided by the + user, or to null if none was provided. Otherwise, set it to null. +
    14. +
  14. If the requestPayerPhone value of + request.[[\options]] is true, then set the + payerPhone attribute of + response to the payer's phone number provided by the + user, or to null if none was provided. When setting the + payerPhone value, the + user agent SHOULD format the phone number to adhere to + [[!E.164]]. +
    15. +
  15. Set response.[[\completeCalled]] to false. +
    16. +
  16. Set request.[[\state]] to "closed". +
    17. +
  17. Set the user agent's payment request is showing + boolean to false. +
    18. +
  18. Resolve the pending promise + request.[[\acceptPromise]] with + response. +
    19. +
+
+
+

+ User aborts the payment request algorithm +

+

+ The user aborts the + payment request algorithm runs when the user aborts the + payment request through the currently interactive user interface. + It MUST queue a task on the user interaction task + source to perform the following steps: +

+
    +
  1. Let request be the PaymentRequest object that + the user is interacting with. +
    2. +
  2. If the request.[[\updating]] is true, then + terminate this algorithm and take no further action. The user + agent user interface SHOULD ensure that this never occurs. +
    3. +
  3. If request.[[\state]] is not + "interactive", then terminate this algorithm and take no + further action. The user agent user interface SHOULD ensure + that this never occurs. +
    4. +
  4. Set request.[[\state]] to "closed". +
    5. +
  5. Set the user agent's payment request is showing + boolean to false. +
    6. +
  6. Reject the promise request.[[\acceptPromise]] + with an "AbortError" DOMException. +
    7. +
+
+
+

+ Update a PaymentRequest's details algorithm +

+

+ The update a PaymentRequest's details + algorithm takes a PaymentDetailsUpdate + detailsPromise and a PaymentRequest + request. The steps are conditional on the + detailsPromise settling. If detailsPromise + never settles then the payment request is blocked. Users SHOULD + always be able to cancel a payment request. Implementations MAY + choose to implement a timeout for pending updates if + detailsPromise doesn't settle in a reasonable amount of + time. If an implementation chooses to implement a timeout, they + must execute the steps listed below in the "upon rejection" path. + Such a timeout is a fatal error for the payment request. +

+
    +
  1. + Upon rejection of detailsPromise: +
      +
    1. + Abort the update with an "AbortError" + DOMException. +
      2. +
    +
    2. +
  2. + Upon fulfillment of detailsPromise with value + value: +
      +
    1. Let details be the result of converting value to a + PaymentDetailsUpdate dictionary. If this throws + an exception, abort the update with the thrown + exception. +
      2. +
    2. Let serializedModifierData be an empty list. +
      3. +
    3. Let selectedShippingOption be null. +
      4. +
    4. Let shippingOptions be an empty + sequence<PaymentShippingOption>. +
      5. +
    5. Validate and canonicalize the details: +
        +
      1. If the + total member of details is present, then: +
          +
        1. + Check and canonicalize total + details.total.amount. If an exception is + thrown, then abort the update with that + exception. +
          2. +
        +
        2. +
      2. If the displayItems member of details + is present, then for each item in + details.displayItems: +
          +
        1. + Check and canonicalize amount + item.amount. If an exception is + thrown, then abort the update with that + exception. +
          2. +
        +
        3. +
      3. If the shippingOptions member of + details is present, and + request.[[\options]].requestShipping is + true, then: +
          +
        1. Set shippingOptions to + details.shippingOptions. +
          2. +
        2. Let seenIDs be an empty list. +
          3. +
        3. For each option in + shippingOptions: +
            +
          1. + Check and canonicalize amount + option.amount. If an + exception is thrown, then abort the update + with that exception. +
            2. +
          2. + If seenIDs contains + option.id, then abort + the update with a TypeError. +
            3. +
          3. Otherwise, append + option.id + to seenIDs. +
            4. +
          +
          4. +
        4. For each option in + shippingOptions: +
            +
          1. If option.selected is + true, then set selectedShippingOption to + option.id. +
            2. +
          +
          5. +
        +
        4. +
      4. If the modifiers member of details is + present, then: +
          +
        1. Let modifiers be the sequence + details.modifiers. +
          2. +
        2. Let serializedModifierData be an empty + list. +
          3. +
        3. For each PaymentDetailsModifier + modifier in modifiers: +
            +
          1. + Run the steps to + validate a payment method identifier with + modifier.supportedMethods. + If it returns false, then abort the update + with a RangeError exception. Optional, + inform the developer that the payment method + identifier is invalid. +
            2. +
          2. If the total member of + modifier is present, then: +
              +
            1. + Check and canonicalize total + modifier.total.amount. If an + exception is thrown, then abort the + update with that exception. +
              2. +
            +
            3. +
          3. If the additionalDisplayItems member of + modifier is present, then for each + PaymentItem item in + modifier.additionalDisplayItems: +
              +
            1. + Check and canonicalize amount + item.amount. If an + exception is thrown, then abort the + update with that exception. +
              2. +
            +
            4. +
          4. If the data member of + modifier is missing, let + serializedData be null. Otherwise, let + serializedData be the result of + JSON-serializing + modifier.data into a + string. If JSON-serializing throws an + exception, then abort the update with that + exception. +
            5. +
          5. Add serializedData to + serializedModifierData. +
            6. +
          6. Remove the data member of + modifier, if it is present. +
            7. +
          +
          4. +
        +
        5. +
      +
      6. +
    6. Update the PaymentRequest using the new details: +
        +
      1. If the + total member of details is present, then: +
          +
        1. Set + request.[[\details]].total + to details.total. +
          2. +
        +
        2. +
      2. If the displayItems member of details + is present, then: +
          +
        1. Set + request.[[\details]].displayItems + to details.displayItems. +
          2. +
        +
        3. +
      3. If the shippingOptions member of + details is present, and + request.[[\options]].requestShipping is + true, then: +
          +
        1. Set + request.[[\details]].shippingOptions + to shippingOptions. +
          2. +
        2. Set the value of request's shippingOption + attribute to selectedShippingOption. +
          3. +
        +
        4. +
      4. If the modifiers member of details is + present, then: +
          +
        1. Set + request.[[\details]].modifiers + to details.modifiers. +
          2. +
        2. Set + request.[[\serializedModifierData]] + to serializedModifierData. +
          3. +
        +
        5. +
      5. If request.[[\options]].requestShipping is + true, and + request.[[\details]].shippingOptions + is empty, then the developer has signified that there are + no valid shipping options for the currently-chosen shipping + address (given by request's shippingAddress). In + this case, the user agent SHOULD display an error + indicating this, and MAY indicate that the currently-chosen + shipping address is invalid in some way. The user agent + SHOULD use the error member of + details, if it is present, to give more + information about why there are no valid shipping options + for that address. +
        6. +
      +
      7. +
    +
    3. +
  3. In either case, run the following steps, after either the upon + rejection or upon fulfillment steps have concluded: +
      +
    1. Set request.[[\updating]] to false. +
      2. +
    2. The user agent SHOULD update the user interface + based on any changed values in request. If + appropriate, the user agent SHOULD re-enable user interface + elements that might have been disabled prior to running this + algorithm. +
      3. +
    +
    4. +
+

+ If any of the above steps say to abort the update with + an exception exception, then: +

+
    +
  1. Abort the current user interaction and close down any remaining + user interface. +
    2. +
  2. Set request.[[\state]] to "closed". +
    3. +
  3. Reject the promise request.[[\acceptPromise]] + with exception. +
    4. +
  4. Abort the algorithm. +
    5. +
+
+

+ Aborting the update is + performed when there is a fatal error updating the payment + request, such as the supplied detailsPromise + rejecting, or its fulfillment value containing invalid data. This + would potentially leave the payment request in an inconsistent + state since the developer hasn't successfully handled the change + event. Consequently, the PaymentRequest moves to a + "closed" state. The error is signaled to the developer + through the rejection of the [[\acceptPromise]], i.e., the + promise returned by show(). +

+

+ User agents might show an error message to the user when + this occurs. +

+
+
+
@@ -3384,602 +3989,6 @@

-
-

- Algorithms -

-

- When the internal slot [[\state]] of a PaymentRequest - object is set to "interactive", the user agent will - trigger the following algorithms based on user interaction. -

-
-

- Shipping address changed algorithm -

-

- The shipping address changed algorithm runs when the user - provides a new shipping address. It MUST run the following steps: -

-
    -
  1. Let request be the PaymentRequest object that - the user is interacting with. -
    2. -
  2. - Queue a task on the user interaction task source to - run the following steps: -
      -
    1. -
      -

      - The redactList optionally gives user agents the - possibility to limit the amount of personal information - about the recipient that the API shares with the merchant. -

      -

      - For merchants, the resulting PaymentAddress object - provides enough information to, for example, calculate - shipping costs, but, in most cases, not enough information - to physically locate and uniquely identify the recipient. -

      -

      - Unfortunately, even with the redactList, - recipient anonymity cannot be assured. This is because in - some countries postal codes are so fine-grained that they - can uniquely identify a recipient. -

      -
      Let redactList be the empty list. Optionally, - set redactList to « "organization", "phone", - "recipient", "addressLine" ». -
      2. -
    2. Let address be the result of running the steps to - create a PaymentAddress from user-provided - input with redactList. -
      3. -
    3. Set the shippingAddress attribute on - request to address. -
      4. -
    4. Run the PaymentRequest updated algorithm with - request and "shippingaddresschange". -
      5. -
    -
    3. -
-
-
-

- Shipping option changed algorithm -

-

- The shipping option changed algorithm runs when the user - chooses a new shipping option. It MUST run the following steps: -

-
    -
  1. Let request be the PaymentRequest object that - the user is interacting with. -
    2. -
  2. - Queue a task on the user interaction task source to - run the following steps: -
      -
    1. Set the shippingOption attribute on - request to the id string of the - PaymentShippingOption provided by the user. -
      2. -
    2. Run the PaymentRequest updated algorithm with - request and "shippingoptionchange". -
      3. -
    -
    3. -
-
-
-

- PaymentRequest updated algorithm -

-

- The PaymentRequest updated algorithm is run by other - algorithms above to fire an event to indicate that a user has - made a change to a PaymentRequest called request - with an event name of name: -

-
    -
  1. If the request.[[\updating]] is true, then - terminate this algorithm and take no further action. Only one update - may take place at a time. The user agent SHOULD ensure that - this never occurs. -
    2. -
  2. If the request.[[\state]] is not set to - "interactive", then terminate this algorithm and take no - further action. The user agent user interface SHOULD ensure - that this never occurs. -
    3. -
  3. Let event be the result of creating an event using - PaymentRequestUpdateEvent. -
    4. -
  4. Initialize event's type attribute to name. -
    5. -
  5. - Dispatch - event at request. -
    6. -
  6. If - event.[[\waitForUpdate]] is true, disable any part - of the user interface that could cause another update event to be - fired. -
    7. -
-
-
-

- User accepts the payment request algorithm -

-

- The user accepts the - payment request algorithm runs when the user accepts the - payment request and confirms that they want to pay. It MUST queue - a task on the user interaction task source to perform the - following steps: -

-
    -
  1. Let request be the PaymentRequest object that - the user is interacting with. -
    2. -
  2. If the request.[[\updating]] is true, then - terminate this algorithm and take no further action. The user - agent user interface SHOULD ensure that this never occurs. -
    3. -
  3. If request.[[\state]] is not - "interactive", then terminate this algorithm and take no - further action. The user agent user interface SHOULD ensure - that this never occurs. -
    4. -
  4. If the requestShipping value of - request.[[\options]] is true, then if the - shippingAddress - attribute of request is null or if the shippingOption attribute of - request is null, then terminate this algorithm and take no - further action. The user agent SHOULD ensure that this never - occurs. -
    5. -
  5. Let response be a new PaymentResponse. -
    6. -
  6. Set the requestId - attribute value of response to the value of - request.[[\details]].id. -
    7. -
  7. Set the methodName - attribute value of response to the payment method - identifier for the payment method that the user selected - to accept the payment. -
    8. -
  8. Let handler be the payment handler selected by - the user. -
    9. -
  9. Set the details - attribute value of response to an object resulting from - running the handler's steps to respond to a payment - request. -
    10. -
  10. If the requestShipping value of - request.[[\options]] is false, then set the - shippingAddress - attribute value of response to null. Otherwise: -
      -
    1. Let redactList be the empty list. -
      2. -
    2. Let shippingAddress be the result of create a - PaymentAddress from user-provided input with - redactList. -
      3. -
    3. Set the shippingAddress attribute - value of response to shippingAddress. -
      4. -
    4. Set the shippingAddress attribute - value of request to shippingAddress. -
      5. -
    -
    11. -
  11. If the requestShipping value of - request.[[\options]] is true, then set the - shippingOption - attribute of response to the value of the shippingOption attribute of - request. Otherwise, set it to null. -
    12. -
  12. If the requestPayerName value of - request.[[\options]] is true, then set the payerName attribute of - response to the payer's name provided by the user, or to - null if none was provided. Otherwise, set it to null. -
    13. -
  13. If the requestPayerEmail value of - request.[[\options]] is true, then set the - payerEmail attribute of - response to the payer's email address provided by the - user, or to null if none was provided. Otherwise, set it to null. -
    14. -
  14. If the requestPayerPhone value of - request.[[\options]] is true, then set the - payerPhone attribute of - response to the payer's phone number provided by the user, - or to null if none was provided. When setting the payerPhone value, the user agent - SHOULD format the phone number to adhere to [[!E.164]]. -
    15. -
  15. Set response.[[\completeCalled]] to false. -
    16. -
  16. Set request.[[\state]] to "closed". -
    17. -
  17. Set the user agent's payment request is showing - boolean to false. -
    18. -
  18. Resolve the pending promise - request.[[\acceptPromise]] with - response. -
    19. -
-
-
-

- User aborts the payment request algorithm -

-

- The user aborts the - payment request algorithm runs when the user aborts the payment - request through the currently interactive user interface. It MUST - queue a task on the user interaction task source to - perform the following steps: -

-
    -
  1. Let request be the PaymentRequest object that - the user is interacting with. -
    2. -
  2. If the request.[[\updating]] is true, then - terminate this algorithm and take no further action. The user - agent user interface SHOULD ensure that this never occurs. -
    3. -
  3. If request.[[\state]] is not - "interactive", then terminate this algorithm and take no - further action. The user agent user interface SHOULD ensure - that this never occurs. -
    4. -
  4. Set request.[[\state]] to "closed". -
    5. -
  5. Set the user agent's payment request is showing - boolean to false. -
    6. -
  6. Reject the promise request.[[\acceptPromise]] - with an "AbortError" DOMException. -
    7. -
-
-
-

- Update a PaymentRequest's details algorithm -

-

- The update a PaymentRequest's details - algorithm takes a PaymentDetailsUpdate - detailsPromise and a PaymentRequest - request. The steps are conditional on the - detailsPromise settling. If detailsPromise - never settles then the payment request is blocked. Users SHOULD - always be able to cancel a payment request. Implementations MAY - choose to implement a timeout for pending updates if - detailsPromise doesn't settle in a reasonable amount of - time. If an implementation chooses to implement a timeout, they must - execute the steps listed below in the "upon rejection" path. Such a - timeout is a fatal error for the payment request. -

-
    -
  1. - Upon rejection of detailsPromise: -
      -
    1. - Abort the update with an "AbortError" - DOMException. -
      2. -
    -
    2. -
  2. - Upon fulfillment of detailsPromise with value - value: -
      -
    1. Let details be the result of converting value to a - PaymentDetailsUpdate dictionary. If this throws an - exception, abort the update with the thrown exception. -
      2. -
    2. Let serializedModifierData be an empty list. -
      3. -
    3. Let selectedShippingOption be null. -
      4. -
    4. Let shippingOptions be an empty - sequence<PaymentShippingOption>. -
      5. -
    5. Validate and canonicalize the details: -
        -
      1. If the total - member of details is present, then: -
          -
        1. - Check and canonicalize total - details.total.amount. If an exception is - thrown, then abort the update with that - exception. -
          2. -
        -
        2. -
      2. If the displayItems member of details - is present, then for each item in - details.displayItems: -
          -
        1. - Check and canonicalize amount - item.amount. If an exception is - thrown, then abort the update with that - exception. -
          2. -
        -
        3. -
      3. If the shippingOptions member of - details is present, and - request.[[\options]].requestShipping is true, - then: -
          -
        1. Set shippingOptions to - details.shippingOptions. -
          2. -
        2. Let seenIDs be an empty list. -
          3. -
        3. For each option in - shippingOptions: -
            -
          1. - Check and canonicalize amount - option.amount. If an - exception is thrown, then abort the update - with that exception. -
            2. -
          2. - If seenIDs contains - option.id, then abort the - update with a TypeError. -
            3. -
          3. Otherwise, append option.id to - seenIDs. -
            4. -
          -
          4. -
        4. For each option in - shippingOptions: -
            -
          1. If option.selected is - true, then set selectedShippingOption to - option.id. -
            2. -
          -
          5. -
        -
        4. -
      4. If the modifiers member of details is - present, then: -
          -
        1. Let modifiers be the sequence - details.modifiers. -
          2. -
        2. Let serializedModifierData be an empty - list. -
          3. -
        3. For each PaymentDetailsModifier - modifier in modifiers: -
            -
          1. - Run the steps to - validate a payment method identifier with - modifier.supportedMethods. - If it returns false, then abort the update - with a RangeError exception. Optional, - inform the developer that the payment method - identifier is invalid. -
            2. -
          2. If the total member of modifier - is present, then: -
              -
            1. - Check and canonicalize total - modifier.total.amount. If an - exception is thrown, then abort the - update with that exception. -
              2. -
            -
            3. -
          3. If the additionalDisplayItems member of - modifier is present, then for each - PaymentItem item in - modifier.additionalDisplayItems: -
              -
            1. - Check and canonicalize amount - item.amount. If an - exception is thrown, then abort the - update with that exception. -
              2. -
            -
            4. -
          4. If the - data member of modifier is missing, - let serializedData be null. Otherwise, - let serializedData be the result of - JSON-serializing - modifier.data into a - string. If JSON-serializing throws an - exception, then abort the update with that - exception. -
            5. -
          5. Add serializedData to - serializedModifierData. -
            6. -
          6. Remove the data member of - modifier, if it is present. -
            7. -
          -
          4. -
        -
        5. -
      -
      6. -
    6. Update the PaymentRequest using the new details: -
        -
      1. If the total - member of details is present, then: -
          -
        1. Set - request.[[\details]].total - to details.total. -
          2. -
        -
        2. -
      2. If the displayItems member of details - is present, then: -
          -
        1. Set - request.[[\details]].displayItems - to details.displayItems. -
          2. -
        -
        3. -
      3. If the shippingOptions member of - details is present, and - request.[[\options]].requestShipping is true, - then: -
          -
        1. Set - request.[[\details]].shippingOptions - to shippingOptions. -
          2. -
        2. Set the value of request's shippingOption - attribute to selectedShippingOption. -
          3. -
        -
        4. -
      4. If the modifiers member of details is - present, then: -
          -
        1. Set - request.[[\details]].modifiers - to details.modifiers. -
          2. -
        2. Set - request.[[\serializedModifierData]] to - serializedModifierData. -
          3. -
        -
        5. -
      5. If request.[[\options]].requestShipping is true, - and - request.[[\details]].shippingOptions - is empty, then the developer has signified that there are no - valid shipping options for the currently-chosen shipping - address (given by request's shippingAddress). In - this case, the user agent SHOULD display an error indicating - this, and MAY indicate that the currently-chosen shipping - address is invalid in some way. The user agent SHOULD use the - error member of - details, if it is present, to give more - information about why there are no valid shipping options for - that address. -
        6. -
      -
      7. -
    -
    3. -
  3. In either case, run the following steps, after either the upon - rejection or upon fulfillment steps have concluded: -
      -
    1. Set request.[[\updating]] to false. -
      2. -
    2. The user agent SHOULD update the user interface based - on any changed values in request. If appropriate, the - user agent SHOULD re-enable user interface elements that might - have been disabled prior to running this algorithm. -
      3. -
    -
    4. -
-

- If any of the above steps say to abort the update with an - exception exception, then: -

-
    -
  1. Abort the current user interaction and close down any remaining - user interface. -
    2. -
  2. Set request.[[\state]] to "closed". -
    3. -
  3. Reject the promise request.[[\acceptPromise]] - with exception. -
    4. -
  4. Abort the algorithm. -
    5. -
-
-

- Aborting the update is performed - when there is a fatal error updating the payment request, such as - the supplied detailsPromise rejecting, or its - fulfillment value containing invalid data. This would potentially - leave the payment request in an inconsistent state since the - developer hasn't successfully handled the change event. - Consequently, the PaymentRequest moves to a "closed" - state. The error is signaled to the developer through the rejection - of the [[\acceptPromise]], i.e., the promise returned by - show(). -

-

- User agents might show an error message to the user when - this occurs. -

-
-
-

Security Considerations