Payment Request API

W3C Candidate Recommendation 30 August 2018

This version:: https://www.w3.org/TR/2018/CR-payment-request-20180830/
Latest published version:: https://www.w3.org/TR/payment-request/
Latest editor's draft:: https://w3c.github.io/payment-request/
Test suite:: https://w3c-test.org/payment-request/
Implementation report:: https://w3c.github.io/test-results/payment-request/all.html
Previous version:: https://www.w3.org/TR/2018/CR-payment-request-20180827/
Editors:: Adrian Bateman (Microsoft Corporation); Zach Koch (Google); Roy McElmurry (Facebook); Domenic Denicola (Google); Marcos Cáceres (Mozilla)
Participate:: GitHub w3c/payment-request; File a bug; Commit history; Pull requests
Can I Use this API?: caniuse.com

Abstract

This specification standardizes an API to allow merchants (i.e. web sites selling physical or digital goods) to utilize one or more payment methods with minimal integration. User agents (e.g., browsers) facilitate the payment flow between merchant and user.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

The working group maintains a list of all bug reports that the group has not yet addressed. Pull requests with proposed specification text for outstanding issues are strongly encouraged.

Note: Sending comments on this document

If you wish to make comments regarding this document, please raise them as GitHub issues. Only send comments by email if you are unable to raise issues on GitHub (see links below). All comments are welcome.

The working group will demonstrate implementation experience by producing an implementation report. The report will show two or more independent implementations passing each mandatory test in the test suite (i.e., each test corresponds to a MUST requirement of the specification).

There has been no change in dependencies on other workings groups during the development of this specification.

This document was published by the Web Payments Working Group as a Candidate Recommendation. This document is intended to become a W3C Recommendation.

GitHub Issues are preferred for discussion of this specification.

W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community. This Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than 31 October 2018.

Please see the Working Group's implementation report.

Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 February 2018 W3C Process Document.

Features at risk

As this specification enters the Candidate Recommendation phase of the W3C standardization process, the working group has identified the following feature(s) as being "at risk" of being removed from the specification. The working group seeks input from implementers, developers, and the general public on whether these features should remain in the specification. If no compelling use cases are received, or if there is limited interest from implementers, these features will be removed from the specification before proceeding along the W3C Recommendation track.

PaymentItem's type member and the PaymentItemType enum (see issue 163).
As the optional detailsPromise argument of the show() method was added late in the Candidate Recommendation phase, the working group is treating it "at risk" and considering moving it to a future version of the specification. This is to avoid this version of the specification from being delayed from progressing along the Recommendation Track, in case we can't get two interoperable implementations in a timely manner. However, if it gets interoperably implemented relatively quickly, the feature will remain in this version of the specification.
Due to PaymentAddress's languageCode attribute only being implemented in one browser (Chrome), the attribute, and all its associated spec text, is at risk.

1. Introduction

This section is non-normative.

This specification describes an API that allows user agents (e.g., browsers) to act as an intermediary between three parties in a transaction:

the payee: the merchant that runs an online store, or other party that requests to be paid.
the payer: the party that makes a purchase at that online store, and who authenticates and authorizes payment as required.
the payment method provider: the party that provides the means (e.g., credit card) that the payer uses to pay, and that is accepted by the payee.

The details of how to fulfill a payment request for a given payment method is an implementation detail of a payment handler. Concretely, each payment handler defines:

Steps to check if a payment can be made:: How a payment handler determines whether it, or the user, can potentially "make a payment" is also an implementation detail of a payment handler. For an example, see the can make payment algorithm of [payment-method-basic-card].
Steps to respond to a payment request:: Steps that return an object or dictionary that a merchant uses to process or validate the transaction. The structure of this object is specific to each payment method. For an example of such an object, see the BasicCardResponse dictionary of [payment-method-basic-card].
Steps for when a user changes payment method (optional): Steps that describe how to handle the user changing payment method or monetary instrument (e.g., from a debit card to a credit card) that results in a dictionary or object or null.

This API also enables web sites to take advantage of more secure payment schemes (e.g., tokenization and system-level authentication) that are not possible with standard JavaScript libraries. This has the potential to reduce liability for the merchant and helps protect sensitive user information.

1.1 Goals

Allow the user agent to act as intermediary between merchants, users, and payment method providers.
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 payment method providers to bring more secure payment transactions to the web.

1.1.1 Out of scope

Create a new payment method
Integrate directly with payment processors

2. Examples of usage

This section is non-normative.

In order to use the API, the developer needs to provide and keep track of a number of key pieces of information. These bits of information are passed to the PaymentRequest constructor as arguments, and subsequently used to update the payment request being displayed to the user. Namely, these bits of information are:

The methodData: A sequence of PaymentMethodDatas that represents the payment methods that the site supports (e.g., "we support card-based payments, but only Visa and MasterCard credit cards.").
The details: The details of the transaction, as a PaymentDetailsInit dictionary. This includes total cost, and optionally a list of goods or services being purchased, for physical goods, and shipping options. Additionally, it can optionally include "modifiers" to how payments are made. For example, "if you pay with a credit card of type X, it incurs a US$3.00 processing fee".
The options: Optionally, a list of things as PaymentOptions that the site needs to deliver the good or service (e.g., for physical goods, the merchant will typically need an physical address to ship to. For digital goods, an email will usually suffice).

Once a PaymentRequest is constructed, it's presented to the end user via the show() method. The show() returns a promise that, once the user confirms request for payment, results in a PaymentResponse.

2.1 The `methodData` argument

The methodData sequence contains PaymentMethodData dictionaries containing the payment method identifiers for the payment methods that the web site accepts and any associated payment method specific data.

Example 1: The `methodData` argument

const methodData = [
  {
    supportedMethods: "basic-card",
    data: {
      supportedNetworks: ["visa", "mastercard"],
      supportedTypes: ["debit", "credit"],
    },
  },
  {
    supportedMethods: "https://example.com/bobpay",
    data: {
      merchantIdentifier: "XXXX",
      bobPaySpecificField: true,
    },
  },
];

2.2 The `details` argument

The details contains information about the transaction that the user is being asked to complete, such as the line items in an order.

Example 2: The `details` argument

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

2.2.1 Shipping options

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

Example 3: Adding shipping options

const shippingOptions = [
  {
    id: "standard",
    label: "🚛 Ground Shipping (2 days)",
    amount: { currency: "USD", value: "5.00" },
    selected: true,
  },
  {
    id: "drone",
    label: "🚀 Drone Express (2 hours)",
    amount: { currency: "USD", value: "25.00" }
  },
];
Object.assign(details, { shippingOptions });

2.2.2 Conditional modifications to payment request

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

Example 4: Modifying payment request based on card type

// Credit card incurs a $3.00 processing fee.
const creditCardFee = {
  label: "Credit card processing fee",
  amount: { currency: "USD", value: "3.00" },
};

// Modifiers apply when the user chooses to pay with
// a credit card.
const modifiers = [
  {
    additionalDisplayItems: [creditCardFee],
    supportedMethods: "basic-card",
    total: {
      label: "Total due",
      amount: { currency: "USD", value: "68.00" },
    },
    data: {
      supportedTypes: "credit",
    },
  },
];
Object.assign(details, { modifiers });

2.3 The `options` argument

The options dictionary contains information the developer needs from the user to perform the payment (e.g., the payer's name and shipping address).

Example 5: The `options` argument

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

2.4 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:

Example 6: Constructing a `PaymentRequest`

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 {
    if (await checkAllValuesAreGood(response)) {
      await response.complete("success");
    } else {
      await response.complete("fail");
    }
  } catch (err) {
    // Something went wrong...
    await response.complete("fail");
  }
}
doPaymentRequest();

2.5 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.

Example 7: Registering event handlers

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 json = request.shippingAddress.toJSON();

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

    return { shippingOptions, total };
  } catch (err) {
    return { error: `Sorry! we can't ship to your address.` };
  }
}

2.6 Fine-grained error reporting

A developer can use the shippingAddressErrors member of the PaymentDetailsUpdate dictionary to indicate that there are validation errors with specific attributes of a PaymentAddress. The 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.

Example 8

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 };
}

2.7 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 provides a toJSON() method that serializes the object directly into JSON. This makes it trivial to POST the resulting JSON back to a server using the Fetch API:

Example 9: POSTing with `fetch()`

