Goals and scope

• Allow the user agent to act as intermediary between a merchant, user, and payment method provider.
• Enable user agents to streamline the user's payment experience by taking into account user preferences, merchant information, security considerations, and other factors.
• Standardize (to the extent that it makes sense) the communication flow between a merchant, user agent, and payment method provider.
• Enable a payment method provider to bring more secure payment transactions to the web.

The following are out of scope for this specification:

• Create a new payment method.
• Integrate directly with payment processors.

Declaring multiple ways of paying

When constructing a new {{PaymentRequest}}, a merchant uses the first argument (|methodData|) to list the different ways a user can pay for things (e.g., credit cards, Apple Pay, Google Pay, etc.). More specifically, the |methodData| sequence contains PaymentMethodData dictionaries containing the payment method identifiers for the payment methods that the merchant accepts and any associated payment method specific data (e.g., which credit card networks are supported).

          const methodData = [
            {
              supportedMethods: "https://example.com/payitforward",
              data: {
                payItForwardField: "ABC",
              },
            },
            {
              supportedMethods: "https://example.com/bobpay",
              data: {
                merchantIdentifier: "XXXX",
                bobPaySpecificField: true,
              },
            },
          ];
        

Describing what is being paid for

When constructing a new {{PaymentRequest}}, a merchant uses the second argument of the constructor (|details|) to provide the details of the transaction that the user is being asked to complete. This includes the total of the order and, optionally, some line items that can provide a detailed breakdown of what is being paid for.

          const details = {
            id: "super-store-order-123-12312",
            displayItems: [
              {
                label: "Sub-total",
                amount: { currency: "GBP", value: "55.00" },
              },
              {
                label: "Value-Added Tax (VAT)",
                amount: { currency: "GBP", value: "5.00" },
              },
            ],
            total: {
              label: "Total due",
              // The total is GBP£65.00 here because we need to
              // add shipping (below). The selected shipping
              // costs GBP£5.00.
              amount: { currency: "GBP", value: "65.00" },
            },
          };
        

Adding shipping options

Here we see an example of how to add two shipping options to the |details|.

          const shippingOptions = [
            {
              id: "standard",
              // Shipping by truck, 2 days
              label: "🚛  Envío por camión (2 dias)",
              amount: { currency: "EUR", value: "5.00" },
              selected: true,
            },
            {
              id: "drone",
              // Drone shipping, 2 hours
              label: "🚀 Drone Express (2 horas)",
              amount: { currency: "EUR", value: "25.00" }
            },
          ];
          Object.assign(details, { shippingOptions });
        

Conditional modifications to payment request

Here we see how to add a processing fee for using a card on a particular network. Notice that it requires recalculating the total.

          // Certain cards incur a $3.00 processing fee.
          const cardFee = {
            label: "Card processing fee",
            amount: { currency: "AUD", value: "3.00" },
          };

          // Modifiers apply when the user chooses to pay with
          // a card.
          const modifiers = [
            {
              additionalDisplayItems: [cardFee],
              supportedMethods: "https://example.com/cardpay",
              total: {
                label: "Total due",
                amount: { currency: "AUD", value: "68.00" },
              },
              data: {
                supportedNetworks: networks,
              },
            },
          ];
          Object.assign(details, { modifiers });
        

Requesting specific information from the end user