async function doPaymentRequest() {
  const payRequest = new PaymentRequest(methodData, details, options);
  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();

3. `PaymentRequest` interface

[Constructor(sequence<PaymentMethodData> methodData, PaymentDetailsInit details, optional PaymentOptions options),
SecureContext, Exposed=Window]
interface PaymentRequest : EventTarget {
  [NewObject]
  Promise<PaymentResponse> show(optional Promise<PaymentDetailsUpdate> detailsPromise);
  [NewObject]
  Promise<void> abort();
  [NewObject]
  Promise<boolean> canMakePayment();

  readonly attribute DOMString id;
  readonly attribute PaymentAddress? shippingAddress;
  readonly attribute DOMString? shippingOption;
  readonly attribute PaymentShippingType? shippingType;

  attribute EventHandler onshippingaddresschange;
  attribute EventHandler onshippingoptionchange;
  attribute EventHandler onpaymentmethodchange;
};

Note

A developer creates a PaymentRequest to make a payment request. This is typically associated with the user initiating a payment process (e.g., by activating a "Buy," "Purchase," or "Checkout" button on a web site, selecting a "Power Up" in an interactive game, or paying at a kiosk in a parking structure). The PaymentRequest allows developers to exchange information with the user agent while the user is providing input (up to the point of user approval or denial of the payment request).

The shippingAddress, shippingOption, and shippingType attributes are populated during processing if the requestShipping member is set.

Because the simultaneous display of multiple PaymentRequest user interfaces might confuse the user, this specification limits the user agent to displaying one at a time via the show() method. This is ensured by a payment request is showing boolean.

3.1 Constructor

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

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

If the current settings object's responsible document is not allowed to use the feature indicated by attribute name allowpaymentrequest, then throw a "SecurityError" DOMException.
Let serializedMethodData be an empty list.
Establish the request's id:
1. If details.id is missing, add an id member to details and set its value to a UUID [RFC4122].
Process payment methods:
1. If the length of the methodData sequence is zero, then throw a TypeError, optionally informing the developer that at least one payment method is required.
2. For each paymentMethod of methodData:
  1. Run the steps to validate a payment method identifier with paymentMethod.supportedMethods. If it returns false, then throw a RangeError exception. Optionally, inform the developer that the payment method identifier is invalid.
  2. If the data member of paymentMethod is missing, let serializedData be null. Otherwise, let serializedData be the result of JSON-serializing paymentMethod.data into a string. Rethrow any exceptions.
  3. Add the tuple (paymentMethod.supportedMethods, serializedData) to serializedMethodData.
Process the total:
1. Check and canonicalize total amount details.total.amount. Rethrow any exceptions.
If the displayItems member of details is present, then for each item in details.displayItems:
1. Check and canonicalize amount item.amount. Rethrow any exceptions.
Let selectedShippingOption be null.
If the requestShipping member of options is present and set to true, process shipping options:
1. Let options be an empty sequence<PaymentShippingOption>.
2. If the shippingOptions member of details is present, then:
  1. Let seenIDs be an empty set.
  2. For each option in details.shippingOptions:
    1. Check and canonicalize amount item.amount. Rethrow any exceptions.
    2. If seenIDs contains option.id, then throw a TypeError. Optionally, inform the developer that shipping option IDs must be unique.
    3. Otherwise, append option.id to seenIDs.
    4. If option.selected is true, then set selectedShippingOption to option.id.
3. Set details.shippingOptions to options.
Let serializedModifierData be an empty list.
Process payment details modifiers:
1. Let modifiers be an empty sequence<PaymentDetailsModifier>.
2. If the modifiers member of details is present, then:
  1. Set modifiers to details.modifiers.
  2. For each modifier of modifiers:
    1. If the total member of modifier is present, then:
      1. Check and canonicalize total amount modifier.total.amount. Rethrow any exceptions.
    2. If the additionalDisplayItems member of modifier is present, then for each item of modifier.additionalDisplayItems:
      1. Check and canonicalize amount item.amount. Rethrow any exceptions.
    3. 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. Rethrow any exceptions.
    4. Add serializedData to serializedModifierData.
    5. Remove the data member of modifier, if it is present.
3. Set details.modifiers to modifiers.
Let request be a new PaymentRequest.
Set request.[[options]] to options.
Set request.[[state]] to "created".
Set request.[[updating]] to false.
Set request.[[details]] to details.
Set request.[[serializedModifierData]] to serializedModifierData.
Set request.[[serializedMethodData]] to serializedMethodData.
Set request.[[response]] to null.
Set the value of request's shippingOption attribute to selectedShippingOption.
Set the value of the shippingAddress attribute on request to null.
If options.requestShipping is set to true, then set the value of the shippingType attribute on request to options.shippingType. Otherwise, set it to null.
Return request.

3.2 `id` attribute

When getting, the id attribute returns this PaymentRequest's [[details]].id.

3.3 `show()` method

Note

The show() method is called when a developer wants to begin user interaction for the payment request. The show() method returns a Promise that will be resolved when the user accepts the payment request. Some kind of user interface will be presented to the user to facilitate the payment request after the show() method returns.

It is not possible to show multiple PaymentRequests at the same time within one user agent. If a PaymentRequest is already showing, calling show() —from any Web site— will return a promise rejected with an "AbortError" DOMException.

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

If the method was not triggered by user activation, return a promise rejected with with a "SecurityError" DOMException.
Let request be the context object.
Let document be request's relevant global object's associated Document.
If document is not fully active, then return a promise rejected with an "AbortError" DOMException.
Optionally, if the user agent wishes to disallow the call to 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 show(), as described in the privacy considerations section.
If request.[[state]] is not "created" then return a promise rejected with an "InvalidStateError" DOMException.
If the user agent's payment request is showing boolean is true, then return a promise rejected with an "AbortError" DOMException.
Set request.[[state]] to "interactive".
Let acceptPromise be a new promise.
Set request.[[acceptPromise]] to acceptPromise.
Optionally:
1. Reject acceptPromise with an "AbortError" DOMException.
2. Set request.[[state]] to "closed".
3. Return acceptPromise.
Note
This allows the user agent to act as if the user had immediately aborted the payment request, at its discretion. For example, in "private browsing" modes or similar, user agents might take advantage of this step.
Set the user agent's payment request is showing boolean to true.
Return acceptPromise and perform the remaining steps in parallel.
Let handlers be an empty list.
For each paymentMethod tuple in request.[[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 required by the specification that defines the identifier, then convert data to an IDL value of the type specified there. Otherwise, convert to object.
4. If conversion results in a exception error:
  1. Set request.[[state]] to "closed".
  2. Reject acceptPromise with error.
  3. Set user agent'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 steps to check if a payment can be made with data.
  2. If canMakePayment is true, then append handler to handlers.
If handlers is empty, then:
1. Set request.[[state]] to "closed".
2. Reject acceptPromise with "NotSupportedError" DOMException.
3. Set user agent's payment request is showing boolean to false.
4. Terminate this algorithm.
Present a user interface that will allow the user to interact with the handlers. The user agent SHOULD prioritize the preference of the user when presenting payment methods. It is RECOMMENDED that the language of the user interface match the language of the body element.
If detailsPromise was passed, then:
1. Run the update a PaymentRequest's details algorithm with detailsPromise and request.
2. Wait for the detailsPromise to settle.
  Note
  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.
For the payment handler selected by the end-user, the user agent MUST pass the converted second element in the paymentMethod tuple. 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 internal slots of request (some MAY be excluded for privacy reasons where appropriate).

The acceptPromise will later be resolved or rejected by either the user accepts the payment request algorithm or the user aborts the payment request algorithm, which are triggered through interaction with the user interface.

If document stops being 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 the user agent's payment request is showing boolean to false.
3. Reject acceptPromise with an "AbortError" DOMException.

3.4 `abort()` method

Note

The abort() method is called if a developer wishes to tell the user agent to abort the payment request and to tear down any user interface that might be shown. The abort() can only be called after the show() method has been called (see states) and before this instance's [[acceptPromise]] has been resolved. For example, developers might choose to do this if the goods they are selling are only available for a limited amount of time. If the user does not accept the payment request within the allowed time period, then the request will be aborted.

A user agent might not always be able to abort a request. For example, if the user agent has delegated responsibility for the request to another app. In this situation, abort() will reject the returned Promise.

See also the algorithm when the user aborts the payment request.

The abort() method MUST act as follows:

Let request be the context object.
If request.[[response]] is not null, and request.[[response]].[[retryPromise]] is not null, return a promise rejected with an "InvalidStateError" DOMException.
If the value of request.[[state]] is not "interactive" then return a promise rejected with an "InvalidStateError" DOMException.
Let promise be a new promise.
Return promise and perform the remaining steps in parallel.
Try to abort the current user interaction with the payment handler and close down any remaining user interface.
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.[[state]] to "closed".
3. Reject the promise request.[[acceptPromise]] with an "AbortError" DOMException.
4. Resolve promise with undefined.

3.5 `canMakePayment()` method

Note

The canMakePayment() method can be used by the developer to determine if the PaymentRequest object can be used to make a payment, before they call show(). It returns a Promise that will be fulfilled with true if the user agent supports any of the desired payment methods supplied to the PaymentRequest constructor, and false if none are supported. If the method is called too often, the user agent might instead return a promise rejected with a "NotAllowedError" DOMException, at its discretion.

The canMakePayment() method MUST act as follows:

Let request be the PaymentRequest object on which the method was called.
If request.[[state]] is not "created", then return a promise rejected with an "InvalidStateError" DOMException.
Optionally, at the user agent's discretion, return a promise rejected with a "NotAllowedError" DOMException.
Note
This allows user agents to apply heuristics to detect and prevent abuse of the canMakePayment() method for fingerprinting purposes, such as creating PaymentRequest objects with a variety of supported payment methods and calling canMakePayment() 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.
Let promise be a new promise.
Return promise, and perform the remaining steps in parallel.
For each paymentMethod tuple in request.[[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 required by the specification that defines the identifier, then convert data to an IDL value. Otherwise, convert to object.
4. If conversion results in an exception error, reject promise with error and terminate this algorithm.
5. Let handlers be a list of registered payment handlers that are authorized and can handle payment request for identifier.
6. For each handler in handlers:
  1. Let canMakePayment be the result of running handler's steps to check if a payment can be made with data.
  2. If canMakePayment is true, resolve promise with true, and return.
Resolve promise with false.

3.6 `shippingAddress` attribute

A PaymentRequest's 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.

3.7 `shippingType` attribute

A PaymentRequest's 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 construction (see PaymentOptions's shippingType member).

3.8 `onshippingaddresschange` attribute

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

3.9 `shippingOption` attribute

A PaymentRequest's 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.

3.10 `onshippingoptionchange` attribute

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

3.11 `onpaymentmethodchange` attribute

A PaymentRequest's onpaymentmethodchange attribute is an EventHandler for a PaymentRequestUpdateEvent named "paymentmethodchange".

3.12 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 `data` member for each corresponding item in the sequence [[details]].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 updateWith(). Note that all `data` members of `PaymentDetailsModifier` instances contained in the `modifiers` member will be removed, as they are instead stored in serialized form in the [[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 state transitions are illustrated in the figure below: Figure 1 The constructor sets the initial state to "created". The `show()` method changes the state to "interactive". From there, the `abort()` method or any other error can send the state to "closed"; similarly, the user accepts the payment request algorithm and user aborts the payment request algorithm will change the state to "closed".
[[updating]]	true is there is a pending updateWith() call to update the payment request and false otherwise.
[[acceptPromise]]	The pending Promise created during show that will be resolved if the user accepts the payment request.
[[response]]	Null, or the `PaymentResponse` instantiated by this `PaymentRequest`.

4. `PaymentMethodData` dictionary

dictionary PaymentMethodData {
  required DOMString supportedMethods;
  object data;
};

A PaymentMethodData dictionary is used to indicate a set of supported payment methods and any associated payment method specific data for those methods.

supportedMethods member: A payment method identifier for a payment method that the merchant web site accepts.
data member: An object that provides optional information that might be needed by the supported payment methods. If supplied, it will be JSON-serialized.

Note

The value of supportedMethods was changed from array to string, but the name was left as a plural to maintain compatibility with existing content on the Web.

5. `PaymentCurrencyAmount` dictionary

dictionary PaymentCurrencyAmount {
  required DOMString currency;
  required DOMString value;
};

A PaymentCurrencyAmount dictionary is used to supply monetary amounts.

currency member: A [ISO4217] well-formed 3-letter alphabetic code (i.e., the numeric codes are not supported). Their canonical form is upper case. However, the set of combinations of currency code for which localized currency symbols are available is implementation dependent. Where a localized currency symbol is not available, a user agent SHOULD use U+00A4 (¤) for formatting. User agents MAY format the display of the currency member to adhere to OS conventions (e.g., for localization purposes).

Note: Digital currencies and ISO 4217 currency codes

User agents implementing this specification enforce [ISO4217]'s 3-letter codes format via ECMAScript’s isWellFormedCurrencyCode abstract operation, which is invoked as part of the check and canonicalize amount algorithm. When a code does not adhere to the [ISO4217] defined format, a RangeError is thrown.

Current implementations will therefore allow the use of well-formed currency codes that are not part of the official [ISO4217] list (e.g., XBT, XRP, etc.). If the provided code is a currency that the browser knows how to display, then an implementation will generally display the appropriate currency symbol in the user interface (e.g., "USD" is shown as "$", "GBP" is "£", and the non-standard "XBT" could be shown as "Ƀ"). When a code cannot be matched, the specification recommends browsers show a scarab "¤".

Efforts are underway at ISO to account for digital currencies, which may result in an update to the [ISO4217] registry or an entirely new registry. The community expects this will resolve ambiguities that have crept in through the use of non-standard 3-letter codes; for example, does "BTC" refer to Bitcoin or to a future Bhutan currency? At the time of publication, it remains unclear what form this evolution will take, or even the time frame in which the work will be completed. The W3C Web Payments Working Group is liaising with ISO so that, in the future, revisions to this specification remain compatible with relevant ISO registries.
value member: A valid decimal monetary value containing a monetary amount.

The following example shows how to represent US$55.00.

Example 10

{
  "currency": "USD",
  "value" : "55.00"
}

5.1 Validity checkers

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

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

Note

The following regular expression is an implementation of the above definition.

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

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

If the result of IsWellFormedCurrencyCode(amount.currency) is false, then throw a RangeError exception, optionally informing the developer that the currency is invalid.
If amount.value is not a valid decimal monetary value, throw a TypeError, optionally informing the developer that the currency is invalid.
Set amount.currency to the result of ASCII uppercasing amount.currency.

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

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

Note: No alteration of values

6. Payment details dictionaries

6.1 `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.

Note

shippingOptions member

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

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

The shippingOptions member is only used if the PaymentRequest was constructed with PaymentOptions requestShipping set to true.

Note

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.

6.2 `PaymentDetailsInit` dictionary

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

Note

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.
Note
If an id member is not present, then the user agent will generate a unique identifier for the payment request during construction.
total member: A PaymentItem containing a non-negative total amount for the payment request.
Note
Algorithms in this specification that accept a PaymentDetailsInit dictionary will throw if the total.amount.value is a negative number.

6.3 `PaymentDetailsUpdate` dictionary

dictionary PaymentDetailsUpdate : PaymentDetailsBase {
  DOMString error;
  PaymentItem total;
  AddressErrors shippingAddressErrors;
};

The PaymentDetailsUpdate dictionary is used to update the payment request using 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. When the payment request is updated using updateWith(), the PaymentDetailsUpdate can contain a message in the error member that will be displayed to the user, if the PaymentDetailsUpdate indicates that there are no valid shippingOptions (and the PaymentRequest was constructed with the requestShipping option set to true). This can be used to explain why goods cannot be shipped to the chosen shipping address, or any other reason why no shipping options are available.
total member: A PaymentItem contains the non-negative amount.
Note
Algorithms in this specification that accept a PaymentDetailsUpdate dictionary will throw if the total.amount.value is a negative number.
shippingAddressErrors member: Represents validation errors with the shipping address that is associated with the event target.

7. `PaymentDetailsModifier` dictionary

dictionary PaymentDetailsModifier {
  required DOMString supportedMethods;
  PaymentItem total;
  sequence<PaymentItem> additionalDisplayItems;
  object data;
};

The PaymentDetailsModifier dictionary provides details that modify the PaymentDetailsBase based on a payment method identifier. It contains the following members:

supportedMethods member: A payment method identifier. The members of the PaymentDetailsModifier only apply if the user selects this payment method.
total member: A PaymentItem value that overrides the total member in the PaymentDetailsInit dictionary for the payment method identifiers of the supportedMethods member.
additionalDisplayItems member: A sequence of PaymentItem dictionaries provides additional display items that are appended to the displayItems member in the PaymentDetailsBase dictionary for the payment method identifiers in the supportedMethods member. This member is commonly used to add a discount or surcharge line item indicating the reason for the different total amount for the selected payment method that the user agent MAY display.
Note
It is the developer's responsibility to verify that the total amount is the sum of the displayItems and the additionalDisplayItems.
data member: An object that provides optional information that might be needed by the supported payment methods. If supplied, it will be JSON-serialized.

8. `PaymentShippingType` enum

enum PaymentShippingType {
  "shipping",
  "delivery",
  "pickup"
};

"shipping": This is the default and refers to the address being collected as the destination for shipping.
"delivery": This refers to the address being collected as being used for delivery. This is commonly faster than shipping. For example, it might be used for food delivery.
"pickup": This refers to the address being collected as part of a service pickup. For example, this could be the address for laundry pickup.

9. `PaymentOptions` dictionary

dictionary PaymentOptions {
  boolean requestPayerName = false;
  boolean requestPayerEmail = false;
  boolean requestPayerPhone = false;
  boolean requestShipping = false;
  PaymentShippingType shippingType = "shipping";
};

Note

The PaymentOptions dictionary is passed to the PaymentRequest constructor and provides information about the options desired for the payment request.

requestPayerName member: A boolean that indicates whether the user agent SHOULD collect and return the payer's name as part of the payment request. For example, this would be set to true to allow a merchant to make a booking in the payer's name.
requestPayerEmail member: A boolean that indicates whether the user agent SHOULD collect and return the payer's email address as part of the payment request. For example, this would be set to true to allow a merchant to email a receipt.
requestPayerPhone member: A boolean that indicates whether the user agent SHOULD collect and return the payer's phone number as part of the payment request. For example, this would be set to true to allow a merchant to phone a customer with a billing enquiry.
requestShipping member: A boolean that indicates whether the user agent SHOULD collect and return a shipping address as part of the payment request. For example, this would be set to true when physical goods need to be shipped by the merchant to the user. This would be set to false for the purchase of digital goods.
shippingType member: A PaymentShippingType enum value. Some transactions require an address for delivery but the term "shipping" isn't appropriate. For example, "pizza delivery" not "pizza shipping" and "laundry pickup" not "laundry shipping". If requestShipping is set to true, then the shippingType member can influence the way the user agent presents the user interface for gathering the shipping address.
The shippingType member only affects the user interface for the payment request.

10. `PaymentItem` dictionary

dictionary PaymentItem {
  required DOMString label;
  required PaymentCurrencyAmount amount;
  boolean pending = false;
  // Note: type member is "at risk" of being removed!
  PaymentItemType type;
};

A sequence of one or more PaymentItem dictionaries is included in the PaymentDetailsBase dictionary to indicate what the payment request is for and the value asked for.

label member: A human-readable description of the item. The user agent may display this to the user.
amount member: A PaymentCurrencyAmount containing the monetary amount for the item.
pending member: A boolean. When set to true it means that the amount member is not final. This is commonly used to show items such as shipping or tax amounts that depend upon selection of shipping address or shipping option. User agents MAY indicate pending fields in the user interface for the payment request.

Feature at Risk

This feature has been marked "at risk". Firefox plans to experiment with this feature during the Candidate Recommendation phase. If you'd like for this feature to remain in the specification, please signal your support for it to remain in issue 163.

type member: A PaymentItemType enum value, which a developer can use to explicitly indicate that this member is of a particular type. A user agent MAY use the value of type to assist in the presentation of PaymentItem by, for example, visually grouping types together or other otherwise distinguishing them from other types (or from items that have no associated type).

Feature at Risk

`PaymentItemType` enum

enum PaymentItemType {
  "tax"
};

The PaymentItemType serves to categorize a PaymentItem into particular types.

"tax": Indicates that the corresponding PaymentItem represents a form of taxation. Examples include sales tax, goods and services tax, value added tax, an so on.

11. Physical addresses

A physical address is composed of the following parts.

Address line: The most specific part of the address. It can include, for example, a street name, a house number, apartment number, a rural delivery route, descriptive instructions, or a post office box number.
City: The city/town portion of the address.
Country: The country corresponding to the address.
Dependent locality: The dependent locality or sublocality within a city. For example, neighborhoods, boroughs, districts, or UK dependent localities.
Language code: The language in which the address is provided. It's used to determine the field separators and the order of fields when formatting the address for display.
Organization: The organization, firm, company, or institution at the address.
Phone number: The phone number of the recipient or contact person at the address.
Postal code: The postal code or ZIP code, also known as PIN code in India.
Recipient: The name of the recipient or contact person at the address.
Region: The top level administrative subdivision of the country. For example, this can be a state, a province, an oblast, or a prefecture.
Sorting code: The sorting code as used in, for example, France.

11.1 `PaymentAddress` interface

[SecureContext, Exposed=(Window)]
interface PaymentAddress {
  [Default] object toJSON();
  readonly attribute DOMString city;
  readonly attribute DOMString country;
  readonly attribute DOMString dependentLocality;
  // "languageCode" is a feature at risk
  readonly attribute DOMString languageCode;
  readonly attribute DOMString organization;
  readonly attribute DOMString phone;
  readonly attribute DOMString postalCode;
  readonly attribute DOMString recipient;
  readonly attribute DOMString region;
  readonly attribute DOMString regionCode;
  readonly attribute DOMString sortingCode;
  readonly attribute FrozenArray<DOMString> addressLine;
};

The PaymentAddress interface represents a physical address.

11.1.1 Internal constructor

Issue 653

Currently, this constructor algorithm is only used internally by a user agent. It is not available to scripts. However, discussions are underway in the working group to make this into a public constructor.

The steps to internally construct a PaymentAddress with an optional AddressInit details are given by the following algorithm:

Let address be a new instance of PaymentAddress.
Set address.[[addressLine]] to the empty frozen array, and all other internal slots to the empty string.
If details was not passed, return address.
If details["country"] is present and not the empty string:
1. Set country the result of strip leading and trailing ASCII whitespace from details["country"] and performing ASCII uppercasing.
2. If country is not a valid [ISO3166-1] alpha-2 code, throw a RangeError exception.
3. Set address.[[country]] to country.
If details["regionCode"] is present and not the empty string:
1. Let regionCode be the result of strip leading and trailing ASCII whitespace from details["regionCode"] and then ASCII uppercasing the result.
2. Let putativeCountrySubdivisionCodeElement be the concatenation of address.[[country]], a single U+002D (-) code point, and regionCode.
3. If putativeCountrySubdivisionCodeElement is not a valid country subdivision code element as per [ISO3166-2]'s section 5.2 "Structure of country subdivision code elements" (non-normative details below), throw a RangeError exception.
  Note: Structure of country subdivision code elements
  Do not implement from this note. The structure of a country subdivision code element is formally defined in [ISO3166-2] (section 5.2). Although the structure is not expected to change at the time of writing, implementers are expected to track updates to [ISO3166-2] directly from ISO.
  
  As [ISO3166-2] is not freely available to the general public, the structure of a country subdivision code element at the time of publication is as follows:
  - Two code points that match an [ISO3166-1] alpha-2 country code.
  - A single U+002D (-) code point.
  - One, two, or three ASCII alphanumeric code points, in any order.
4. Set address.[[regionCode]] to regionCode.
5. If details["region"] is not present:
  1. Let region be the corresponding country subdivision name for regionCode. Where [ISO3166-2] defines multiple country subdivision names for a regionCode, it is RECOMMENDED the user agent select one by matching on:
    1. The language of the body element.
    2. The user's preferred languages.
    3. Any other criteria the user agent deems suitable.
  2. Set details["region"] to region.
If details["languageCode"] is present:
1. If IsStructurallyValidLanguageTag(details["languageCode"]) is false, throw a RangeError exception.
2. Set address.[[languageCode]] to CanonicalizeLanguageTag(details["languageCode"]).
Let cleanAddressLines be an empty list.
If details["addressLine"] is present, then for each item in details["addressLine"]:
1. Strip leading and trailing ASCII whitespace from item and append the result into cleanAddressLines.
Set address.[[addressLine]] to a new frozen array created from cleanAddressLines.
If details["region"] is present, strip leading and trailing ASCII whitespace from details["region"] and set address.[[region]] to the result.
If details["city"] is present, strip leading and trailing ASCII whitespace from details["city"] and set address.[[city]] to the result.
If details["dependentLocality"] is present, strip leading and trailing ASCII whitespace from details["dependentLocality"] and set address.[[dependentLocality]] to the result.
If details["postalCode"] is present, strip leading and trailing ASCII whitespace from details["postalCode"] and set address.[[postalCode]] to the result.
If details["sortingCode"] is present, strip leading and trailing ASCII whitespace from details["sortingCode"] and set address.[[sortingCode]] to the result.
If details["sortingCode"] is present, strip leading and trailing ASCII whitespace from details["sortingCode"] and set address.[[sortingCode]] to the result.
If details["organization"] is present, strip leading and trailing ASCII whitespace from details["organization"] and set address.[[organization]] to the result.
If details["recipient"] is present, strip leading and trailing ASCII whitespace from details["recipient"] and set address.[[recipient]] to the result.
If details["phone"] is present, strip leading and trailing ASCII whitespace from details["phone"] and set address.[[phone]] to the result.
Return address.

11.1.2 `toJSON()` method

When called, runs [WEBIDL]'s default toJSON operation.

11.1.3 `country` attribute

Represents the country of the address. When getting, returns the value of the PaymentAddress's [[country]] internal slot.

11.1.4 `addressLine` attribute

Represents the address line of the address. When getting, returns the value of the PaymentAddress's [[addressLine]] internal slot.

11.1.5 `region` attribute

Represents the region of the address. When getting, returns the value of the PaymentAddress's [[region]] internal slot.

11.1.6 `regionCode` attribute

Represents the region of the address as a code element of an [ISO3166-2] country subdivision name (e.g., "CA" for California, USA). When getting, returns the value of the PaymentAddress's [[regionCode]] internal slot.

11.1.7 `city` attribute

Represents the city of the address. When getting, returns the value of the PaymentAddress's [[city]] internal slot.

11.1.8 `dependentLocality` attribute

Represents the dependent locality of the address. When getting, returns the value of the PaymentAddress's [[dependentLocality]] internal slot.

11.1.9 `postalCode` attribute

Represents the postal code of the address. When getting, returns the value of the PaymentAddress's [[postalCode]] internal slot.

11.1.10 `sortingCode` attribute

Represents the sorting code of the address. When getting, returns the value of the PaymentAddress's [[sortingCode]] internal slot.

11.1.11 `languageCode` attribute

Feature at Risk

This feature has been marked "at risk". If you'd like for this feature to remain in the specification, please signal your support for it to remain in issue 608.

Represents the language code of the address. When getting, returns the value of the PaymentAddress's [[languageCode]] internal slot.

11.1.12 `organization` attribute

Represents the organization of the address. When getting, returns the value of the PaymentAddress's [[organization]] internal slot.

11.1.13 `recipient` attribute

Represents the recipient of the address. When getting, returns the value of the PaymentAddress's [[recipient]] internal slot.

11.1.14 `phone` attribute

Represents the phone number of the address. When getting, returns the value of the PaymentAddress's [[phone]] internal slot.

11.1.15 Internal slots

Internal slot	Description (non-normative)
[[country]]	A country as an [ISO3166-1] alpha-2 code stored in its canonical uppercase form or the empty string. For example, "JP".
[[addressLine]]	A frozen array, possibly of zero length, representing an address line.
[[region]]	A region as a country subdivision name or the empty string, such as "Victoria", representing the state of Victoria in Australia.
[[regionCode]]	The empty string, or one to three code points that represent a region as the code element of an [ISO3166-2] country subdivision name (i.e., the characters after the hyphen in an ISO3166-2 country subdivision code element, such as "CA" for the state of California in the USA, or "11" for the Lisbon district of Portugal).
[[city]]	A city or the empty string.
[[dependentLocality]]	A dependent locality or the empty string.
[[postalCode]]	A postal code or the empty string.
[[sortingCode]]	A sorting code or the empty string.
[[languageCode]]	Feature at Risk This feature has been marked "at risk". If you'd like for this feature to remain in the specification, please signal your support for it to remain in issue 608. A language tag representing the language code, or the empty string.
[[organization]]	An organization or the empty string.
[[recipient]]	A recipient or the empty string.
[[phone]]	A phone number or the empty string.

11.2 `AddressInit` dictionary

dictionary AddressInit {
  DOMString country;
  sequence<DOMString> addressLine;
  DOMString region;
  DOMString regionCode;
  DOMString city;
  DOMString dependentLocality;
  DOMString postalCode;
  DOMString sortingCode;
  DOMString languageCode;
  DOMString organization;
  DOMString recipient;
  DOMString phone;
};

A AddressInit is passed when constructing a PaymentAddress. Its members are as follows.

addressLine member: An address line, represented as a sequence.
city member: A city.
country member: An country, represented as a [ISO3166-1] country code.
dependentLocality member: A dependent locality.
languageCode member: Feature at Risk
This feature has been marked "at risk". If you'd like for this feature to remain in the specification, please signal your support for it to remain in issue 608.

A language code, represented as a language tag.
organization member: An organization.
phone member: A phone number, optionally structured to adhere to [E.164].
postalCode member: A postal code.
recipient member: A recipient. Under certain circumstances, this member may contain multiline information. For example, it might contain "care of" information.
region member: A region.
regionCode member: The empty string, or one to three code points that represent a region as the code element of an [ISO3166-2] country subdivision name (i.e., the characters after the hyphen in an ISO3166-2 country subdivision code element, such as "CA" for the state of California in the USA, or "11" for the Lisbon district of Portugal).
sortingCode member: A sorting code.

11.3 `AddressErrors` dictionary

dictionary AddressErrors {
  DOMString addressLine;
  DOMString city;
  DOMString country;
  DOMString dependentLocality;
  DOMString languageCode;
  DOMString organization;
  DOMString phone;
  DOMString postalCode;
  DOMString recipient;
  DOMString region;
  DOMString regionCode;
  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).

Note

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 to not to ask the user to fix things they might not have control over (e.g., languageCode).

addressLine member: Denotes that the address line has a validation error. In the user agent's UI, this member corresponds to the input field that provided the PaymentAddress's addressLine attribute's value.
city member: Denotes that the city has a validation error. In the user agent's UI, this member corresponds to the input field that provided the PaymentAddress's city attribute's value.
country member: Denotes that the country has a validation error. In the user agent's UI, this member corresponds to the input field that provided the PaymentAddress's country attribute's value.
dependentLocality member: Denotes that the dependent locality has a validation error. In the user agent's UI, this member corresponds to the input field that provided the PaymentAddress's dependentLocality attribute's value.
languageCode member: Denotes that the language code has a validation error. In the user agent's UI, this member corresponds to the input field that provided the PaymentAddress's languageCode attribute's value.
organization member: Denotes that the organization has a validation error. In the user agent's UI, this member corresponds to the input field that provided the PaymentAddress's organization attribute's value.
phone member: Denotes that the phone number has a validation error. In the user agent's UI, this member corresponds to the input field that provided the PaymentAddress's phone attribute's value.
postalCode member: Denotes that the postal code has a validation error. In the user agent's UI, this member corresponds to the input field that provided the PaymentAddress's postalCode attribute's value.
recipient member: Denotes that the recipient has a validation error. In the user agent's UI, this member corresponds to the input field that provided the PaymentAddress's addressLine attribute's value.
region member: Denotes that the region has a validation error. In the user agent's UI, this member corresponds to the input field that provided the PaymentAddress's region attribute's value.
regionCode member: Denotes that the region code representation of the region has a validation error. In the user agent's UI, this member corresponds to the input field that provided the PaymentAddress's regionCode attribute's value.
sortingCode member: The sorting code has a validation error. In the user agent's UI, this member corresponds to the input field that provided the PaymentAddress's sortingCode attribute's value.

11.4 Creating a `PaymentAddress` from user-provided input

The steps to create a PaymentAddress from user-provided input are given by the following algorithm. The algorithm takes a list redactList, for which user input will not be gathered.

Let details be an AddressInit dictionary with no members present.
If "addressLine" is not in redactList, set details["addressLine"] to the result of splitting the user-provided address line into a list. If none was provided, set it to the empty list.
Note
How to split an address line is locale dependent and beyond the scope of this specification.
If "country" is not in redactList, set details["country"] to the user-provided country as an upper case [ISO3166-1] alpha-2 code, or to the empty string if none was provided.
If "phone" is not in redactList, set details["phone"] to the user-provided phone number, or to the empty string if none was provided.
Note: Privacy of phone number

To maintain user's privacy, implementers need to be mindful that a shipping address's associated phone number might be different or the same from that of the end-user's. As such, implementers need to take care to not provide the end user's phone number to the merchant without the end user's consent.
If "languageCode" is not in redactList, set details["languageCode"] to a canonicalized language tag, or to the empty string if none was provided.
Feature at Risk 608
If "city" is not in redactList, set details["city"] to the user-provided city, or to the empty string if none was provided.
If "dependentLocality" is not in redactList, set details["dependentLocality"] to the user-provided dependent locality, or to the empty string if none was provided.
If "organization" is not in redactList, set details["organization"] to the user-provided recipient organization, or to the empty string if none was provided.
If "postalCode" is not in redactList, set details["postalCode"] to the user-provided postal code, or to the empty string if none was provided. Optionally, redact part of details["postalCode"].
Note: Privacy of Postal Codes

Postal codes in certain countries can be so specific as to uniquely identify an individual. This being a privacy concern, some user agents only return the part of a postal code that they deem sufficient for a merchant to calculate shipping costs. This varies across countries and regions, and so the choice to redact part, or all, of the postal code is left to the discretion of implementers in the interest of protecting users' privacy.
If "recipient" is not in redactList, set details["recipient"] to the user-provided recipient of the transaction, or to the empty string if none was provided.
If "region" is not in redactList:

Note: Countries where regions are not commonly used
In some countries (e.g., Belgium) it is uncommon for users to include a region as part of a physical address (even if all the regions of a country are part of [ISO3166-2]). As such, when the user agent knows that the user is inputting the address for a particular country, it might not provide a field for the user to input a region. In such cases, the user agent returns an empty string for both PaymentAddress's region and regionCode attributes - but the address can still serve its intended purpose (e.g., be valid for shipping or billing purposes).
1. Set details["region"] to the user-provided region, or to the empty string if none was provided.
2. If details["region"] has a corresponding country subdivision code element, set details["regionCode"] to that country subdivision code element.
If "sortingCode" is not in redactList, set details["sortingCode"] to the user-provided sorting code, or to the empty string if none was provided.
Internally construct a new PaymentAddress with details and return the result.

12. `PaymentShippingOption` dictionary

dictionary PaymentShippingOption {
  required DOMString id;
  required DOMString label;
  required PaymentCurrencyAmount amount;
  boolean selected = false;
};

The PaymentShippingOption dictionary has members describing a shipping option. Developers can provide the user with one or more shipping options by calling the updateWith() method in response to a change event.

id member: A string identifier used to reference this PaymentShippingOption. It MUST be unique for a given PaymentRequest.
label member: A human-readable string description of the item. The user agent SHOULD use this string to display the shipping option to the user.
amount member: A PaymentCurrencyAmount containing the monetary amount for the item.
selected member: A boolean. When true, it indicates that this is the default selected PaymentShippingOption in a sequence. User agents SHOULD display this option by default in the user interface.

13. `PaymentComplete` enum

enum PaymentComplete {
  "fail",
  "success",
  "unknown"
};

"fail": Indicates that processing of the payment failed. The user agent MAY display UI indicating failure.
"success": Indicates the payment was successfully processed. The user agent MAY display UI indicating success.
"unknown": The developer did not indicate success or failure and the user agent SHOULD NOT display UI indicating success or failure.

14. `PaymentResponse` interface

[SecureContext, Exposed=Window]
interface PaymentResponse : EventTarget {
  [Default] object toJSON();

  readonly attribute DOMString requestId;
  readonly attribute DOMString methodName;
  readonly attribute object details;
  readonly attribute PaymentAddress? shippingAddress;
  readonly attribute DOMString? shippingOption;
  readonly attribute DOMString? payerName;
  readonly attribute DOMString? payerEmail;
  readonly attribute DOMString? payerPhone;

  [NewObject]
  Promise<void> complete(optional PaymentComplete result = "unknown");
  [NewObject]
  Promise<void> retry(PaymentValidationErrors errorFields);

  attribute EventHandler onpayerdetailchange;
};

Note

A PaymentResponse is returned when a user has selected a payment method and approved a payment request.

14.1 `retry()` method

The retry(errorFields) method MUST act as follows:

Let response be the context object.
Let request be response.[[request]].
Let document be request's relevant global object's associated Document.
If document is not fully active, then return a promise rejected with an "AbortError" DOMException.
If response.[[complete]] is true, return a promise rejected with an "InvalidStateError" DOMException.
If response.[[retryPromise]] is not null, return a promise rejected with an "InvalidStateError" DOMException.
Set request.[[state]] to "interactive".
Let retryPromise be a new promise.
Set response.[[retryPromise]] to retryPromise.
If errorFields's paymentMethod member was passed, and if required by the specification that defines response's payment method, then convert errorFields paymentMethod to an IDL value of the type specified there. Otherwise, convert to object.
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.
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 error member is passed, present the error in the user agent's UI.
If document stops being 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 the user agent's payment request is showing boolean to false.
3. Reject retryPromise with an "AbortError" DOMException.
Finally, when retryPromise settles, set response.[[retryPromise]] to null.
Return retryPromise.
Note
The retryPromise will later be resolved by the user accepts the payment request algorithm, or rejected by either the user aborts the payment request algorithm or abort the update.

14.1.1 `PaymentValidationErrors` dictionary

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

payer member: Validation errors related to the payer details.
shippingAddress member: Represents validation errors with the PaymentResponse's shippingAddress.
error member: A general description of an error with the payment from which the user can attempt to recover from by, for example, retrying a payment. A developer can optionally pass the error member on its own to give a general overview of validation issues, or it can be passed in combination with other members of the PaymentValidationErrors dictionary.
paymentMethod member: A payment method specific errors. See, for example, [payment-method-basic-card]'s BasicCardErrorFields.

14.1.2 `PayerErrorFields` dictionary

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

The PayerErrorFields is used to represent validation errors with one or more payer details.

Payer details are any of the payer's name, payer's phone number, and payer's email.

email member: Denotes that the payer's email suffers from a validation error. In the user agent's UI, this member corresponds to the input field that provided the PaymentResponse's payerEmail attribute's value.
name member: Denotes that the payer's name suffers from a validation error. In the user agent's UI, this member corresponds to the input field that provided the PaymentResponse's payerName attribute's value.
phone member: Denotes that the payer's phone number suffers from a validation error. In the user agent's UI, this member corresponds to the input field that provided the PaymentResponse's payerPhone attribute's value.

Example 11: Payer-related validation errors

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

14.2 `toJSON()` method

When called, runs [WEBIDL]'s default toJSON operation.

14.3 `methodName` attribute

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

14.4 `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).

Note

Each standardized payment method identifier, such as Basic Card ("basic-card"), defines its own unique IDL dictionary for use with the details attribute. The shape of this data (i.e., its members and their corresponding types and formats) differs depending on which standardized payment method identifier is selected by the end user.

Similarly, a URL-based payment method identifier defines the shape of details. However, as URL-based payment method identifiers are not standardized by the W3C, developers need to consult whoever controls the URL for the expected shape of the details object.

14.5 `shippingAddress` attribute

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

14.6 `shippingOption` attribute

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

14.7 `payerName` attribute

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

14.8 `payerEmail` attribute

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

14.9 `payerPhone` attribute

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

14.10 `requestId` attribute

The corresponding payment request id that spawned this payment response.

14.11 `complete()` method

Note

The complete() method is called after the user has accepted the payment request and the [[acceptPromise]] has been resolved. Calling the 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 complete() the payment request user interface remains in a pending state. At this point the user interface ought not offer a cancel command because acceptance of the payment request has been returned. However, if something goes wrong and the developer never calls complete() then the user interface is blocked.

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

The complete(result) method MUST act as follows:

Let response be the context object.
If response.[[complete]] is true, return a promise rejected with an "InvalidStateError" DOMException.
Let promise be a new promise.
Set response.[[complete]] to true.
If response.[[retryPromise]] is not null, reject promise with an "InvalidStateError" DOMException.
Return promise and perform the remaining steps in parallel.
If document stops being 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 the user agent's payment request is showing boolean to false.
3. Reject promise with an "AbortError" DOMException.
Otherwise:
1. Close down any remaining user interface. The user agent MAY use the value result to influence the user experience.
2. Set the user agent's payment request is showing boolean to false.
3. Resolve promise with undefined.

14.12 `onpayerdetailchange` attribute

Allows a developer to handle "payerdetailchange" events.

14.13 Internal Slots

Instances of PaymentResponse are created with the internal slots in the following table:

Internal Slot	Description (non-normative)
[[complete]]	Is true if the request for payment has completed (i.e., `complete()` was called, or there was a fatal error that made the response not longer usable), or false otherwise.
[[request]]	The `PaymentRequest` instance that instantiated this `PaymentResponse`.
[[retryPromise]]	Null, or a Promise that resolves when a user accepts the payment request or rejects if the user aborts the payment request.

15. `PaymentRequest` and `iframe` elements

This section is non-normative.

To indicate that a cross-origin iframe is allowed to invoke the payment request API, the allowpaymentrequest attribute can be specified on the iframe element.

16. Events

16.1 Summary

This section is non-normative.

Event name	Interface	Dispatched when…	Target
`shippingaddresschange`	`PaymentRequestUpdateEvent`	The user provides a new shipping address.	`PaymentRequest`
`shippingoptionchange`	`PaymentRequestUpdateEvent`	The user chooses a new shipping option.	`PaymentRequest`
`payerdetailchange`	`PaymentRequestUpdateEvent`	The user changes the payer name, the payer email, or the payer phone (see payer detail changed algorithm).	`PaymentResponse`
`paymentmethodchange`	`PaymentMethodChangeEvent`	The user chooses a different payment method within a payment handler.	`PaymentRequest`

16.2 `PaymentMethodChangeEvent` interface

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

16.2.1 `methodDetails` attribute

When getting, returns the value it was initialized with. See methodDetails member of PaymentMethodChangeEventInit for more information.

16.2.2 `methodName` attribute

When getting, returns the value it was initialized with. See methodName member of PaymentMethodChangeEventInit for more information.

16.2.3 `PaymentMethodChangeEventInit` dictionary

dictionary PaymentMethodChangeEventInit : PaymentRequestUpdateEventInit {
  required DOMString methodName;
  object? methodDetails;
};

methodName member: A DOMString representing the payment method identifier.
methodDetails member: An object representing some data from the payment method, or null.

16.3 `PaymentRequestUpdateEvent` interface

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

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

16.3.1 Constructor

The PaymentRequestUpdateEvent(type, eventInitDict) constructor MUST act as follows:

Let event be the result of constructing a PaymentRequestUpdateEvent instance with type and eventInitDict.
Set event.[[waitForUpdate]] to false.
Return event.

16.3.2 `updateWith()` method

Note

If a developer wants to update the payment request, then they need to call updateWith() and provide a PaymentDetailsUpdate dictionary, or a promise for one, containing changed values that the user agent presents to the user.

To prevent the user interface from blocking (and to reflect changes made by the end-user through the UI), developers need to immediately call updateWith().

Example: how to use `updateWith()` correctly.

// ❌ Bad - this won't work!
request.onshippingaddresschange = async ev => {
  // await goes to next tick, and updateWith()
  // was not called.
  const details = await getNewDetails(oldDetails);
  // 💥 So it's now too late! updateWith()
  // throws "InvalidStateError".
  ev.updateWith(details);
};

// ✅ Good - UI will wait.
request.onshippingaddresschange = ev => {
  // Calling updateWith() with a promise is ok 👍
  const promiseForNewDetails = getNewDetails(oldDetails);
  ev.updateWith(promiseForNewDetails);
};

Additionally, [[waitForUpdate]] prevents reuse of PaymentRequestUpdateEvent.

Example: can only call `updateWith()` once

// ❌ Bad - calling updateWith() doesn't work!
request.addEventListener("shippingaddresschange", ev => {
  ev.updateWith(details); // this is ok.
  // 💥 [[waitForUpdate]] is true, throws "InvalidStateError".
  ev.updateWith(otherDetails);
});

// ❌ Bad - this won't work either!
request.addEventListener("shippingaddresschange", async ev => {
  const p = Promise.resolve({ ...details });
  ev.updateWith(p);
  await p;
  // 💥 Only one call to updateWith() is allowed,
  // so the following throws "InvalidStateError"
  ev.updateWith({ ...newDetails });
});

The updateWith(detailsPromise) method MUST act as follows:

Let event be this PaymentRequestUpdateEvent instance.
If event's isTrusted attribute is false, then then throw an "InvalidStateError" DOMException.
If event.[[waitForUpdate]] is true, then throw an "InvalidStateError" DOMException.
If event's target is an instance of PaymentResponse, let request be event's target.[[request]].
Otherwise, let request be the value of event's target.
Assert: request is an instance of PaymentRequest.
If request.[[state]] is not "interactive", then throw an "InvalidStateError" DOMException.
If request.[[updating]] is true, then throw an "InvalidStateError" DOMException.
Set event's stop propagation flag and stop immediate propagation flag.
Set event.[[waitForUpdate]] to true.
Run the update a PaymentRequest's details algorithm with detailsPromise and request.

16.3.3 Internal Slots

Instances of PaymentRequestUpdateEvent are created with the internal slots in the following table:

Internal Slot	Description (non-normative)
[[waitForUpdate]]	A boolean indicating whether an `updateWith()`-initiated update is currently in progress.

16.3.4 `PaymentRequestUpdateEventInit` dictionary

dictionary PaymentRequestUpdateEventInit : EventInit {};

17. 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.

17.1 Shipping address changed algorithm

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

Let request be the PaymentRequest object that the user is interacting with.
Queue a task on the user interaction task source to run the following steps:
1. Note: Privacy of recipient information
  
  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. Let address be the result of running the steps to create a PaymentAddress from user-provided input with redactList.
3. Set the shippingAddress attribute on request to address.
4. Run the PaymentRequest updated algorithm with request and "shippingaddresschange".

17.2 Shipping option changed algorithm

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

Let request be the PaymentRequest object that the user is interacting with.
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. Run the PaymentRequest updated algorithm with request and "shippingoptionchange".

17.3 Payment method changed algorithm

A payment handler MAY run the payment method changed algorithm when the user changes payment method with methodDetails, which is either 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:

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

17.4 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:

Assert: request.[[updating]] is false. Only one update can take place at a time.
Assert: request.[[state]] is "interactive".
Let event be the result of creating an event using the PaymentRequestUpdateEvent interface.
Initialize event's type attribute to name.
Dispatch event at request.
If event.[[waitForUpdate]] is true, disable any part of the user interface that could cause another update event to be fired.

17.5 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:

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

17.6 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:

Let request be the PaymentRequest object that the user is interacting with.
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.
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.
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.
Let isRetry be true if request.[[response]] is not null, false otherwise.
Let response be request.[[response]] if isRetry is true, or a new PaymentResponse otherwise.
If isRetry if false, initialize the newly created response:
1. Set response.[[request]] to request.
2. Set response.[[retryPromise]] to null.
3. Set response.[[complete]] to false.
4. Set the requestId attribute value of response to the value of request.[[details]].id.
5. Set request.[[response]] to response.
Let handler be the payment handler selected by the user.
Set the methodName attribute value of response to the payment method identifier of handler.
Set the details attribute value of response to an object resulting from running the handler's steps to respond to a payment request.
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. Let shippingAddress be the result of create a PaymentAddress from user-provided input with redactList.
3. Set the shippingAddress attribute value of response to shippingAddress.
4. Set the shippingAddress attribute value of request to shippingAddress.
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.
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.
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.
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].
If isRetry is true, resolve response.[[retryPromise]] with undefined. Otherwise, resolve request.[[acceptPromise]] with response.
Set request.[[state]] to "closed".

17.7 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:

Let request be the PaymentRequest object that the user is interacting with.
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.
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.
Set request.[[state]] to "closed".
Set the user agent's payment request is showing boolean to false.
Let error be an "AbortError" DOMException.
Let response be request.[[response]].
If response is not null:
1. Set response.[[complete]] to true.
2. Assert: response.[[retryPromise]] is not null.
3. Reject response.[[retryPromise]] with error.
Otherwise, reject request.[[acceptPromise]] with error.

17.8 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. 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. 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.

Set request.[[updating]] to true.
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.
Upon rejection of detailsPromise:
1. Abort the update with request and an "AbortError" DOMException.
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 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 total member of details is present, then:
    1. Check and canonicalize total amount details.total.amount. If an exception is thrown, then abort the update with request and that exception.
  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 request and that exception.
  3. If the shippingOptions member of details is present, and request.[[options]].requestShipping is true, then:
    1. Let seenIDs be an empty set.
    2. For each option in details.shippingOptions:
      1. Check and canonicalize amount option.amount. If an exception is thrown, then abort the update with request and that exception.
      2. If seenIDs[option.id] exists, then abort the update with request and a TypeError.
      3. Append option.id to seenIDs.
      4. Append option to shippingOptions.
      5. If option.selected is true, then set selectedShippingOption to option.id.
  4. If the modifiers member of details is present, then:
    1. Let modifiers be the sequence details.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.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 total member of modifier is present, then:
        
        Check and canonicalize total amount modifier.total.amount. If an exception is thrown, then abort the update with request and that exception.
      3. If the additionalDisplayItems member of modifier is present, then for each PaymentItem item in modifier.additionalDisplayItems:
        
        Check and canonicalize amount item.amount. If an exception is thrown, then abort the update with request and that exception.
      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 request and that exception.
      5. Add serializedData to serializedModifierData.
      6. Remove the data member of modifier, if it is present.
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. If the displayItems member of details is present, then:
    1. Set request.[[details]].displayItems to details.displayItems.
  3. If the shippingOptions member of details is present, and request.[[options]].requestShipping is true, then:
    1. Set request.[[details]].shippingOptions to shippingOptions.
    2. Set the value of request's shippingOption attribute to selectedShippingOption.
  4. If the modifiers member of details is present, then:
    1. Set request.[[details]].modifiers to details.modifiers.
    2. Set request.[[serializedModifierData]] to serializedModifierData.
  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.
    
    Further, if the 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.
Set request.[[updating]] to false.
Update the user interface based on any changed values in request. Re-enable user interface elements disabled prior to running this algorithm.

17.8.1 Abort the update

To abort the update with a PaymentRequest request and exception exception:

Optionally, show an error message to the user when letting them know an error has occurred.
Abort the current user interaction and close down any remaining user interface.
Queue a task on the user interaction task source to perform the following steps:
1. Set the user agent's payment request is showing boolean to false.
2. Set request.[[state]] to "closed".
3. Let response be request.[[response]].
4. If response is not null, then:
  1. Set response.[[complete]] to true.
  2. Assert: response.[[retryPromise]] is not null.
  3. Reject response.[[retryPromise]] with exception.
5. Otherwise, reject request.[[acceptPromise]] with exception.
6. Set request.[[updating]] to false.
Abort the algorithm.

Note

Abort the update runs 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().

Similarly, abort the update occurring during retry() causes the [[retryPromise]] to reject, and the corresponding PaymentRequest's [[complete]] internal slot will be set to true (i.e., it can no longer be used).

18. Privacy and Security Considerations

This section is non-normative.

18.1 User Protections with `show()` method

This section is non-normative.

To help ensure that users do not inadvertently share sensitive credentials with an origin, this API requires that PaymentRequest's show() method be triggered by user 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 show() method. In addition, the user agent can limit the rate at which a page can call show().

18.2 Secure contexts

This section is non-normative.

The API defined in this specification is only exposed in secure contexts. In practice, this means that this API is only available over HTTPS. This is to limit the possibly of payment method data (e.g., credit card numbers) being sent in the clear.

18.3 Cross-origin payment requests

This section is non-normative.

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 allowpaymentrequest attribute.

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

18.4 Encryption of data fields

This section is non-normative.

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.

18.5 How user agents match payment handlers

This section is non-normative.

As part of show(), the user agent typically displays a list of matching payment handlers that satisfy the payment methods accepted by the merchant and other conditions. Matching can take into account payment method information provided as input to the API, information provided by the payment method owner, the payment handlers registered by the user, user preferences, and other considerations.

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

19. Privacy Considerations

19.1 Exposing user information

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

One way that the API supports limited information sharing is through the "redactList" associated with the creation of physical addresses throughout the API. This feature enables user agents to provide the payee with enough information to compute shipping costs or tax information, while limiting the payee's ability to identify the payer via the address.

The user agent MUST NOT share the values of the displayItems member or additionalDisplayItems member with a third-party payment handler without user consent.

19.2 canMakePayment() protections

The canMakePayment() method enables the payee to call show() if the user is ready to take advantage of the API, or to fall back to a legacy checkout experience if not. Because this method shares some information with the payee, user agents are expected to protect the user from abuse of the method, for example, by restricting the number or frequency of calls.

20. Dependencies

This specification relies on several other underlying specifications.

DOM

The Event interface, the EventTarget interface, the EventInit dictionary, and the terms fire an event, dispatch flag, stop propagation flag, isTrusted attribute, context object, and stop immediate propagation flag are defined by [DOM].

ECMAScript

The terms Promise, internal slot,


          RangeError

, TypeError, and JSON.stringify are defined by [ECMASCRIPT].

The term JSON-serialize applied to a given object means to run the algorithm specified by the original value of the JSON.stringify function on the supplied object, passing the supplied object as the sole argument, and return the resulting string. This can throw an exception.

HTML

The following are defined by [HTML]: EventHandler, queue a task, user interaction task source, top-level browsing context, current settings object, allowed to use, triggered by user activation, in parallel, the iframe element, and the allowpaymentrequest attribute.

Infra

The [[!INFRA] specification defines how to strip leading and trailing ascii whitespace. It also defines the concept of a list and code point.

ISO 3366-2

Country subdivision name and country subdivision code element are defined in [ISO3166-2].

Payment Method Identifiers

The term payment method identifier is defined by [payment-method-id]. It's an unique identifier for a payment method.

Web IDL

When this specification says to throw an error, the user agent must throw an error as described in [WEBIDL]. When this occurs in a sub-algorithm, this results in termination of execution of the sub-algorithm and all ancestor algorithms until one is reached that explicitly describes procedures for catching exceptions.

The algorithm for converting an ECMAScript value to a dictionary is defined by [WEBIDL].

DOMException and the following DOMException types from [WEBIDL] are used: "AbortError", "InvalidStateError", "NotAllowedError", "NotSupportedError", and "SecurityError".

Writing Promise-Using Specifications

The terms a new promise, a promise rejected with r, upon fulfillment and upon rejection are defined by [PROMISES-GUIDE].

21. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, RECOMMENDED, SHOULD, and SHOULD NOT are to be interpreted as described in [RFC2119].

There is only one class of product that can claim conformance to this specification: a user agent.

Note

Although this specification is primarily targeted at web browsers, it is feasible that other software could also implement this specification in a conforming manner.

User agents MAY implement algorithms given in this specification in any way desired, so long as the end result is indistinguishable from the result that would be obtained by the specification's algorithms.

User agents MAY impose implementation-specific limits on otherwise unconstrained inputs, e.g., to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations. When an input exceeds implementation-specific limit, the user agent MUST throw, or, in the context of a promise, reject with, a TypeError optionally informing the developer of how a particular input exceeded an implementation-specific limit.

A. IDL Index

[Constructor(sequence<PaymentMethodData> methodData, PaymentDetailsInit details, optional PaymentOptions options),
SecureContext, Exposed=Window]
interface PaymentRequest : EventTarget {
  [NewObject]
  Promise<PaymentResponse> show(optional Promise<PaymentDetailsUpdate> detailsPromise);
  [NewObject]
  Promise<void> abort();
  [NewObject]
  Promise<boolean> canMakePayment();

  readonly attribute DOMString id;
  readonly attribute PaymentAddress? shippingAddress;
  readonly attribute DOMString? shippingOption;
  readonly attribute PaymentShippingType? shippingType;

  attribute EventHandler onshippingaddresschange;
  attribute EventHandler onshippingoptionchange;
  attribute EventHandler onpaymentmethodchange;
};

dictionary PaymentMethodData {
  required DOMString supportedMethods;
  object data;
};

dictionary PaymentCurrencyAmount {
  required DOMString currency;
  required DOMString value;
};

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

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

dictionary PaymentDetailsUpdate : PaymentDetailsBase {
  DOMString error;
  PaymentItem total;
  AddressErrors shippingAddressErrors;
};

dictionary PaymentDetailsModifier {
  required DOMString supportedMethods;
  PaymentItem total;
  sequence<PaymentItem> additionalDisplayItems;
  object data;
};

enum PaymentShippingType {
  "shipping",
  "delivery",
  "pickup"
};

dictionary PaymentOptions {
  boolean requestPayerName = false;
  boolean requestPayerEmail = false;
  boolean requestPayerPhone = false;
  boolean requestShipping = false;
  PaymentShippingType shippingType = "shipping";
};

dictionary PaymentItem {
  required DOMString label;
  required PaymentCurrencyAmount amount;
  boolean pending = false;
  // Note: type member is "at risk" of being removed!
  PaymentItemType type;
};

enum PaymentItemType {
  "tax"
};

[SecureContext, Exposed=(Window)]
interface PaymentAddress {
  [Default] object toJSON();
  readonly attribute DOMString city;
  readonly attribute DOMString country;
  readonly attribute DOMString dependentLocality;
  // "languageCode" is a feature at risk
  readonly attribute DOMString languageCode;
  readonly attribute DOMString organization;
  readonly attribute DOMString phone;
  readonly attribute DOMString postalCode;
  readonly attribute DOMString recipient;
  readonly attribute DOMString region;
  readonly attribute DOMString regionCode;
  readonly attribute DOMString sortingCode;
  readonly attribute FrozenArray<DOMString> addressLine;
};

dictionary AddressInit {
  DOMString country;
  sequence<DOMString> addressLine;
  DOMString region;
  DOMString regionCode;
  DOMString city;
  DOMString dependentLocality;
  DOMString postalCode;
  DOMString sortingCode;
  DOMString languageCode;
  DOMString organization;
  DOMString recipient;
  DOMString phone;
};

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

dictionary PaymentShippingOption {
  required DOMString id;
  required DOMString label;
  required PaymentCurrencyAmount amount;
  boolean selected = false;
};

enum PaymentComplete {
  "fail",
  "success",
  "unknown"
};

[SecureContext, Exposed=Window]
interface PaymentResponse : EventTarget {
  [Default] object toJSON();

  readonly attribute DOMString requestId;
  readonly attribute DOMString methodName;
  readonly attribute object details;
  readonly attribute PaymentAddress? shippingAddress;
  readonly attribute DOMString? shippingOption;
  readonly attribute DOMString? payerName;
  readonly attribute DOMString? payerEmail;
  readonly attribute DOMString? payerPhone;

  [NewObject]
  Promise<void> complete(optional PaymentComplete result = "unknown");
  [NewObject]
  Promise<void> retry(PaymentValidationErrors errorFields);

  attribute EventHandler onpayerdetailchange;
};

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

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

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

dictionary PaymentMethodChangeEventInit : PaymentRequestUpdateEventInit {
  required DOMString methodName;
  object? methodDetails;
};

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

dictionary PaymentRequestUpdateEventInit : EventInit {};

B. Acknowledgements

This specification was derived from a report published previously by the Web Platform Incubator Community Group.

C. References

C.1 Normative references

[BCP47]: Tags for Identifying Languages. A. Phillips; M. Davis. IETF. September 2009. IETF Best Current Practice. URL: https://tools.ietf.org/html/bcp47
[DOM]: DOM Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/
[E.164]: The international public telecommunication numbering plan. ITU-T. November 2010. Recommendation. URL: https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-E.164-201011-I!!PDF-E&type=items
[ecma-402]: ECMAScript Internationalization API Specification. Ecma International. URL: https://tc39.github.io/ecma402/
[ECMASCRIPT]: ECMAScript Language Specification. Ecma International. URL: https://tc39.github.io/ecma262/
[HTML]: HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]: Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[ISO3166-1]: ISO 3166: Codes for the representation of names of countries and their subdivisions – Part 1: Country codes. International Organization for Standardization (ISO). November 2013. Published. URL: https://www.iso.org/standard/63545.html
[ISO3166-2]: ISO 3166: Codes for the representation of names of countries and their subdivisions – Part 2: Country subdivision code.. International Organization for Standardization (ISO). November 2013. Published. URL: https://www.iso.org/standard/63546.html
[ISO4217]: Currency codes - ISO 4217. ISO. 2015. International Standard. URL: http://www.iso.org/iso/home/standards/currency_codes.htm
[payment-method-id]: Payment Method Identifiers. Adrian Bateman; Zach Koch; Roy McElmurry; Marcos Caceres. W3C. 14 September 2017. W3C Candidate Recommendation. URL: https://www.w3.org/TR/payment-method-id/
[PROMISES-GUIDE]: Writing Promise-Using Specifications. Domenic Denicola. W3C. 16 February 2016. Finding of the W3C TAG. URL: https://www.w3.org/2001/tag/doc/promises-guide
[RFC2119]: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC4122]: A Universally Unique IDentifier (UUID) URN Namespace. P. Leach; M. Mealling; R. Salz. IETF. July 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc4122
[secure-contexts]: Secure Contexts. Mike West. W3C. 15 September 2016. W3C Candidate Recommendation. URL: https://www.w3.org/TR/secure-contexts/
[WEBIDL]: Web IDL. Cameron McCormack; Boris Zbarsky; Tobie Langel. W3C. 15 December 2016. W3C Editor's Draft. URL: https://heycam.github.io/webidl/

C.2 Informative references

[fetch]: Fetch Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/
[payment-method-basic-card]: Payment Method: Basic Card. Adrian Bateman; Zach Koch; Roy McElmurry; Marcos Caceres. W3C. 10 May 2018. W3C Working Draft. URL: https://www.w3.org/TR/payment-method-basic-card/
[rfc6454]: The Web Origin Concept. A. Barth. IETF. December 2011. Proposed Standard. URL: https://tools.ietf.org/html/rfc6454

Payment Request API

W3C Candidate Recommendation 30 August 2018

Abstract

Status of This Document

Features at risk

1. Introduction

1.1 Goals

1.1.1 Out of scope

2. Examples of usage

2.1 The methodData argument

2.2 The details argument

2.2.1 Shipping options

2.2.2 Conditional modifications to payment request

2.3 The options argument

2.4 Constructing a PaymentRequest

2.5 Handling events and updating the payment request

2.6 Fine-grained error reporting

2.7 POSTing payment response back to a server

3. PaymentRequest interface

3.1 Constructor

3.2 id attribute

3.3 show() method

3.4 abort() method

3.5 canMakePayment() method

3.6 shippingAddress attribute

3.7 shippingType attribute

3.8 onshippingaddresschange attribute

3.9 shippingOption attribute

3.10 onshippingoptionchange attribute

3.11 onpaymentmethodchange attribute

3.12 Internal Slots

4. PaymentMethodData dictionary

5. PaymentCurrencyAmount dictionary

5.1 Validity checkers

6. Payment details dictionaries

6.1 PaymentDetailsBase dictionary

6.2 PaymentDetailsInit dictionary

6.3 PaymentDetailsUpdate dictionary

7. PaymentDetailsModifier dictionary

8. PaymentShippingType enum

9. PaymentOptions dictionary

10. PaymentItem dictionary

PaymentItemType enum

11. Physical addresses

11.1 PaymentAddress interface

11.1.1 Internal constructor

11.1.2 toJSON() method

11.1.3 country attribute

11.1.4 addressLine attribute

11.1.5 region attribute

11.1.6 regionCode attribute

11.1.7 city attribute

11.1.8 dependentLocality attribute

11.1.9 postalCode attribute

11.1.10 sortingCode attribute

11.1.11 languageCode attribute

11.1.12 organization attribute

11.1.13 recipient attribute

11.1.14 phone attribute

11.1.15 Internal slots

11.2 AddressInit dictionary

11.3 AddressErrors dictionary

11.4 Creating a PaymentAddress from user-provided input

12. PaymentShippingOption dictionary

13. PaymentComplete enum

14. PaymentResponse interface

14.1 retry() method

14.1.1 PaymentValidationErrors dictionary

14.1.2 PayerErrorFields dictionary

14.2 toJSON() method

14.3 methodName attribute

14.4 details attribute

14.5 shippingAddress attribute

14.6 shippingOption attribute

14.7 payerName attribute

14.8 payerEmail attribute

14.9 payerPhone attribute

14.10 requestId attribute

14.11 complete() method

14.12 onpayerdetailchange attribute

2.1 The `methodData` argument

2.2 The `details` argument

2.3 The `options` argument

2.4 Constructing a `PaymentRequest`

3. `PaymentRequest` interface

3.2 `id` attribute

3.3 `show()` method

3.4 `abort()` method

3.5 `canMakePayment()` method

3.6 `shippingAddress` attribute

3.7 `shippingType` attribute

3.8 `onshippingaddresschange` attribute

3.9 `shippingOption` attribute

3.10 `onshippingoptionchange` attribute

3.11 `onpaymentmethodchange` attribute

4. `PaymentMethodData` dictionary

5. `PaymentCurrencyAmount` dictionary

6.1 `PaymentDetailsBase` dictionary

6.2 `PaymentDetailsInit` dictionary

6.3 `PaymentDetailsUpdate` dictionary

7. `PaymentDetailsModifier` dictionary

8. `PaymentShippingType` enum

9. `PaymentOptions` dictionary

10. `PaymentItem` dictionary

`PaymentItemType` enum

11.1 `PaymentAddress` interface

11.1.2 `toJSON()` method

11.1.3 `country` attribute

11.1.4 `addressLine` attribute

11.1.5 `region` attribute

11.1.6 `regionCode` attribute

11.1.7 `city` attribute

11.1.8 `dependentLocality` attribute

11.1.9 `postalCode` attribute

11.1.10 `sortingCode` attribute

11.1.11 `languageCode` attribute

11.1.12 `organization` attribute

11.1.13 `recipient` attribute

11.1.14 `phone` attribute

11.2 `AddressInit` dictionary

11.3 `AddressErrors` dictionary

11.4 Creating a `PaymentAddress` from user-provided input

12. `PaymentShippingOption` dictionary

13. `PaymentComplete` enum

14. `PaymentResponse` interface

14.1 `retry()` method

14.1.1 `PaymentValidationErrors` dictionary

14.1.2 `PayerErrorFields` dictionary

14.2 `toJSON()` method

14.3 `methodName` attribute

14.4 `details` attribute

14.5 `shippingAddress` attribute

14.6 `shippingOption` attribute

14.7 `payerName` attribute

14.8 `payerEmail` attribute

14.9 `payerPhone` attribute

14.10 `requestId` attribute

14.11 `complete()` method

14.12 `onpayerdetailchange` attribute

15. `PaymentRequest` and `iframe` elements

16.2 `PaymentMethodChangeEvent` interface

16.2.1 `methodDetails` attribute

16.2.2 `methodName` attribute

16.2.3 `PaymentMethodChangeEventInit` dictionary

16.3 `PaymentRequestUpdateEvent` interface

16.3.2 `updateWith()` method

16.3.4 `PaymentRequestUpdateEventInit` dictionary

17.8 Update a `PaymentRequest`'s details algorithm

18.1 User Protections with `show()` method