Some financial transactions require a user to provide specific information in order for a merchant to fulfill a purchase (e.g., the user's shipping address, in case a physical good needs to be shipped). To request this information, a merchant can pass a third optional argument (|options:PaymentOptions |) to the {{PaymentRequest}} constructor indicating what information they require. When the payment request is shown, the user agent will request this information from the end user and return it to the merchant when the user accepts the payment request.

          const options = {
            requestPayerEmail: false,
            requestPayerName: true,
            requestPayerPhone: false,
            requestShipping: true,
          }
        

Constructing a PaymentRequest

Having gathered all the prerequisite bits of information, we can now construct a {{PaymentRequest}} and request that the browser present it to the user:

          async function doPaymentRequest() {
            try {
              const request = new PaymentRequest(methodData, details, options);
              // See below for a detailed example of handling these events
              request.onshippingaddresschange = ev => ev.updateWith(details);
              request.onshippingoptionchange = ev => ev.updateWith(details);
              const response = await request.show();
              await validateResponse(response);
            } catch (err) {
              // AbortError, SecurityError
              console.error(err);
            }
          }
          async function validateResponse(response) {
            try {
              const errors = await checkAllValuesAreGood(response);
              if (errors.length) {
                await response.retry(errors);
                return validateResponse(response);
              }
              await response.complete("success");
            } catch (err) {
              // Something went wrong...
              await response.complete("fail");
            }
          }
          // Must be called as a result of a click
          // or some explicit user action.
          doPaymentRequest();
        

Handling events and updating the payment request

Prior to the user accepting to make payment, the site is given an opportunity to update the payment request in response to user input. This can include, for example, providing additional shipping options (or modifying their cost), removing items that cannot ship to a particular address, etc.

          const request = new PaymentRequest(methodData, details, options);
          // Async update to details
          request.onshippingaddresschange = ev => {
            ev.updateWith(checkShipping(request));
          };
          // Sync update to the total
          request.onshippingoptionchange = ev => {
            // selected shipping option
            const { shippingOption } = request;
            const newTotal = {
              currency: "USD",
              label: "Total due",
              value: calculateNewTotal(shippingOption),
            };
            ev.updateWith({ total: newTotal });
          };
          async function checkShipping(request) {
            try {
              const { shippingAddress } = request;

              await ensureCanShipTo(shippingAddress);
              const { shippingOptions, total } = await calculateShipping(shippingAddress);

              return { shippingOptions, total };
            } catch (err) {
              // Shows error to user in the payment sheet.
              return { error: `Sorry! we can't ship to your address.` };
            }
          }
        

Fine-grained error reporting

A developer can use the {{PaymentDetailsUpdate/shippingAddressErrors}} member of the {{PaymentDetailsUpdate}} dictionary to indicate that there are validation errors with specific attributes of a {{ContactAddress}}. The {{PaymentDetailsUpdate/shippingAddressErrors}} member is a {{AddressErrors}} dictionary, whose members specifically demarcate the fields of a [=physical address=] that are erroneous while also providing helpful error messages to be displayed to the end user.

          request.onshippingaddresschange = ev => {
            ev.updateWith(validateAddress(request.shippingAddress));
          };
          function validateAddress(shippingAddress) {
            const error = "Can't ship to this address.";
            const shippingAddressErrors = {
              city: "FarmVille is not a real place.",
              postalCode: "Unknown postal code for your country.",
            };
            // Empty shippingOptions implies that we can't ship
            // to this address.
            const shippingOptions = [];
            return { error, shippingAddressErrors, shippingOptions };
          }
        

POSTing payment response back to a server

It's expected that data in a {{PaymentResponse}} will be POSTed back to a server for processing. To make this as easy as possible, {{PaymentResponse}} can use the [=default toJSON steps=] (i.e., `.toJSON()`) to serializes the object directly into JSON. This makes it trivial to POST the resulting JSON back to a server using the [[[fetch]]]:

          async function doPaymentRequest() {
            const payRequest = new PaymentRequest(methodData, details);
            const payResponse = await payRequest.show();
            let result = "";
            try {
              const httpResponse = await fetch("/process-payment", {
                method: "POST",
                headers: { "Content-Type": "application/json" },
                body: payResponse.toJSON(),
              });
              result = httpResponse.ok ? "success" : "fail";
            } catch (err) {
              console.error(err);
              result = "fail";
            }
            await payResponse.complete(result);
          }
          doPaymentRequest();
        

Using with cross-origin iframes

To indicate that a cross-origin [^iframe^] is allowed to invoke the payment request API, the [^iframe/allow^] attribute along with the "payment" keyword can be specified on the [^iframe^] element.

          <iframe
            src="https://cross-origin.example"
            allow="payment">
          </iframe>
        

If the [^iframe^] will be navigated across multiple origins that support the Payment Request API, then one can set [^iframe/allow^] to `"payment *"`. The [[[permissions-policy]]] specification provides further details and examples.

Constructor

The {{PaymentRequest}} is constructed using the supplied sequence of PaymentMethodData |methodData| including any payment method specific {{PaymentMethodData/data}}, the PaymentDetailsInit |details|, and the {{PaymentOptions}} |options|.

The PaymentRequest(|methodData|, |details|, |options|) constructor MUST act as follows:

1. If [=this=]'s [=relevant global object=]'s [=associated `Document`=] is not allowed to use the "payment" permission, then [=exception/throw=] a {{"SecurityError"}} {{DOMException}}.
2. Establish the request's id:
   1. If |details|.{{PaymentDetailsInit/id}} is missing, add an {{PaymentDetailsInit/id}} member to |details| and set its value to a UUID [[RFC4122]].
3. Let |serializedMethodData| be an empty list.
4. Process payment methods:
   1. If the length of the |methodData| sequence is zero, then [=exception/throw=] a {{TypeError}}, optionally informing the developer that at least one payment method is required.
   2. Let |seenPMIs:Set| be the empty [=set=].
   3. For each |paymentMethod| of |methodData|:
      1. Run the steps to validate a payment method identifier with |paymentMethod|.{{PaymentMethodData/supportedMethods}}. If it returns false, then throw a {{RangeError}} exception. Optionally, inform the developer that the payment method identifier is invalid.
      2. Let |pmi| be the result of parsing |paymentMethod|.{{PaymentMethodData/supportedMethods}} with [=basic URL parser=]:
         1. If failure, set |pmi| to |paymentMethod|.{{PaymentMethodData/supportedMethods}}.
      3. If |seenPMIs| [=set/contain|contains=] |pmi| throw a {{RangeError}} {{DOMException}} optionally informing the developer that this [=payment method identifier=] is a duplicate.
      4. [=set/Append=] |pmi| to |seenPMIs|.
      5. If the {{PaymentMethodData/data}} member of |paymentMethod| is missing, let |serializedData| be null. Otherwise, let |serializedData| be the result of [=serialize a JavaScript value to a JSON string|serialize=] |paymentMethod|.{{PaymentMethodData/data}} into a JSON string. Rethrow any exceptions.
      6. If |serializedData| is not null, and if the specification that defines the |paymentMethod|.{{PaymentMethodData/supportedMethods}} specifies an [=Payment Method/additional data type=]:
         1. Let |object| be the result of JSON-parsing |serializedData|.

         2. Let |idl| be the result of [=converted to an IDL value|converting=] |object| to an IDL value of the [=Payment Method/additional data type=]. Rethrow any exceptions.

         3. Run the steps to validate payment method data, if any, from the specification that defines the |paymentMethod|.{{PaymentMethodData/supportedMethods}} on |object|. Rethrow any exceptions.

            These step assures that any IDL type conversion and validation errors are caught as early as possible.

      7. Add the tuple (|paymentMethod|.{{PaymentMethodData/supportedMethods}}, |serializedData|) to |serializedMethodData|.
5. Process the total:
   1. Check and canonicalize total amount |details|.{{PaymentDetailsInit/total}}.{{PaymentItem/amount}}. Rethrow any exceptions.
6. If the {{PaymentDetailsBase/displayItems}} member of |details| is present, then for each |item| in |details|.{{PaymentDetailsBase/displayItems}}:
   1. Check and canonicalize amount |item|.{{PaymentItem/amount}}. Rethrow any exceptions.
7. Let |selectedShippingOption| be null.
8. If the {{PaymentOptions/requestShipping}} member of |options| is present and set to true, process shipping options:
   1. Let |options:PaymentShippingOption| be an empty sequence<{{PaymentShippingOption}}>.
   2. If the {{PaymentDetailsBase/shippingOptions}} member of |details| is present, then:
      1. Let |seenIDs| be an empty set.
      2. For each |option:PaymentShippingOption| in |details|.{{PaymentDetailsBase/shippingOptions}}:
         1. Check and canonicalize amount |item|.{{PaymentItem/amount}}. Rethrow any exceptions.
         2. If |seenIDs| contains |option|.{{PaymentShippingOption/id}}, then throw a {{TypeError}}. Optionally, inform the developer that shipping option IDs must be unique.
         3. Otherwise, append |option|.{{PaymentShippingOption/id}} to |seenIDs|.
         4. If |option|.{{PaymentShippingOption/selected}} is true, then set |selectedShippingOption| to |option|.{{PaymentShippingOption/id}}.
   3. Set |details|.{{PaymentDetailsBase/shippingOptions}} to |options|.
9. Let |serializedModifierData| be an empty list.
10. Process payment details modifiers:
    1. Let |modifiers| be an empty sequence<{{PaymentDetailsModifier}}>.
    2. If the {{PaymentDetailsBase/modifiers}} member of |details| is present, then:
       1. Set |modifiers| to |details|.{{PaymentDetailsBase/modifiers}}.
       2. For each |modifier| of |modifiers|:
          1. If the {{PaymentDetailsModifier/total}} member of |modifier| is present, then:
             1. Check and canonicalize total amount |modifier|.{{PaymentDetailsModifier/total}}.{{PaymentItem/amount}}. Rethrow any exceptions.
          2. If the {{PaymentDetailsModifier/additionalDisplayItems}} member of |modifier| is present, then for each |item| of |modifier|.{{PaymentDetailsModifier/additionalDisplayItems}}:
             1. Check and canonicalize amount |item|.{{PaymentItem/amount}}. Rethrow any exceptions.
          3. If the {{PaymentDetailsModifier/data}} member of |modifier| is missing, let |serializedData| be null. Otherwise, let |serializedData| be the result of [=serialize a JavaScript value to a JSON string|serialize=] |modifier|.{{PaymentDetailsModifier/data}} into a JSON string. Rethrow any exceptions.
          4. Add the tuple (|modifier|.{{PaymentDetailsModifier/supportedMethods}}, |serializedData|) to |serializedModifierData|.
          5. Remove the {{PaymentDetailsModifier/data}} member of |modifier|, if it is present.
    3. Set |details|.{{PaymentDetailsBase/modifiers}} to |modifiers|.
11. Let |request:PaymentRequest| be a new {{PaymentRequest}}.
12. Set |request|.{{PaymentRequest/[[handler]]}} to `null`.
13. Set |request|.{{PaymentRequest/[[options]]}} to |options|.
14. Set |request|.{{PaymentRequest/[[state]]}} to "[=PaymentRequest/created=]".
15. Set |request|.{{PaymentRequest/[[updating]]}} to false.
16. Set |request|.{{PaymentRequest/[[details]]}} to |details|.
17. Set |request|.{{PaymentRequest/[[serializedModifierData]]}} to |serializedModifierData|.
18. Set |request|.{{PaymentRequest/[[serializedMethodData]]}} to |serializedMethodData|.
19. Set |request|.{{PaymentRequest/[[response]]}} to null.
20. Set the value of |request|'s {{PaymentRequest/shippingOption}} attribute to |selectedShippingOption|.
21. Set the value of the {{PaymentRequest/shippingAddress}} attribute on |request| to null.
22. If |options|.{{PaymentOptions/requestShipping}} is set to true, then set the value of the {{PaymentRequest/shippingType}} attribute on |request| to |options|.{{PaymentOptions/shippingType}}. Otherwise, set it to null.
23. Return |request|.

id attribute

When getting, the {{PaymentRequest/id}} attribute returns this {{PaymentRequest}}'s {{PaymentRequest/[[details]]}}.{{PaymentDetailsInit/id}}.

show() method

The show(optional |detailsPromise|) method MUST act as follows:

1. Let |request:PaymentRequest| be [=this=].
2. If the [=relevant global object=] of [=request=] does not have [=transient activation=], the user agent MAY:
   1. Return [=a promise rejected with=] with a {{"SecurityError"}} {{DOMException}}.

   This allows the user agent to not require user activation, for example to support redirect flows where a user activation may not be present upon redirect. See for security considerations.

   See also issue #1022 for discussion around providing more guidance in the specification on when user agents should or should not require a user activation for {{PaymentRequest/show()}}.

3. Otherwise, [=consume user activation=] of the [=relevant global object=].
4. Let |document| be |request|'s [=relevant global object=]'s [=associated `Document`=].
5. If |document| is not [=Document/fully active=], then return a promise rejected with an {{"InvalidStateError"}} {{DOMException}}.
6. If |document|'s [=Document/visibility state=] is not `"visible"`, then return a promise rejected with an {{"AbortError"}} {{DOMException}}.

7. Optionally, if the user agent wishes to disallow the call to {{PaymentRequest/show()}} to protect the user, then return a promise rejected with a {{"SecurityError"}} {{DOMException}}. For example, the user agent may limit the rate at which a page can call {{PaymentRequest/show()}}, as described in section .

8. If |request|.{{PaymentRequest/[[state]]}} is not "[=PaymentRequest/created=]" then return a promise rejected with an {{"InvalidStateError"}} {{DOMException}}.
9. If the user agent's payment request is showing boolean is true, then:
   1. Set |request|.{{PaymentRequest/[[state]]}} to "[=PaymentRequest/closed=]".
   2. Return a promise rejected with an {{"AbortError"}} {{DOMException}}.
10. Set |request|.{{PaymentRequest/[[state]]}} to "[=PaymentRequest/interactive=]".
11. Let |acceptPromise:Promise| be a new promise.
12. Set |request|.{{PaymentRequest/[[acceptPromise]]}} to |acceptPromise|.

13. Optionally:

    1. Reject |acceptPromise| with an {{"AbortError"}} {{DOMException}}.
    2. Set |request|.{{PaymentRequest/[[state]]}} to "[=PaymentRequest/closed=]".
    3. Return |acceptPromise|.

    This allows the user agent to act as if the user had immediately [=user aborts the payment request|aborted the payment request=], at its discretion. For example, in "private browsing" modes or similar, user agents might take advantage of this step.

14. Set |request|'s payment-relevant browsing context's payment request is showing boolean to true.
15. Return |acceptPromise| and perform the remaining steps in parallel.
16. Let |handlers:list| be an empty list.
17. For each |paymentMethod| tuple in |request|.{{PaymentRequest/[[serializedMethodData]]}}:
    1. Let |identifier| be the first element in the |paymentMethod| tuple.
    2. Let |data| be the result of JSON-parsing the second element in the |paymentMethod| tuple.
    3. If the specification that defines the |identifier| specifies an [=Payment Method/additional data type=], then [=converted to an IDL value|convert=] |data| to an IDL value of that type. Otherwise, [=converted to an IDL value|convert=] |data| to {{object}}.
    4. If conversion results in an exception |error|:
       1. Set |request|.{{PaymentRequest/[[state]]}} to "[=PaymentRequest/closed=]".
       2. Reject |acceptPromise| with |error|.
       3. Set |request|'s payment-relevant browsing context's payment request is showing boolean to false.
       4. Terminate this algorithm.
    5. Let |registeredHandlers| be a list of registered payment handlers for the payment method |identifier|.
    6. For each |handler| in |registeredHandlers|:
       1. Let |canMakePayment| be the result of running |handler|'s [=Payment Handler/steps to check if a payment can be made=] with |data|.
       2. If |canMakePayment| is true, then append |handler| to |handlers|.
18. If |handlers| is empty, then:
    1. Set |request|.{{PaymentRequest/[[state]]}} to "[=PaymentRequest/closed=]".
    2. Reject |acceptPromise| with {{"NotSupportedError"}} {{DOMException}}.
    3. Set |request|'s payment-relevant browsing context's payment request is showing boolean to false.
    4. Terminate this algorithm.

19. Present a user interface that will allow the user to interact with the |handlers|. The user agent SHOULD prioritize the user's preference when presenting payment methods. The user interface SHOULD be presented using the language and locale-based formatting that matches the |document|'s [=document element|document element's=] [=Node/language=], if any, or an appropriate fallback if that is not available.

20. If |detailsPromise| was passed, then:
    1. Run the update a PaymentRequest's details algorithm with |detailsPromise|, |request|, and null.
    2. Wait for the |detailsPromise| to settle.

       Based on how the |detailsPromise| settles, the update a PaymentRequest's details algorithm determines how the payment UI behaves. That is, upon rejection of the |detailsPromise|, the payment request aborts. Otherwise, upon fulfillment |detailsPromise|, the user agent re-enables the payment request UI and the payment flow can continue.

21. Set |request|.{{PaymentRequest/[[handler]]}} be the payment handler selected by the end-user.
22. Let |modifiers:list| be an empty list.
23. For each |tuple| in {{PaymentRequest/[[serializedModifierData]]}}:
    1. If the first element of |tuple| (a PMI) matches the payment method identifier of |request|.{{PaymentRequest/[[handler]]}}, then append the second element of |tuple| (the serialized method data) to |modifiers|.

24. Pass the [=converted to an IDL value|converted=] second element in the |paymentMethod| tuple and |modifiers|. Optionally, the user agent SHOULD send the appropriate data from |request| to the user-selected payment handler in order to guide the user through the payment process. This includes the various attributes and other [=internal slots=] of |request| (some MAY be excluded for privacy reasons where appropriate).

    Handling of multiple applicable modifiers in the {{PaymentRequest/[[serializedModifierData]]}} [=internal slot=] is payment handler specific and beyond the scope of this specification. Nevertheless, it is RECOMMENDED that payment handlers use a "last one wins" approach with items in the {{PaymentRequest/[[serializedModifierData]]}} list: that is to say, an item at the end of the list always takes precedence over any item at the beginning of the list (see example below).

    The |acceptPromise| will later be resolved or rejected by the user accepts the payment request algorithm, or the user aborts the payment request algorithm (which are triggered through interaction with the user interface), or the payment handler indicates an internal error algorithm.

    If |document| stops being [=Document/fully active=] while the user interface is being shown, or no longer is by the time this step is reached, then:

    1. Close down the user interface.
    2. Set |request|.{{PaymentRequest/[[state]]}} to "[=PaymentRequest/closed=]".
    3. Set |request|'s payment-relevant browsing context's payment request is showing boolean to false.
    4. Queue a task on the user interaction task source to [=reject=] |acceptPromise| with an {{"AbortError"}} {{DOMException}}.

abort() method

The {{PaymentRequest/abort()}} method MUST act as follows:

1. Let |request:PaymentRequest| be [=this=].
2. If |request|.{{PaymentRequest/[[response]]}} is not null, and |request|.{{PaymentRequest/[[response]]}}.{{PaymentResponse/[[retryPromise]]}} is not null, return a promise rejected with an {{"InvalidStateError"}} {{DOMException}}.
3. If the value of |request|.{{PaymentRequest/[[state]]}} is not "[=PaymentRequest/interactive=]" then return a promise rejected with an {{"InvalidStateError"}} {{DOMException}}.
4. Let |promise:Promise| be a new promise.
5. Return |promise| and perform the remaining steps in parallel.
6. Try to abort the current user interaction with the payment handler and close down any remaining user interface.
7. Queue a task on the user interaction task source to perform the following steps:
   1. If it is not possible to abort the current user interaction, then reject |promise| with {{"InvalidStateError"}} {{DOMException}} and abort these steps.
   2. Set |request|.{{PaymentRequest/[[state]]}} to "[=PaymentRequest/closed=]".
   3. Reject the promise |request|.{{PaymentRequest/[[acceptPromise]]}} with an {{"AbortError"}} {{DOMException}}.
   4. Resolve |promise| with undefined.

canMakePayment() method

The {{PaymentRequest/canMakePayment()}} method MUST run the can make payment algorithm.

shippingAddress attribute

A {{PaymentRequest}}'s {{PaymentRequest/shippingAddress}} attribute is populated when the user provides a shipping address. It is null by default. When a user provides a shipping address, the shipping address changed algorithm runs.

shippingType attribute

A {{PaymentRequest}}'s {{PaymentRequest/shippingType}} attribute is the type of shipping used to fulfill the transaction. Its value is either a {{PaymentShippingType}} enum value, or null if none is provided by the developer during [=PaymentRequest.PaymentRequest()|construction=] (see {{PaymentOptions}}'s {{PaymentOptions/shippingType}} member).

onshippingaddresschange attribute

A {{PaymentRequest}}'s {{PaymentRequest/onshippingaddresschange}} attribute is an {{EventHandler}} for a {{PaymentRequestUpdateEvent}} named shippingaddresschange.

shippingOption attribute

A {{PaymentRequest}}'s {{PaymentRequest/shippingOption}} attribute is populated when the user chooses a shipping option. It is null by default. When a user chooses a shipping option, the shipping option changed algorithm runs.

onshippingoptionchange attribute

A {{PaymentRequest}}'s {{PaymentRequest/onshippingoptionchange}} attribute is an {{EventHandler}} for a {{PaymentRequestUpdateEvent}} named shippingoptionchange.

onpaymentmethodchange attribute

A {{PaymentRequest}}'s {{PaymentRequest/onpaymentmethodchange}} attribute is an {{EventHandler}} for a {{PaymentMethodChangeEvent}} named "paymentmethodchange".

Internal Slots

Instances of {{PaymentRequest}} are created with the [=internal slots=] in the following table:

Internal Slot	Description (non-normative)
[[\serializedMethodData]]	The methodData supplied to the constructor, but represented as tuples containing supported methods and a string or null for data (instead of the original object form).
[[\serializedModifierData]]	A list containing the serialized string form of each {{PaymentDetailsModifier/data}} member for each corresponding item in the sequence {{PaymentRequest/[[details]]}}.{{PaymentDetailsBase/modifier}}, or null if no such member was present.
[[\details]]	The current {{PaymentDetailsBase}} for the payment request initially supplied to the constructor and then updated with calls to {{PaymentRequestUpdateEvent/updateWith()}}. Note that all {{PaymentDetailsModifier/data}} members of {{PaymentDetailsModifier}} instances contained in the {{PaymentDetailsBase/modifiers}} member will be removed, as they are instead stored in serialized form in the {{PaymentRequest/[[serializedModifierData]]}} [=internal slot=].
[[\options]]	The {{PaymentOptions}} supplied to the constructor.
[[\state]]	The current state of the payment request, which transitions from: "created" The payment request is constructed and has not been presented to the user. "interactive" The payment request is being presented to the user. "closed" The payment request completed. The [=PaymentRequest/state=] transitions are illustrated in the figure below:
[[\updating]]	True if there is a pending {{PaymentRequestUpdateEvent/updateWith()}} call to update the payment request and false otherwise.
[[\acceptPromise]]	The pending {{Promise}} created during {{PaymentRequest/show()}} that will be resolved if the user accepts the payment request.
[[\response]]	Null, or the {{PaymentResponse}} instantiated by this {{PaymentRequest}}.
[[\handler]]	The Payment Handler associated with this {{PaymentRequest}}. Initialized to `null`.

Validity checkers

A [=JavaScript string=] is a valid decimal monetary value if it consists of the following [=code points=] in the given order:

1. Optionally, a single U+002D (-), to indicate that the amount is negative.
2. One or more [=code points=] in the range U+0030 (0) to U+0039 (9).
3. Optionally, a single U+002E (.) followed by one or more [=code points=] in the range U+0030 (0) to U+0039 (9).

^-?[0-9]+(\.[0-9]+)?$

To check and canonicalize amount given a {{PaymentCurrencyAmount}} |amount|, run the following steps:

1. If the result of IsWellFormedCurrencyCode(|amount|.{{PaymentCurrencyAmount/currency}}) is false, then throw a {{RangeError}} exception, optionally informing the developer that the currency is invalid.
2. If |amount|.{{PaymentCurrencyAmount/value}} is not a valid decimal monetary value, throw a {{TypeError}}, optionally informing the developer that the currency is invalid.
3. Set |amount|.{{PaymentCurrencyAmount/currency}} to the result of ASCII uppercase |amount|.{{PaymentCurrencyAmount/currency}}.

To check and canonicalize total amount given a {{PaymentCurrencyAmount}} |amount:PaymentCurrencyAmount|, run the following steps:

1. Check and canonicalize amount |amount|. Rethrow any exceptions.
2. If the first code point of |amount|.{{PaymentCurrencyAmount/value}} is U+002D (-), then throw a {{TypeError}} optionally informing the developer that a total's value can't be a negative number.

PaymentDetailsBase dictionary

        dictionary PaymentDetailsBase {
          sequence<PaymentItem> displayItems;
          sequence<PaymentShippingOption> shippingOptions;
          sequence<PaymentDetailsModifier> modifiers;
        };
        

displayItems member

A sequence of {{PaymentItem}} dictionaries contains line items for the payment request that the user agent MAY display.

shippingOptions member

A sequence containing the different shipping options for the user to choose from.

If an item in the sequence has the {{PaymentShippingOption/selected}} member set to true, then this is the shipping option that will be used by default and {{PaymentRequest/shippingOption}} will be set to the {{PaymentShippingOption/id}} of this option without running the shipping option changed algorithm. If more than one item in the sequence has {{PaymentShippingOption/selected}} set to true, then the user agent selects the last one in the sequence.

The {{PaymentDetailsBase/shippingOptions}} member is only used if the {{PaymentRequest}} was constructed with {{PaymentOptions}} and {{PaymentOptions/requestShipping}} set to true.

modifiers member

A sequence of {{PaymentDetailsModifier}} dictionaries that contains modifiers for particular payment method identifiers. For example, it allows you to adjust the total amount based on payment method.

PaymentDetailsInit dictionary

          dictionary PaymentDetailsInit : PaymentDetailsBase {
            DOMString id;
            required PaymentItem total;
          };
        

In addition to the members inherited from the {{PaymentDetailsBase}} dictionary, the following members are part of the PaymentDetailsInit dictionary:

id member

A free-form identifier for this payment request.

total member

A {{PaymentItem}} containing a non-negative total amount for the payment request.

PaymentDetailsUpdate dictionary

          dictionary PaymentDetailsUpdate : PaymentDetailsBase {
            DOMString error;
            PaymentItem total;
            AddressErrors shippingAddressErrors;
            PayerErrors payerErrors;
            object paymentMethodErrors;
          };
        

The {{PaymentDetailsUpdate}} dictionary is used to update the payment request using {{PaymentRequestUpdateEvent/updateWith()}}.

In addition to the members inherited from the {{PaymentDetailsBase}} dictionary, the following members are part of the {{PaymentDetailsUpdate}} dictionary:

error member

A human-readable string that explains why goods cannot be shipped to the chosen shipping address, or any other reason why no shipping options are available. When the payment request is updated using {{PaymentRequestUpdateEvent/updateWith()}}, the {{PaymentDetailsUpdate}} can contain a message in the {{PaymentDetailsUpdate/error}} member that will be displayed to the user if the {{PaymentDetailsUpdate}} indicates that there are no valid {{PaymentDetailsBase/shippingOptions}} (and the {{PaymentRequest}} was constructed with the {{PaymentOptions/requestShipping}} option set to true).

total member

A {{PaymentItem}} containing a non-negative {{PaymentItem/amount}}.

Algorithms in this specification that accept a {{PaymentDetailsUpdate}} dictionary will throw if the {{PaymentDetailsUpdate/total}}.{{PaymentItem/amount}}.{{PaymentCurrencyAmount/value}} is a negative number.

shippingAddressErrors member

Represents validation errors with the shipping address that is associated with the potential event target.

payerErrors member

Validation errors related to the payer details.

paymentMethodErrors member

Payment method specific errors.

retry() method

The retry(|errorFields:PaymentValidationErrors|) method MUST act as follows:

1. Let |response:PaymentResponse| be [=this=].
2. Let |request:PaymentRequest| be |response|.{{PaymentResponse/[[request]]}}.
3. Let |document:Document| be |request|'s relevant global object's associated `Document`.
4. If |document| is not [=Document/fully active=], then return a promise rejected with an {{"InvalidStateError"}} {{DOMException}}.
5. If |response|.{{PaymentResponse/[[complete]]}} is true, return a promise rejected with an {{"InvalidStateError"}} {{DOMException}}.
6. If |response|.{{PaymentResponse/[[retryPromise]]}} is not null, return a promise rejected with an {{"InvalidStateError"}} {{DOMException}}.
7. Set |request|.{{PaymentRequest/[[state]]}} to "[=PaymentRequest/interactive=]".
8. Let |retryPromise:Promise| be a new promise.
9. Set |response|.{{PaymentResponse/[[retryPromise]]}} to |retryPromise|.
10. If |errorFields:PaymentValidationErrors| was passed:
    1. Optionally, show a warning in the developer console if any of the following are true:
       1. |request|.{{PaymentRequest/[[options]]}}.{{PaymentOptions/requestPayerName}} is false, and |errorFields|.{{PaymentValidationErrors/payer}}.{{PayerErrors/name}} is present.
       2. |request|.{{PaymentRequest/[[options]]}}.{{PaymentOptions/requestPayerEmail}} is false, and |errorFields|.{{PaymentValidationErrors/payer}}.{{PayerErrors/email}} is present.
       3. |request|.{{PaymentRequest/[[options]]}}.{{PaymentOptions/requestPayerPhone}} is false, and |errorFields|.{{PaymentValidationErrors/payer}}.{{PayerErrors/phone}} is present.
       4. |request|.{{PaymentRequest/[[options]]}}.{{PaymentOptions/requestShipping}} is false, and |errorFields|.{{PaymentValidationErrors/shippingAddress}} is present.
    2. If |errorFields:PaymentValidationErrors|.{{PaymentValidationErrors/paymentMethod}} member was passed, and if required by the specification that defines |response|.{{PaymentResponse/methodName}}, then [=converted to an IDL value|convert=] |errorFields|'s {{PaymentValidationErrors/paymentMethod}} member to an IDL value of the type specified there. Otherwise, [=converted to an IDL value|convert=] to {{object}}.
    3. Set |request|'s payment-relevant browsing context's payment request is showing boolean to false.
    4. If conversion results in a exception |error|:
       1. Reject |retryPromise| with |error|.
       2. Set user agent's payment request is showing boolean to false.
       3. Return.
    5. By matching the members of |errorFields| to input fields in the user agent's UI, indicate to the end user that something is wrong with the data of the payment response. For example, a user agent might draw the user's attention to the erroneous |errorFields| in the browser's UI and display the value of each field in a manner that helps the user fix each error. Similarly, if the {{PaymentValidationErrors/error}} member is passed, present the error in the user agent's UI. In the case where the value of a member is the empty string, the user agent MAY substitute a value with a suitable error message.
11. Otherwise, if |errorFields| was not passed, signal to the end user to attempt to retry the payment. Re-enable any UI element that affords the end user the ability to retry accepting the payment request.
12. If |document| stops being [=Document/fully active=] while the user interface is being shown, or no longer is by the time this step is reached, then:
    1. Close down the user interface.
    2. Set |request|.{{PaymentRequest/[[state]]}} to "[=PaymentRequest/closed=]".
    3. Set |request|'s payment-relevant browsing context's payment request is showing boolean to false.
    4. Queue a task on the user interaction task source to [=reject=] |retryPromise| with an {{"AbortError"}} {{DOMException}}.
13. Finally, when |retryPromise| settles, set |response|.{{PaymentResponse/[[retryPromise]]}} to null.
14. Return |retryPromise|.

    The |retryPromise| will later be resolved by the user accepts the payment request algorithm, or rejected by the user aborts the payment request algorithm, or abort the update, or the payment handler indicates an internal error algorithm.

            dictionary PaymentValidationErrors {
              PayerErrors payer;
              AddressErrors shippingAddress;
              DOMString error;
              object paymentMethod;
            };
          

          dictionary PayerErrors {
            DOMString email;
            DOMString name;
            DOMString phone;
          };
          

            const payer = {
              email: "The domain is invalid.",
              phone: "Unknown country code.",
              name: "Not in database.",
            };
            await response.retry({ payer });
          

methodName attribute

The payment method identifier for the payment method that the user selected to fulfill the transaction.

details attribute

An {{object}} or dictionary generated by a payment method that a merchant can use to process or validate a transaction (depending on the payment method).

shippingAddress attribute

If the {{PaymentOptions/requestShipping}} member was set to true in the {{PaymentOptions}} passed to the {{PaymentRequest}} constructor, then {{PaymentRequest/shippingAddress}} will be the full and final [=shipping address=] chosen by the user.

shippingOption attribute

If the {{PaymentOptions/requestShipping}} member was set to true in the {{PaymentOptions}} passed to the {{PaymentRequest}} constructor, then {{PaymentRequest/shippingOption}} will be the {{PaymentShippingOption/id}} attribute of the selected shipping option.

payerName attribute

If the {{PaymentOptions/requestPayerName}} member was set to true in the {{PaymentOptions}} passed to the {{PaymentRequest}} constructor, then {{PaymentResponse/payerName}} will be the name provided by the user.

payerEmail attribute

If the {{PaymentOptions/requestPayerEmail}} member was set to true in the {{PaymentOptions}} passed to the {{PaymentRequest}} constructor, then {{PaymentResponse/payerEmail}} will be the email address chosen by the user.

payerPhone attribute

If the {{PaymentOptions/requestPayerPhone}} member was set to true in the {{PaymentOptions}} passed to the {{PaymentRequest}} constructor, then {{PaymentResponse/payerPhone}} will be the phone number chosen by the user.

requestId attribute

The corresponding payment request {{PaymentRequest/id}} that spawned this payment response.

complete() method

The {{PaymentResponse/complete()}} method is called after the user has accepted the payment request and the {{PaymentRequest/[[acceptPromise]]}} has been resolved. Calling the {{PaymentResponse/complete()}} method tells the user agent that the payment interaction is over (and SHOULD cause any remaining user interface to be closed).

After the payment request has been accepted and the {{PaymentResponse}} returned to the caller, but before the caller calls {{PaymentResponse/complete()}}, the payment request user interface remains in a pending state. At this point the user interface SHOULD NOT offer a cancel command because acceptance of the payment request has been returned. However, if something goes wrong and the developer never calls {{PaymentResponse/complete()}} then the user interface is blocked.

For this reason, implementations MAY impose a timeout for developers to call {{PaymentResponse/complete()}}. If the timeout expires then the implementation will behave as if {{PaymentResponse/complete()}} was called with no arguments.

The {{PaymentResponse/complete()}} method MUST act as follows:

1. Let |response:PaymentResponse| be [=this=].
2. If |response|.{{PaymentResponse/[[complete]]}} is true, return a promise rejected with an {{"InvalidStateError"}} {{DOMException}}.
3. If |response|.{{PaymentResponse/[[retryPromise]]}} is not null, return a promise rejected with an {{"InvalidStateError"}} {{DOMException}}.
4. Let |promise:Promise| be a new promise.
5. Let |serializedData| be the result of [=serialize a JavaScript value to a JSON string|serialize=] |details|.{{PaymentCompleteDetails/data}} into a JSON string.
6. If serializing [=exception/throws=] an exception, return a promise rejected with that exception.
7. If required by the specification that defines the |response|.{{PaymentResponse/methodName}}:
   1. Let |json| be the result of calling `JSON`'s {{JSON/parse()}} with |serializedData|.
   2. Let |idl| be the result of [=converted to an IDL value|converting=] |json| to an IDL value of the type specified by the specification that defines the |response|.{{PaymentResponse/methodName}}.
   3. If the conversion to an IDL value [=exception/throws=] an [=exception=], return a promise rejected with that exception.
   4. If required by the specification that defines the |response|.{{PaymentResponse/methodName}}, validate the members of |idl|. If a member's value is invalid, return a promise rejected with a {{TypeError}}.
8. Set |response|.{{PaymentResponse/[[complete]]}} to true.
9. Return |promise| and perform the remaining steps in parallel.
10. If |document| stops being [=Document/fully active=] while the user interface is being shown, or no longer is by the time this step is reached, then:
    1. Close down the user interface.
    2. Set |request|'s payment-relevant browsing context's payment request is showing boolean to false.
    3. Queue a task on the user interaction task source to [=reject=] |promise| with an {{"AbortError"}} {{DOMException}}.
11. Otherwise:
    1. Close down any remaining user interface. The user agent MAY use the value |result| and |serializedData| to influence the user experience.
    2. Set |request|'s payment-relevant browsing context's payment request is showing boolean to false.
    3. Resolve |promise| with undefined.

onpayerdetailchange attribute

Allows a developer to handle "payerdetailchange" events.

Internal Slots

Instances of {{PaymentResponse}} are created with the [=internal slots=] in the following table:

AddressErrors dictionary

          dictionary AddressErrors {
            DOMString addressLine;
            DOMString city;
            DOMString country;
            DOMString dependentLocality;
            DOMString organization;
            DOMString phone;
            DOMString postalCode;
            DOMString recipient;
            DOMString region;
            DOMString sortingCode;
          };
        

The members of the {{AddressErrors}} dictionary represent validation errors with specific parts of a [=physical address=]. Each dictionary member has a dual function: firstly, its presence denotes that a particular part of an address is suffering from a validation error. Secondly, the string value allows the developer to describe the validation error (and possibly how the end user can fix the error).

Developers need to be aware that users might not have the ability to fix certain parts of an address. As such, they need to be mindful not to ask the user to fix things they might not have control over.

addressLine member

Denotes that the [=physical address/address line=] has a validation error. In the user agent's UI, this member corresponds to the input field that provided the {{ContactAddress}}'s {{ContactAddress/addressLine}} attribute's value.

city member

Denotes that the [=physical address/city=] has a validation error. In the user agent's UI, this member corresponds to the input field that provided the {{ContactAddress}}'s {{ContactAddress/city}} attribute's value.

country member

Denotes that the [=physical address/country=] has a validation error. In the user agent's UI, this member corresponds to the input field that provided the {{ContactAddress}}'s {{ContactAddress/country}} attribute's value.

dependentLocality member

Denotes that the [=physical address/dependent locality=] has a validation error. In the user agent's UI, this member corresponds to the input field that provided the {{ContactAddress}}'s {{ContactAddress/dependentLocality}} attribute's value.

organization member

Denotes that the [=physical address/organization=] has a validation error. In the user agent's UI, this member corresponds to the input field that provided the {{ContactAddress}}'s {{ContactAddress/organization}} attribute's value.

phone member

Denotes that the [=physical address/phone number=] has a validation error. In the user agent's UI, this member corresponds to the input field that provided the {{ContactAddress}}'s {{ContactAddress/phone}} attribute's value.

postalCode member

Denotes that the [=physical address/postal code=] has a validation error. In the user agent's UI, this member corresponds to the input field that provided the {{ContactAddress}}'s {{ContactAddress/postalCode}} attribute's value.

recipient member

Denotes that the [=physical address/recipient=] has a validation error. In the user agent's UI, this member corresponds to the input field that provided the {{ContactAddress}}'s {{ContactAddress/addressLine}} attribute's value.

region member

Denotes that the [=physical address/region=] has a validation error. In the user agent's UI, this member corresponds to the input field that provided the {{ContactAddress}}'s {{ContactAddress/region}} attribute's value.

sortingCode member

The [=physical address/sorting code=] has a validation error. In the user agent's UI, this member corresponds to the input field that provided the {{ContactAddress}}'s {{ContactAddress/sortingCode}} attribute's value.

Summary

PaymentMethodChangeEvent interface

          [SecureContext, Exposed=Window]
          interface PaymentMethodChangeEvent : PaymentRequestUpdateEvent {
            constructor(DOMString type, optional PaymentMethodChangeEventInit eventInitDict = {});
            readonly attribute DOMString methodName;
            readonly attribute object? methodDetails;
          };
        

            dictionary PaymentMethodChangeEventInit : PaymentRequestUpdateEventInit {
              DOMString methodName = "";
              object? methodDetails = null;
            };
          

PaymentRequestUpdateEvent interface

          [SecureContext, Exposed=Window]
          interface PaymentRequestUpdateEvent : Event {
            constructor(DOMString type, optional PaymentRequestUpdateEventInit eventInitDict = {});
            undefined updateWith(Promise<PaymentDetailsUpdate> detailsPromise);
          };
        

The {{PaymentRequestUpdateEvent}} enables developers to update the details of the payment request in response to a user interaction.

            dictionary PaymentRequestUpdateEventInit : EventInit {};
          

Can make payment algorithm

The can make payment algorithm checks if the user agent supports making payment with the payment methods with which the {{PaymentRequest}} was constructed.

1. Let |request:PaymentRequest| be the {{PaymentRequest}} object on which the method was called.
2. If |request|.{{PaymentRequest/[[state]]}} is not "[=PaymentRequest/created=]", then return a promise rejected with an {{"InvalidStateError"}} {{DOMException}}.
3. Let |document| be |request|'s [=relevant global object=]'s [=associated `Document`=].
4. If |document| is not [=Document/fully active=], then return a promise rejected with an {{"InvalidStateError"}} {{DOMException}}.
5. Optionally, at the top-level browsing context's discretion, return a promise rejected with a {{"NotAllowedError"}} {{DOMException}}.

   This allows user agents to apply heuristics to detect and prevent abuse of the calling method for fingerprinting purposes, such as creating {{PaymentRequest}} objects with a variety of supported payment methods and triggering the can make payment algorithm on them one after the other. For example, a user agent may restrict the number of successful calls that can be made based on the top-level browsing context or the time period in which those calls were made.

6. Let |hasHandlerPromise:Promise| be a new promise.
7. Return |hasHandlerPromise|, and perform the remaining steps in parallel.
8. For each |paymentMethod| tuple in |request|. {{PaymentRequest/[[serializedMethodData]]}}:
   1. Let |identifier| be the first element in the |paymentMethod| tuple.
   2. If the user agent has a payment handler that supports handling payment requests for |identifier|, resolve |hasHandlerPromise| with true and terminate this algorithm.
9. Resolve |hasHandlerPromise| with false.

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:PaymentRequest| be the {{PaymentRequest}} object that the user is interacting with.
2. Queue a task on the user interaction task source to run the following steps:

   1. The |redactList| limits the amount of personal information about the recipient that the API shares with the merchant.

      For merchants, the resulting {{ContactAddress}} 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.

   2. Let |redactList:list| be the empty list. Set |redactList| to « "organization", "phone", "recipient", "addressLine" ».
   3. Let |address:ContactAddress| be the result of running the steps to [=ContactsManager/create a contactaddress from user-provided input=] with |redactList|.
   4. Set |request|.{{PaymentRequest/shippingAddress}} to |address|.
   5. Run the PaymentRequest updated algorithm with |request| and "shippingaddresschange".

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:PaymentRequest| be the {{PaymentRequest}} object that the user is interacting with.
2. Queue a task on the user interaction task source to run the following steps:
   1. Set the {{PaymentRequest/shippingOption}} attribute on |request| to the id string of the {{PaymentShippingOption}} provided by the user.
   2. Run the PaymentRequest updated algorithm with |request| and "shippingoptionchange".

Payment method changed algorithm

A payment handler MAY run the payment method changed algorithm when the user changes payment method with |methodDetails|, which is a dictionary or an {{object}} or null, and a |methodName|, which is a DOMString that represents the payment method identifier of the payment handler the user is interacting with.

When the user selects or changes a payment method (e.g., a credit card), the {{PaymentMethodChangeEvent}} includes redacted billing address information for the purpose of performing tax calculations. Redacted attributes include, but are not limited to, [=physical address/address line=], [=physical address/dependent locality=], [=physical address/organization=], [=physical address/phone number=], and [=physical address/recipient=].

1. Let |request:PaymentRequest| be the {{PaymentRequest}} object that the user is interacting with.
2. Queue a task on the user interaction task source to run the following steps:
   1. Assert: |request|.{{PaymentRequest/[[updating]]}} is false. Only one update can take place at a time.
   2. Assert: |request|.{{PaymentRequest/[[state]]}} is "[=PaymentRequest/interactive=]".
   3. Fire an event named "paymentmethodchange" at |request| using {{PaymentMethodChangeEvent}}, with its {{PaymentMethodChangeEvent/methodName}} attribute initialized to |methodName|, and its {{PaymentMethodChangeEvent/methodDetails}} attribute initialized to |methodDetails|.

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. Assert: |request|.{{PaymentRequest/[[updating]]}} is false. Only one update can take place at a time.
2. Assert: |request|.{{PaymentRequest/[[state]]}} is "[=PaymentRequest/interactive=]".
3. Let |event:PaymentRequestUpdateEvent| be the result of creating an event using the {{PaymentRequestUpdateEvent}} interface.
4. Initialize |event|'s {{Event/type}} attribute to |name|.
5. Dispatch |event| at |request|.
6. If |event|.{{PaymentRequestUpdateEvent/[[waitForUpdate]]}} is true, disable any part of the user interface that could cause another update event to be fired.
7. Otherwise, set |event|.{{PaymentRequestUpdateEvent/[[waitForUpdate]]}} to true.

Payer detail changed algorithm

The user agent MUST run the payer detail changed algorithm when the user changes the |payer name|, or the |payer email|, or the |payer phone| in the user interface:

1. Let |request:PaymentRequest| be the {{PaymentRequest}} object that the user is interacting with.
2. If |request|.{{PaymentRequest/[[response]]}} is null, return.
3. Let |response:PaymentResponse| be |request|.{{PaymentRequest/[[response]]}}.
4. Queue a task on the user interaction task source to run the following steps:
   1. Assert: |request|.{{PaymentRequest/[[updating]]}} is false.
   2. Assert: |request|.{{PaymentRequest/[[state]]}} is "[=PaymentRequest/interactive=]".
   3. Let |options:PaymentOptions| be |request|.{{PaymentRequest/[[options]]}}.
   4. If |payer name| changed and |options|.{{PaymentOptions/requestPayerName}} is true:
      1. Set |response|.{{PaymentResponse/payerName}} attribute to |payer name|.
   5. If |payer email| changed and |options|.{{PaymentOptions/requestPayerEmail}} is true:
      1. Set |response|.{{PaymentResponse/payerEmail}} to |payer email|.
   6. If |payer phone| changed and |options|.{{PaymentOptions/requestPayerPhone}} is true:
      1. Set |response|.{{PaymentResponse/payerPhone}} to |payer phone|.
   7. Let |event:PaymentRequestUpdateEvent| be the result of creating an event using {{PaymentRequestUpdateEvent}}.
   8. Initialize |event|'s {{Event/type}} attribute to "payerdetailchange".
   9. Dispatch |event| at |response|.
   10. If |event|.{{PaymentRequestUpdateEvent/[[waitForUpdate]]}} is true, disable any part of the user interface that could cause another change to the payer details to be fired.
   11. Otherwise, set |event|.{{PaymentRequestUpdateEvent/[[waitForUpdate]]}} to true.

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:PaymentRequest| be the {{PaymentRequest}} object that the user is interacting with.
2. If the |request|.{{PaymentRequest/[[updating]]}} is true, then terminate this algorithm and take no further action. The user agent user interface SHOULD ensure that this never occurs.
3. If |request|.{{PaymentRequest/[[state]]}} is not "[=PaymentRequest/interactive=]", then terminate this algorithm and take no further action. The user agent user interface SHOULD ensure that this never occurs.
4. If the {{PaymentOptions/requestShipping}} value of |request|.{{PaymentRequest/[[options]]}} is true, then if the {{PaymentRequest/shippingAddress}} attribute of |request| is null or if the {{PaymentRequest/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. Let |isRetry:boolean| be true if |request|.{{PaymentRequest/[[response]]}} is not null, false otherwise.
6. Let |response:PaymentResponse| be |request|.{{PaymentRequest/[[response]]}} if |isRetry| is true, or a new {{PaymentResponse}} otherwise.
7. If |isRetry| is false, initialize the newly created |response|:
   1. Set |response|.{{PaymentResponse/[[request]]}} to |request|.
   2. Set |response|.{{PaymentResponse/[[retryPromise]]}} to null.
   3. Set |response|.{{PaymentResponse/[[complete]]}} to false.
   4. Set the {{PaymentResponse/requestId}} attribute value of |response| to the value of |request|.{{PaymentRequest/[[details]]}}.{{PaymentDetailsInit/id}}.
   5. Set |request|.{{PaymentRequest/[[response]]}} to |response|.
8. Let |handler:payment handler| be |request|.{{PaymentRequest/[[handler]]}}.
9. Set the {{PaymentResponse/methodName}} attribute value of |response| to the payment method identifier of |handler|.
10. Set the {{PaymentResponse/details}} attribute value of |response| to an object resulting from running the |handler|'s [=Payment Handler/steps to respond to a payment request=].
11. If the {{PaymentOptions/requestShipping}} value of |request|.{{PaymentRequest/[[options]]}} is false, then set the {{PaymentResponse/shippingAddress}} attribute value of |response| to null. Otherwise:
    1. Let |shippingAddress:ContactAddress| be the result of [=ContactsManager/create a contactaddress from user-provided input=]
    2. Set the {{PaymentResponse/shippingAddress}} attribute value of |response| to |shippingAddress|.
    3. Set the {{PaymentResponse/shippingAddress}} attribute value of |request| to |shippingAddress|.
12. If the {{PaymentOptions/requestShipping}} value of |request|.{{PaymentRequest/[[options]]}} is true, then set the {{PaymentResponse/shippingOption}} attribute of |response| to the value of the {{PaymentResponse/shippingOption}} attribute of |request|. Otherwise, set it to null.
13. If the {{PaymentOptions/requestPayerName}} value of |request|.{{PaymentRequest/[[options]]}} is true, then set the {{PaymentResponse/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.
14. If the {{PaymentOptions/requestPayerEmail}} value of |request|.{{PaymentRequest/[[options]]}} is true, then set the {{PaymentResponse/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.
15. If the {{PaymentOptions/requestPayerPhone}} value of |request|.{{PaymentRequest/[[options]]}} is true, then set the {{PaymentResponse/payerPhone}} attribute of |response| to the payer's phone number provided by the user, or to null if none was provided. When setting the {{PaymentResponse/payerPhone}} value, the user agent SHOULD format the phone number to adhere to [[E.164]].
16. Set |request|.{{PaymentRequest/[[state]]}} to "[=PaymentRequest/closed=]".
17. If |isRetry| is true, resolve |response|.{{PaymentResponse/[[retryPromise]]}} with undefined. Otherwise, resolve |request|.{{PaymentRequest/[[acceptPromise]]}} with |response|.

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:PaymentRequest| be the {{PaymentRequest}} object that the user is interacting with.
2. If |request|.{{PaymentRequest/[[state]]}} is not "[=PaymentRequest/interactive=]", then terminate this algorithm and take no further action. The user agent user interface SHOULD ensure that this never occurs.
3. Set |request|.{{PaymentRequest/[[state]]}} to "[=PaymentRequest/closed=]".
4. Set |request|'s payment-relevant browsing context's payment request is showing boolean to false.
5. Let |error| be an {{"AbortError"}} {{DOMException}}.
6. Let |response:PaymentResponse| be |request|.{{PaymentRequest/[[response]]}}.
7. If |response| is not null:
   1. Set |response|.{{PaymentResponse/[[complete]]}} to true.
   2. Assert: |response|.{{PaymentResponse/[[retryPromise]]}} is not null.
   3. Reject |response|.{{PaymentResponse/[[retryPromise]]}} with |error|.
8. Otherwise, reject |request|.{{PaymentRequest/[[acceptPromise]]}} with |error|.
9. Abort the current user interaction and close down any remaining user interface.

Payment handler indicates an internal error algorithm

The payment handler indicates an internal error algorithm runs when the payment handler that the user has selected encounters an internal error that prevents it from completing the payment. This can occur due to reasons such as the operating system terminating the payment handler (e.g., due to memory pressure), or the payment handler itself encountering an unrecoverable error.

1. Queue a task on the user interaction task source to perform the following steps:
   1. Let |request:PaymentRequest| be the {{PaymentRequest}} object that the user is interacting with.
   2. If |request|.{{PaymentRequest/[[state]]}} is not "[=PaymentRequest/interactive=]", then terminate this algorithm and take no further action.
   3. Let |error| be an {{"OperationError"}} {{DOMException}}.
   4. Set |request|.{{PaymentRequest/[[state]]}} to "[=PaymentRequest/closed=]".
   5. Set |request|'s payment-relevant browsing context's payment request is showing boolean to false.
   6. Let |response:PaymentResponse| be |request|.{{PaymentRequest/[[response]]}}.
   7. If |response| is not null:
      1. Set |response|.{{PaymentResponse/[[complete]]}} to true.
      2. Assert: |response|.{{PaymentResponse/[[retryPromise]]}} is not null.
      3. Reject |response|.{{PaymentResponse/[[retryPromise]]}} with |error|.
   8. Otherwise, reject |request|.{{PaymentRequest/[[acceptPromise]]}} with |error|.
   9. Optionally, show a generic error message to the user indicating that the payment could not be completed.
   10. Optionally, log detailed error information to the developer console for debugging purposes.
   11. Abort the current user interaction and close down any remaining user interface.

The {{"OperationError"}} type allows merchants to distinguish payment handler errors from user cancellation (which uses {{"AbortError"}}).

Update a PaymentRequest's details algorithm

The update a PaymentRequest's details algorithm takes a {{PaymentDetailsUpdate}} |detailsPromise|, a {{PaymentRequest}} |request|, and |pmi| that is either a DOMString or null (a payment method identifier). The steps are conditional on the |detailsPromise| settling. If |detailsPromise| never settles then the payment request is blocked. The user agent SHOULD provide the user with a means to abort a payment request. Implementations MAY choose to implement a timeout for pending updates if |detailsPromise| doesn't settle in a reasonable amount of time.

In the case where a timeout occurs, or the user manually aborts, or the payment handler decides to abort this particular payment, the user agent MUST run the user aborts the payment request algorithm.

1. Set |request|.{{PaymentRequest/[[updating]]}} to true.
2. In parallel, disable the user interface that allows the user to accept the payment request. This is to ensure that the payment is not accepted until the user interface is updated with any new details.
3. Upon rejection of |detailsPromise|:
   1. Abort the update with |request| and an {{"AbortError"}} {{DOMException}}.
4. Upon fulfillment of |detailsPromise| with value |value|:
   1. Let |details:PaymentDetailsUpdate| be the result of [=converted to an IDL value|converting=] |value| to a {{PaymentDetailsUpdate}} dictionary. If this [=exception/throw=] an exception, abort the update with |request| and with the thrown exception.
   2. Let |serializedModifierData| be an empty list.
   3. Let |selectedShippingOption| be null.
   4. Let |shippingOptions| be an empty sequence<{{PaymentShippingOption}}>.
   5. Validate and canonicalize the details:
      1. If the {{PaymentDetailsUpdate/total}} member of |details| is present, then:
         1. Check and canonicalize total amount |details|.{{PaymentDetailsUpdate/total}}.{{PaymentItem/amount}}. If an exception is thrown, then abort the update with |request| and that exception.
      2. If the {{PaymentDetailsBase/displayItems}} member of |details| is present, then for each |item| in |details|.{{PaymentDetailsBase/displayItems}}:
         1. Check and canonicalize amount |item|.{{PaymentItem/amount}}. If an exception is thrown, then abort the update with |request| and that exception.
      3. If the {{PaymentDetailsBase/shippingOptions}} member of |details| is present, and |request|.{{PaymentRequest/[[options]]}}.{{PaymentOptions/requestShipping}} is true, then:
         1. Let |seenIDs| be an empty set.
         2. For each |option| in |details|.{{PaymentDetailsBase/shippingOptions}}:
            1. Check and canonicalize amount |option|.{{PaymentShippingOption/amount}}. If an exception is thrown, then abort the update with |request| and that exception.
            2. If |seenIDs|[|option|.{{PaymentShippingOption/id}] exists, then abort the update with |request| and a {{TypeError}}.
            3. Append |option|.{{PaymentShippingOption/id}} to |seenIDs|.
            4. Append |option| to |shippingOptions|.
            5. If |option|.{{PaymentShippingOption/selected}} is true, then set |selectedShippingOption| to |option|.{{PaymentShippingOption/id}}.
      4. If the {{PaymentDetailsBase/modifiers}} member of |details| is present, then:
         1. Let |modifiers| be the sequence |details|.{{PaymentDetailsBase/modifiers}}.
         2. Let |serializedModifierData| be an empty list.
         3. For each {{PaymentDetailsModifier}} |modifier| in |modifiers|:
            1. Run the steps to validate a payment method identifier with |modifier|.{{PaymentDetailsModifier/supportedMethods}}. If it returns false, then abort the update with |request| and a {{RangeError}} exception. Optionally, inform the developer that the payment method identifier is invalid.
            2. If the {{PaymentDetailsModifier/total}} member of |modifier| is present, then:
               1. Check and canonicalize total amount |modifier|.{{PaymentDetailsModifier/total}}.{{PaymentItem/amount}}. If an exception is thrown, then abort the update with |request| and that exception.
            3. If the {{PaymentDetailsModifier/additionalDisplayItems}} member of |modifier| is present, then for each {{PaymentItem}} |item| in |modifier|.{{PaymentDetailsModifier/additionalDisplayItems}}:
               1. Check and canonicalize amount |item|.{{PaymentItem/amount}}. If an exception is thrown, then abort the update with |request| and that exception.
            4. If the {{PaymentDetailsModifier/data}} member of |modifier| is missing, let |serializedData| be null. Otherwise, let |serializedData| be the result of [=serialize a JavaScript value to a JSON string|serialize=] |modifier|.{{PaymentDetailsModifier/data}} into a JSON string. If it throws an exception, then abort the update with |request| and that exception.
            5. Add |serializedData| to |serializedModifierData|.
            6. Remove the {{PaymentDetailsModifier/data}} member of |modifier|, if it is present.
   6. If the {{PaymentDetailsUpdate/paymentMethodErrors}} member is present and |identifier| is not null:
      1. If required by the specification that defines the |pmi|, then [=converted to an IDL value|convert=] {{PaymentDetailsUpdate/paymentMethodErrors}} to an IDL value.
      2. If conversion results in a exception |error|, abort the update with |error|.
      3. The payment handler SHOULD display an error for each relevant erroneous field of {{PaymentDetailsUpdate/paymentMethodErrors}}.
   7. Update the {{PaymentRequest}} using the new details:
      1. If the {{PaymentDetailsUpdate/total}} member of |details| is present, then:
         1. Set |request|.{{PaymentRequest/[[details]]}}.{{PaymentDetailsInit/total}} to |details|.{{PaymentDetailsUpdate/total}}.
      2. If the {{PaymentDetailsBase/displayItems}} member of |details| is present, then:
         1. Set |request|.{{PaymentRequest/[[details]]}}.{{PaymentDetailsBase/displayItems}} to |details|.{{PaymentDetailsBase/displayItems}}.
      3. If the {{PaymentDetailsBase/shippingOptions}} member of |details| is present, and |request|.{{PaymentRequest/[[options]]}}.{{PaymentOptions/requestShipping}} is true, then:
         1. Set |request|.{{PaymentRequest/[[details]]}}.{{PaymentDetailsBase/shippingOptions}} to |shippingOptions|.
         2. Set the value of |request|'s {{PaymentRequest/shippingOption}} attribute to |selectedShippingOption|.
      4. If the {{PaymentDetailsBase/modifiers}} member of |details| is present, then:
         1. Set |request|.{{PaymentRequest/[[details]]}}.{{PaymentDetailsBase/modifiers}} to |details|.{{PaymentDetailsBase/modifiers}}.
         2. Set |request|.{{PaymentRequest/[[serializedModifierData]]}} to |serializedModifierData|.

      5. If |request|.{{PaymentRequest/[[options]]}}.{{PaymentOptions/requestShipping}} is true, and |request|.{{PaymentRequest/[[details]]}}.{{PaymentDetailsBase/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 {{PaymentRequest/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 {{PaymentDetailsUpdate/error}} member of |details|, if it is present, to give more information about why there are no valid shipping options for that address.

         Further, if |details|["{{PaymentDetailsUpdate/shippingAddressErrors}}"] member is present, the user agent SHOULD display an error specifically for each erroneous field of the shipping address. This is done by matching each present member of the {{AddressErrors}} to a corresponding input field in the shown user interface.

         Similarly, if |details|["{{payerErrors}}"] member is present and |request|.{{PaymentRequest/[[options]]}}'s {{PaymentOptions/requestPayerName}}, {{PaymentOptions/requestPayerEmail}}, or {{PaymentOptions/requestPayerPhone}} is true, then display an error specifically for each erroneous field.

         Likewise, if |details|.{{PaymentDetailsUpdate/paymentMethodErrors}} is present, then display errors specifically for each erroneous input field for the particular payment method.

5. Set |request|.{{PaymentRequest/[[updating]]}} to false.
6. Update the user interface based on any changed values in |request|. Re-enable user interface elements disabled prior to running this algorithm.

User protections with show() method

To help ensure that users do not inadvertently share sensitive credentials with an origin, this API requires that PaymentRequest's {{PaymentRequest/show()}} method be invoked while the relevant {{Window}} has [=transient activation=] (e.g., via a click or press).

To avoid a confusing user experience, this specification limits the user agent to displaying one at a time via the {{PaymentRequest/show()}} method. In addition, the user agent can limit the rate at which a page can call {{PaymentRequest/show()}}.

Secure contexts

The API defined in this specification is only exposed in a [=secure context=] - see also the [[[secure-contexts]]] specification for more details. In practice, this means that this API is only available over HTTPS. This is to limit the possibility of payment method data (e.g., credit card numbers) being sent in the clear.

Cross-origin payment requests

It is common for merchants and other payees to delegate checkout and other e-commerce activities to payment service providers through an iframe. This API supports payee-authorized cross-origin iframes through [[HTML]]'s [^iframe/allow^] attribute.

Payment handlers have access to both the origin that hosts the iframe and the origin of the iframe content (where the {{PaymentRequest}} initiates).

Encryption of data fields

The {{PaymentRequest}} API does not directly support encryption of data fields. Individual payment methods may choose to include support for encrypted data but it is not mandatory that all payment methods support this.

How user agents match payment handlers

For security reasons, a user agent can limit matching (in {{PaymentRequest/show()}} and {{PaymentRequest/canMakePayment()}}) to payment handlers from the same origin as a URL payment method identifier.

Data usage

Payment method owners establish the privacy policies for how user data collected for the payment method may be used. Payment Request API sets a clear expectation that data will be used for the purposes of completing a transaction, and user experiences associated with this API convey that intention. It is the responsibility of the payee to ensure that any data usage conforms to payment method policies. For any permitted usage beyond completion of the transaction, the payee should clearly communicate that usage to the user.

Exposing user information

The user agent MUST NOT share information about the user with a developer (e.g., the [=shipping address=]) without user consent.

In particular, the {{PaymentMethodData}}'s {{PaymentMethodData/data}} and {{PaymentResponse}}'s {{PaymentResponse/details}} members allow for the arbitrary exchange of data. In light of the wide range of data models used by existing payment methods, prescribing data specifics in this API would limit its usefulness. The {{PaymentResponse/details}} member carries data from the payment handler, whether Web-based (as defined by the [[[web-based-payment-handler]]]) or proprietary. The [=user agent=] MUST NOT support payment handlers unless they include adequate user consent mechanisms (such as awareness of parties to the transaction and mechanisms for demonstrating the intention to share data).

The user agent MUST NOT share the values of the {{PaymentDetailsBase/displayItems}} member or {{PaymentDetailsModifier/additionalDisplayItems}} member for any purpose other than to facilitate completion of the transaction.

The {{PaymentMethodChangeEvent}} enables the payee to update the displayed total based on information specific to a selected payment method. For example, the billing address associated with a selected payment method might affect the tax computation (e.g., VAT), and it is desirable that the user interface accurately display the total before the payer completes the transaction. At the same time, it is desirable to share as little information as possible prior to completion of the payment. Therefore, when a payment method defines the [=Payment Handler/steps for when a user changes payment method=], it is important to minimize the data shared via the {{PaymentMethodChangeEvent}}'s {{PaymentMethodChangeEvent/methodDetails}} attribute. Requirements and approaches for minimizing shared data are likely to vary by payment method and might include:

• Use of a "|redactList|" for physical addresses. The current specification makes use of a "|redactList|" to redact the [=physical address/address line=], [=physical address/organization=], [=physical address/phone number=], and [=physical address/recipient=] from a {{PaymentRequest/shippingAddress}}.
• Support for instructions from the payee identifying specific elements to exclude or include from the payment method response data (returned through {{PaymentResponse}}.|details|). The payee might provide these instructions via PaymentMethodData.|data|, enabling a payment method definition to evolve without requiring changes to the current API.

Where sharing of privacy-sensitive information might not be obvious to users (e.g., when [=payment handler/payment method changed algorithm | changing payment methods =]), it is RECOMMENDED that user agents inform the user of exactly what information is being shared with a merchant.

canMakePayment() protections

The {{PaymentRequest/canMakePayment()}} method provides feature detection for different payment methods. It may become a fingerprinting vector if in the future, a large number of payment methods are available. User agents are expected to protect the user from abuse of the method. For example, user agents can reduce user fingerprinting by:

• Rate-limiting the frequency of calls with different parameters.

For rate-limiting the user agent might look at repeated calls from:

• the same [=host/registrable domain=].
• the [=top-level browsing context=]. Alternatively, the user agent may block access to the API entirely for [=origins=] known to be bad actors.
• the [=origin=] of an [^iframe^] or popup window.

These rate-limiting techniques intend to increase the cost associated with repeated calls, whether it is the cost of managing multiple [=host/registrable domains=] or the user experience friction of opening multiple windows (tabs or pop-ups).

User activation requirement

If the user agent does not require user activation as part of the {{PaymentRequest/show()}} method, some additional security mitigations should be considered. Not requiring user activation increases the risk of spam and click-jacking attacks, by allowing a Payment Request UI to be initiated without the user interacting with the page immediately beforehand.

In order to mitigate spam, the user agent may decide to enforce a user activation requirement after some threshold, for example after the user has already been shown a Payment Request UI without a user activation on the current page. In order to mitigate click-jacking attacks, the user agent may implement a time threshold in which clicks are ignored immediately after a dialog is shown.

Another relevant mitigation exists in step 6 of {{PaymentRequest/show()}}, where the document must be visible in order to initiate the user interaction.