w3c.github.io
Open in
urlscan Pro
2606:50c0:8002::153
Public Scan
Submitted URL: https://w3c.github.io/payment-request/#dfn-steps-to-validate-payment-method-data
Effective URL: https://w3c.github.io/payment-request/
Submission: On March 17 via api from US — Scanned from DE
Effective URL: https://w3c.github.io/payment-request/
Submission: On March 17 via api from US — Scanned from DE
Form analysis 0 forms found in the DOM
Text Content
↑ Jump to Table of Contents← Collapse Sidebar
ReSpec
* 🔎 Search Specref…
* 📚 Search definitions…
* ℹ️ About 34.5.0…
* 💾 Export…
1
PAYMENT REQUEST API 1.1
W3C Editor's Draft 05 February 2024
More details about this document This version:
https://w3c.github.io/payment-request/ Latest published version:
https://www.w3.org/TR/payment-request-1.1/ Latest editor's
draft:https://w3c.github.io/payment-request/ History:
https://www.w3.org/standards/history/payment-request-1.1/ Commit history Test
suite:https://wpt.live/payment-request/ Implementation report:
https://w3c.github.io/test-results/payment-request/all.html Editors: Marcos
Cáceres (Apple Inc.) Rouslan Solomakhin (Google) Ian Jacobs (W3C) Former
editors: Domenic Denicola (Google) Adrian Bateman (Microsoft Corporation) Zach
Koch (Google) Roy McElmurry (Facebook) Danyao Wang (Google) Feedback: GitHub
w3c/payment-request (pull requests, new issue, open issues) Browser support:
78
79
66
12.1
desktop
122
123
15.5
12.2
12.0
mobile
More info
Copyright © 2024 World Wide Web Consortium. W3C® liability, trademark and
permissive document license rules apply.
--------------------------------------------------------------------------------
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. 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 W3C published Payment Request API 1.0 as a Proposed Recommendation in
September 2021. Since then, W3C has been working to resolve two Formal
Objections from W3C Members; see the Team Report for details. At this time, a
Council is evaluating the Formal Objections to determine whether Payment Request
API 1.0 should advance to Recommendation or be returned to the Working Group for
changes.
In the meantime, the Editors have continued to update this specification with
new features (see change log below). To provide devellopers and implementers
with more confidence about these features, the working group has decided to
formally publish the a new W3C Working Draft. This will also provide the group
with a foundation for potential discussion at TPAC about the future of Payment
Request.
It is not uncommon for a Working Group to work on different revisions of a
specification simultaneously (e.g., see the CSS WG). With that in mind, and
because our current charter anticipates enhancements to Payment Request 1.0,
we've publish this 1.1 draft.
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.
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 an Editor's
Draft.
Publication as an Editor's Draft does not imply endorsement by W3C and its
Members.
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. Future updates to this specification may incorporate new
features.
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 03 November 2023 W3C Process Document.
CHANGES SINCE LAST PUBLICATION
This version of the specification removes data features from the API,
essentially pushing data details to payment method descriptions. The complete
list of changes, including all editorial changes, is viewable in the commit
history. Key set of changes are viewable in the Changelog.
TABLE OF CONTENTS
1. Abstract
2. Status of This Document
1. Changes since last publication
3. 1. Introduction
1. 1.1 Goals and scope
4. 2. Examples of usage
1. 2.1 Declaring multiple ways of paying
2. 2.2 Describing what is being paid for
3. 2.3 Conditional modifications to payment request
4. 2.4 Constructing a PaymentRequest
5. 2.5 POSTing payment response back to a server
6. 2.6 Using with cross-origin iframes
5. 3. PaymentRequest interface
1. 3.1 Constructor
2. 3.2 id attribute
3. 3.3 show() method
4. 3.4 abort() method
5. 3.5 canMakePayment() method
6. 3.6 onpaymentmethodchange attribute
7. 3.7 Internal Slots
6. 4. PaymentMethodData dictionary
7. 5. PaymentCurrencyAmount dictionary
1. 5.1 Validity checkers
8. 6. Payment details dictionaries
1. 6.1 PaymentDetailsBase dictionary
2. 6.2 PaymentDetailsInit dictionary
3. 6.3 PaymentDetailsUpdate dictionary
9. 7. PaymentDetailsModifier dictionary
10. 8. PaymentItem dictionary
11. 9. PaymentCompleteDetails dictionary
12. 10. PaymentComplete enum
13. 11. PaymentResponse interface
1. 11.1 retry() method
1. 11.1.1 PaymentValidationErrors dictionary
2. 11.2 methodName attribute
3. 11.3 details attribute
4. 11.4 requestId attribute
5. 11.5 complete() method
6. 11.6 Internal Slots
14. 12. Permissions Policy integration
15. 13. Events
1. 13.1 Summary
2. 13.2 PaymentMethodChangeEvent interface
1. 13.2.1 methodDetails attribute
2. 13.2.2 methodName attribute
3. 13.2.3 PaymentMethodChangeEventInit dictionary
3. 13.3 PaymentRequestUpdateEvent interface
1. 13.3.1 Constructor
2. 13.3.2 updateWith() method
3. 13.3.3 Internal Slots
4. 13.3.4 PaymentRequestUpdateEventInit dictionary
16. 14. Algorithms
1. 14.1 Can make payment algorithm
2. 14.2 Payment method changed algorithm
3. 14.3 PaymentRequest updated algorithm
4. 14.4 User accepts the payment request algorithm
5. 14.5 User aborts the payment request algorithm
6. 14.6 Update a PaymentRequest's details algorithm
1. 14.6.1 Abort the update
17. 15. Privacy and Security Considerations
1. 15.1 User protections with show() method
2. 15.2 Secure contexts
3. 15.3 Cross-origin payment requests
4. 15.4 Encryption of data fields
5. 15.5 How user agents match payment handlers
6. 15.6 Data usage
7. 15.7 Exposing user information
8. 15.8 canMakePayment() protections
9. 15.9 User activation requirement
18. 16. Accessibility Considerations
19. 17. Dependencies
20. 18. Conformance
21. A. IDL Index
22. B. Acknowledgements
23. C. Changelog
24. D. References
1. D.1 Normative references
2. D.2 Informative references
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: the means that the payer uses to pay the payee (e.g., a
card payment or credit transfer). The payment method provider establishes the
ecosystem to support that payment method.
A payment method defines:
An optional additional data type Optionally, an IDL type that the payment method
expects to receive as the PaymentMethodData's data member. If not specified for
a given payment method, no conversion to IDL is done and the payment method will
receive data as JSON. Steps to validate payment method data Algorithmic steps
that specify how a payment method validates the data member of the
PaymentMethodData, after it is converted to the payment method's additional data
type. If not specified for a given payment method, no validation is done.
The details of how to fulfill a payment request for a given payment method is an
implementation detail of a payment handler, which is an application or service
that handles requests for payment. Concretely, a 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. 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. 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 AND SCOPE
* Allow the user agent to act as intermediary between a merchant, user, and
payment method provider.
* Enable user agents to streamline the user's payment experience by taking into
account user preferences, merchant information, security considerations, and
other factors.
* Standardize (to the extent that it makes sense) the communication flow
between a merchant, user agent, and payment method provider.
* Enable a payment method provider to bring more secure payment transactions to
the web.
The following are out of scope for this specification:
* Create a new payment method.
* Integrate directly with payment processors.
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. Additionally, it can optionally include "modifiers"
to how payments are made. For example, "if you pay with a card belonging to
network X, it incurs a US$3.00 processing fee".
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 DECLARING MULTIPLE WAYS OF PAYING
When constructing a new PaymentRequest, a merchant uses the first argument
(methodData) to list the different ways a user can pay for things (e.g., credit
cards, Apple Pay, Google Pay, etc.). More specifically, the methodData sequence
contains PaymentMethodData dictionaries containing the payment method
identifiers for the payment methods that the merchant accepts and any associated
payment method specific data (e.g., which credit card networks are supported).
Example 1: The `methodData` argument
const methodData = [
{
supportedMethods: "https://example.com/payitforward",
data: {
payItForwardField: "ABC",
},
},
{
supportedMethods: "https://example.com/bobpay",
data: {
merchantIdentifier: "XXXX",
bobPaySpecificField: true,
},
},
];
2.2 DESCRIBING WHAT IS BEING PAID FOR
When constructing a new PaymentRequest, a merchant uses the second argument of
the constructor (details) to provide the details of the transaction that the
user is being asked to complete. This includes the total of the order and,
optionally, some line items that can provide a detailed breakdown of what is
being paid for.
Example 2: The `details` argument
const details = {
id: "super-store-order-123-12312",
displayItems: [
{
label: "Sub-total",
amount: { currency: "GBP", value: "55.00" },
},
{
label: "Value-Added Tax (VAT)",
amount: { currency: "GBP", value: "5.00" },
},
{
label: "Standard shipping",
amount: { currency: "GBP", value: "5.00" },
},
],
total: {
label: "Total due",
// The total is GBP£65.00 here because we need to
// add tax and shipping.
amount: { currency: "GBP", value: "65.00" },
},
};
2.3 CONDITIONAL MODIFICATIONS TO PAYMENT REQUEST
Here we see how to add a processing fee for using a card on a particular
network. Notice that it requires recalculating the total.
Example 3: Modifying payment request based on card type
// Certain cards incur a $3.00 processing fee.
const cardFee = {
label: "Card processing fee",
amount: { currency: "AUD", value: "3.00" },
};
// Modifiers apply when the user chooses to pay with
// a card.
const modifiers = [
{
additionalDisplayItems: [cardFee],
supportedMethods: "https://example.com/cardpay",
total: {
label: "Total due",
amount: { currency: "AUD", value: "68.00" },
},
data: {
supportedNetworks: networks,
},
},
];
Object.assign(details, { modifiers });
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 4: Constructing a `PaymentRequest`
async function doPaymentRequest() {
try {
const request = new PaymentRequest(methodData, details, options);
const response = await request.show();
await validateResponse(response);
} catch (err) {
// AbortError, SecurityError
console.error(err);
}
}
async function validateResponse(response) {
try {
const errors = await checkAllValuesAreGood(response);
if (errors.length) {
await response.retry(errors);
return validateResponse(response);
}
await response.complete("success");
} catch (err) {
// Something went wrong...
await response.complete("fail");
}
}
// Must be called as a result of a click
// or some explicit user action.
doPaymentRequest();
2.5 POSTING PAYMENT RESPONSE BACK TO A SERVER
It's expected that data in a PaymentResponse will be POSTed back to a server for
processing. To make this as easy as possible, PaymentResponse can use the
default toJSON steps (i.e., .toJSON()) to serializes the object directly into
JSON. This makes it trivial to POST the resulting JSON back to a server using
the Fetch Standard:
Example 5: 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();
2.6 USING WITH CROSS-ORIGIN IFRAMES
To indicate that a cross-origin iframe is allowed to invoke the payment request
API, the allow attribute along with the "payment" keyword can be specified on
the iframe element.
Example 6: Using Payment Request API with cross-origin iframes
<iframe
src="https://cross-origin.example"
allow="payment">
</iframe>
If the iframe will be navigated across multiple origins that support the Payment
Request API, then one can set allow to "payment *". The Permissions Policy
specification provides further details and examples.
MDN✅ PaymentRequest
This feature is in all major engines.
Chrome 60+ Chrome Android 53+ Edge 15+ Edge Mobile ? Firefox 55+ Firefox Android
? Opera ? Opera Android 44+ Safari 11.1+ Safari iOS ? Samsung Internet ? WebView
Android No
3. PAYMENTREQUEST INTERFACE
WebIDL[SecureContext, Exposed=Window]
interface PaymentRequest : EventTarget {
constructor(
sequence<PaymentMethodData> methodData,
PaymentDetailsInit details
);
[NewObject]
Promise<PaymentResponse> show(optional Promise<PaymentDetailsUpdate> detailsPromise);
[NewObject]
Promise<undefined> abort();
[NewObject]
Promise<boolean> canMakePayment();
readonly attribute DOMString id;
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).
A request's payment-relevant browsing context is that PaymentRequest's relevant
global object's browsing context's top-level browsing context. Every
payment-relevant browsing context has a payment request is showing boolean,
which prevents showing more than one payment UI at a time.
The payment request is showing boolean simply prevents more than one payment UI
being shown in a single browser tab. However, a payment handler can restrict the
user agent to showing only one payment UI across all browser windows and tabs.
Other payment handlers might allow showing a payment UI across disparate browser
tabs.
MDN✅ PaymentRequest/PaymentRequest
This feature is in all major engines.
Chrome 60+ Chrome Android 53+ Edge 15+ Edge Mobile ? Firefox 55+ Firefox Android
? Opera ? Opera Android 44+ Safari 11.1+ Safari iOS ? Samsung Internet ? WebView
Android No
3.1 CONSTRUCTOR
The PaymentRequest is constructed using the supplied sequence of
PaymentMethodData methodData including any payment method specific data, and the
PaymentDetailsInit details.
The PaymentRequest(methodData, details) constructor MUST act as follows:
tests: 2
* payment-request-constructor 🔒
* payment-request-insecure
1. If this's relevant global object's associated Document is not allowed to
use the "payment" permission, then throw a "SecurityError" DOMException.
2. 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]. tests: 1
* payment-request-id-attribute 🔒
3. Let serializedMethodData be an empty list.
4. 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. Let seenPMIs be the empty set.
3. 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. tests: 1
* payment-request-ctor-pmi-handling 🔒
2. Let pmi be the result of parsing paymentMethod.supportedMethods with
basic URL parser:
1. If failure, set pmi to paymentMethod.supportedMethods.
3. If seenPMIs contains pmi throw a RangeError DOMException optionally
informing the developer that this payment method identifier is a
duplicate.
4. Append pmi to seenPMIs.
5. If the data member of paymentMethod is missing, let serializedData be
null. Otherwise, let serializedData be the result of serialize
paymentMethod.data into a JSON string. Rethrow any exceptions.
6. If serializedData is not null, and if the specification that defines
the paymentMethod.supportedMethods specifies an additional data type:
1. Let object be the result of JSON-parsing serializedData.
2. Let idl be the result of converting object to an IDL value of the
additional data type. Rethrow any exceptions.
3. Run the steps to validate payment method data, if any, from the
specification that defines the paymentMethod.supportedMethods on
object. Rethrow any exceptions.
Note
These step assures that any IDL type conversion and validation
errors are caught as early as possible.
7. Add the tuple (paymentMethod.supportedMethods, serializedData) to
serializedMethodData.
5. Process the total:
1. Check and canonicalize total amount details.total.amount. Rethrow any
exceptions. tests: 1
* payment-request-ctor-currency-code-checks 🔒
6. 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.
tests: 1
* payment-request-ctor-currency-code-checks 🔒
7. Let serializedModifierData be an empty list.
8. 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. tests: 1
* payment-request-ctor-currency-code-checks 🔒
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. tests: 1
* payment-request-ctor-currency-code-checks 🔒
3. If the data member of modifier is missing, let serializedData be
null. Otherwise, let serializedData be the result of serialize
modifier.data into a JSON string. Rethrow any exceptions.
4. Add the tuple (modifier.supportedMethods, serializedData) to
serializedModifierData.
5. Remove the data member of modifier, if it is present.
3. Set details.modifiers to modifiers.
9. Let request be a new PaymentRequest.
10. Set request.[[handler]] to null.
11. Set request.[[state]] to "created".
12. Set request.[[updating]] to false.
13. Set request.[[details]] to details.
14. Set request.[[serializedModifierData]] to serializedModifierData.
15. Set request.[[serializedMethodData]] to serializedMethodData.
16. Set request.[[response]] to null.
17. Return request.
MDN✅ PaymentRequest/id
This feature is in all major engines.
Chrome 60+ Chrome Android ? Edge 16+ Edge Mobile ? Firefox 55+ Firefox Android ?
Opera ? Opera Android ? Safari 11.1+ Safari iOS ? Samsung Internet ? WebView
Android No
3.2 ID ATTRIBUTE
When getting, the id attribute returns this PaymentRequest's [[details]].id.
tests: 1
* payment-request-id-attribute 🔒
Note
For auditing and reconciliation purposes, a merchant can associate a unique
identifier for each transaction with the id attribute.
MDN✅ PaymentRequest/show
This feature is in all major engines.
Chrome 60+ Chrome Android 53+ Edge 15+ Edge Mobile ? Firefox 55+ Firefox Android
? Opera ? Opera Android 44+ Safari 11.1+ Safari iOS ? Samsung Internet ? WebView
Android No
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.
Each payment handler controls what happens when multiple browsing context
simultaneously call the show() method. For instance, some payment handlers will
allow multiple payment UIs to be shown in different browser tabs/windows. Other
payment handlers might only allow a single payment UI to be shown for the entire
user agent.
The show(optional detailsPromise) method MUST act as follows:
tests: 1
* payment-request-show-method 🔒
1. Let request be this.
2. If the relevant global object of request does not have transient
activation, the user agent MAY:
1. Return a promise rejected with with a "SecurityError" DOMException.
Note
This allows the user agent to not require user activation, for example to
support redirect flows where a user activation may not be present upon
redirect. See 15.9 User activation requirement for security considerations.
tests: 2
* payment-request-show-method 🔒
* show-method-postmessage 🔒💪
3. Otherwise, consume user activation of the relevant global object. tests: 1
* show-consume-activation 🔒
4. Let document be request's relevant global object's associated Document.
5. If document is not fully active, then return a promise rejected with an
"AbortError" DOMException. tests: 1
* rejects_if_not_active 🔒
6. If document's visibility state is not "visible", then return a promise
rejected with an "AbortError" DOMException.
7. Optionally, if the user agent wishes to disallow the call to 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 section 15. Privacy and Security
Considerations.
8. If request.[[state]] is not "created" then return a promise rejected with
an "InvalidStateError" DOMException.
9. If the user agent's payment request is showing boolean is true, then:
1. Set request.[[state]] to "closed".
2. Return a promise rejected with an "AbortError" DOMException.
10. Set request.[[state]] to "interactive".
11. Let acceptPromise be a new promise.
12. Set request.[[acceptPromise]] to acceptPromise.
13. 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.
14. Set request's payment-relevant browsing context's payment request is
showing boolean to true.
15. Return acceptPromise and perform the remaining steps in parallel.
16. Let handlers be an empty list.
17. 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 the specification that defines the identifier specifies an additional
data type, then convert data to an IDL value of that type. Otherwise,
convert data to object.
4. If conversion results in an exception error:
1. Set request.[[state]] to "closed".
2. Reject acceptPromise with error.
3. Set request's payment-relevant browsing context's payment request is
showing boolean to false.
4. Terminate this algorithm.
5. Let registeredHandlers be a list of registered payment handlers for the
payment method identifier.
Note: Payment Handler registration
Mechanisms to register a payment handler are outside the scope of this
specification. For one mechanism, see Payment Handler API.
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.
18. If handlers is empty, then:
1. Set request.[[state]] to "closed".
2. Reject acceptPromise with "NotSupportedError" DOMException.
3. Set request's payment-relevant browsing context's payment request is
showing boolean to false.
4. Terminate this algorithm.
19. Present a user interface that will allow the user to interact with the
handlers. The user agent SHOULD prioritize the user's preference when
presenting payment methods. The user interface SHOULD be presented using
the language and locale-based formatting that matches the document's
document element's language, if any, or an appropriate fallback if that is
not available.
Note: Localization of the payments user interface
The API does not currently provide a way for developers to specify the
language and base direction in which the payment sheet is presented to end
users. Instead, the API relies on localization information inherited from
the document.
20. If detailsPromise was passed, then:
1. Run the update a PaymentRequest's details algorithm with detailsPromise,
request, and null.
2. Wait for the detailsPromise to settle.
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.
tests: 1
* show-method-optional-promise-rejects 🔒
21. Set request.[[handler]] be the payment handler selected by the end-user.
22. Let modifiers be an empty list.
23. For each tuple in [[serializedModifierData]]:
1. If the first element of tuple (a PMI) matches the payment method
identifier of request.[[handler]], then append the second element of
tuple (the serialized method data) to modifiers.
24. Pass the converted second element in the paymentMethod tuple and modifiers.
Optionally, the user agent SHOULD send the appropriate data from request to
the user-selected payment handler in order to guide the user through the
payment process. This includes the various attributes and other internal
slots of request (some MAY be excluded for privacy reasons where
appropriate).
Handling of multiple applicable modifiers in the [[serializedModifierData]]
internal slot is payment handler specific and beyond the scope of this
specification. Nevertheless, it is RECOMMENDED that payment handlers use a
"last one wins" approach with items in the [[serializedModifierData]] list:
that is to say, an item at the end of the list always takes precedence over
any item at the beginning of the list (see example below).
Example 7: Handling of multiple applicable modifiers
This example demonstrates precedence order of [[serializedModifierData]].
The first modifier applies equally to all cards, irrespective of network.
The second modifier applies specifically to cards on the "coolcard"
network.
const details = {
total: {
label: "Total due",
amount: { currency: "USD", value: "50.00" },
},
};
// All cards incur a $3.00 processing fee.
const cardFee = {
label: "Card processing fee",
amount: { currency: "USD", value: "3.00" },
};
// But coolcard incurs a $1.00 processing fee.
const coolCardFee = {
label: "Coolcard processing fee",
amount: { currency: "USD", value: "1.00" },
};
// Modifiers apply when the user chooses to pay with
// a credit card.
details.modifiers = [
// Applies to all cards...
{
additionalDisplayItems: [cardFee],
supportedMethods: "https://example.com/cardpay",
total: {
label: "Total due",
amount: { currency: "USD", value: "53.00" },
},
data: {
supportedNetworks: [], // All networks
},
},
// Applies only to cool cards...
{
additionalDisplayItems: [coolCardFee],
supportedMethods: "https://example.com/cardpay",
total: {
label: "Total due",
amount: { currency: "USD", value: "51.00" },
},
data: {
supportedNetworks: ["coolcard"], // coolcard network only
},
},
];
If the modifiers array in the example above was to be reversed (i.e.,
supportedNetworks: [] was to come last in the modifiers list), then it
would take precedence over the "coolcard" modifier even though the coolcard
modifier matches cards more specifically. This is because "last one wins".
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:
tests: 1
* rejects_if_not_active 🔒
1. Close down the user interface.
2. Set request's payment-relevant browsing context's payment request is
showing boolean to false.
MDN✅ PaymentRequest/abort
This feature is in all major engines.
Chrome 60+ Chrome Android 53+ Edge 15+ Edge Mobile ? Firefox 55+ Firefox Android
? Opera ? Opera Android 44+ Safari 11.1+ Safari iOS ? Samsung Internet ? WebView
Android No
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:
tests: 1
* payment-request-abort-method 🔒
1. Let request be this.
2. If request.[[response]] is not null, and
request.[[response]].[[retryPromise]] is not null, return a promise rejected
with an "InvalidStateError" DOMException.
3. If the value of request.[[state]] is not "interactive" then return a promise
rejected with an "InvalidStateError" DOMException.
4. Let promise be a new promise.
5. Return promise and perform the remaining steps in parallel.
6. Try to abort the current user interaction with the payment handler and close
down any remaining user interface.
7. Queue a task on the user interaction task source to perform the following
steps:
1. If it is not possible to abort the current user interaction, then reject
promise with "InvalidStateError" DOMException and abort these steps.
2. Set request.[[state]] to "closed".
3. Reject the promise request.[[acceptPromise]] with an "AbortError"
DOMException.
4. Resolve promise with undefined.
MDN✅ PaymentRequest/canMakePayment
This feature is in all major engines.
Chrome 60+ Chrome Android 53+ Edge 16+ Edge Mobile ? Firefox 55+ Firefox Android
? Opera ? Opera Android 44+ Safari 11.1+ Safari iOS ? Samsung Internet ? WebView
Android No
3.5 CANMAKEPAYMENT() METHOD
Note: canMakePayment()
The canMakePayment() method can be used by the developer to determine if the
user agent has support for one of the desired payment methods. See 15.8
canMakePayment() protections.
A true result from canMakePayment() does not imply that the user has a
provisioned instrument ready for payment.
The canMakePayment() method MUST run the can make payment algorithm.
tests: 1
* payment-request-canmakepayment-method 🔒
MDN✅ PaymentRequest/paymentmethodchange_event
This feature is in all major engines.
Chrome 76+ Chrome Android ? Edge ? Edge Mobile ? Firefox 55+ Firefox Android ?
Opera 47+ Opera Android 44+ Safari 12.1+ Safari iOS ? Samsung Internet ? WebView
Android No
3.6 ONPAYMENTMETHODCHANGE ATTRIBUTE
A PaymentRequest's onpaymentmethodchange attribute is an EventHandler for a
PaymentMethodChangeEvent named "paymentmethodchange".
3.7 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. [[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 if 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. [[handler]] The Payment Handler associated with this
PaymentRequest. Initialized to null.
4. PAYMENTMETHODDATA DICTIONARY
WebIDLdictionary 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 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
WebIDLdictionary PaymentCurrencyAmount {
required DOMString currency;
required DOMString value;
};
A PaymentCurrencyAmount dictionary is used to supply monetary amounts.
currency member
An [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.
When displaying a monetary value, it is RECOMMENDED that user agents display the
currency code, but it's OPTIONAL for user agents to display a currency symbol.
This is because currency symbols can be ambiguous due to use across a number of
different currencies (e.g., "$" could mean any of USD, AUD, NZD, CAD, and so
on.).
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 U+0024 Dollar Sign ($), "GBP" is shown
as U+00A3 Pound Sign (£), "PLN" is shown as U+007A U+0142 Złoty (zł), and the
non-standard "XBT" could be shown as U+0243 Latin Capital Letter B with Stroke
(Ƀ)).
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.
Example 8: How to represent 1.234 Omani rials
{
"currency": "OMR",
"value": "1.234"
}
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:
1. Optionally, a single U+002D (-), to indicate that the amount is negative.
2. One or more code points in the range U+0030 (0) to U+0039 (9).
3. Optionally, a single U+002E (.) followed by one or more code points in the
range U+0030 (0) to U+0039 (9).
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:
1. If the result of IsWellFormedCurrencyCode(amount.currency) is false, then
throw a RangeError exception, optionally informing the developer that the
currency is invalid.
2. If amount.value is not a valid decimal monetary value, throw a TypeError,
optionally informing the developer that the currency is invalid.
3. Set amount.currency to the result of ASCII uppercase amount.currency.
To check and canonicalize total amount given a PaymentCurrencyAmount amount, run
the following steps:
1. Check and canonicalize amount amount. Rethrow any exceptions.
2. 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
The algorithm does not alter or canonicalize the amount.value. For example, a
user agent will not change "55" into "55.00". Payment handlers need to be
prepared to deal with such values.
6. PAYMENT DETAILS DICTIONARIES
6.1 PAYMENTDETAILSBASE DICTIONARY
WebIDLdictionary PaymentDetailsBase {
sequence<PaymentItem> displayItems;
sequence<PaymentDetailsModifier> modifiers;
};
displayItems member A sequence of PaymentItem dictionaries contains line items
for the payment request that the user agent MAY display.
Note
It is the developer's responsibility, when generating or updating a
PaymentRequest, to verify that the total amount is the sum of these items.
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
WebIDLdictionary PaymentDetailsInit : PaymentDetailsBase {
DOMString id;
required PaymentItem total;
};
Note
The PaymentDetailsInit dictionary is used in the construction of the payment
request.
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
WebIDLdictionary PaymentDetailsUpdate : PaymentDetailsBase {
PaymentItem total;
object paymentMethodErrors;
};
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:
total member A PaymentItem containing a non-negative amount.
Note
Algorithms in this specification that accept a PaymentDetailsUpdate dictionary
will throw if the total.amount.value is a negative number.
paymentMethodErrors member
Payment method specific errors.
7. PAYMENTDETAILSMODIFIER DICTIONARY
WebIDLdictionary 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 serialized.
8. PAYMENTITEM DICTIONARY
WebIDLdictionary PaymentItem {
required DOMString label;
required PaymentCurrencyAmount amount;
boolean pending = false;
};
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.
Note: Internationalization of the label
The language and direction of the label may often be determined from information
inherited from the document. However, this approach may not suffice for some use
cases. The working group intends to fix this in a future version by aligning
with general approaches for the Web that are in development.
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.
9. PAYMENTCOMPLETEDETAILS DICTIONARY
WebIDLdictionary PaymentCompleteDetails {
object? data = null;
};
The PaymentCompleteDetails dictionary provides additional information from the
merchant website to the payment handler when the payment request completes.
The PaymentCompleteDetails dictionary contains the following members:
data member An object that provides optional information that might be needed by
the PaymentResponse associated payment method. If supplied, it will be
serialize.
10. PAYMENTCOMPLETE ENUM
WebIDLenum 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.
MDN✅ PaymentResponse
This feature is in all major engines.
Chrome 60+ Chrome Android 53+ Edge 15+ Edge Mobile ? Firefox 55+ Firefox Android
? Opera ? Opera Android ? Safari 11.1+ Safari iOS ? Samsung Internet ? WebView
Android No
11. PAYMENTRESPONSE INTERFACE
WebIDL[SecureContext, Exposed=Window]
interface PaymentResponse : EventTarget {
[Default] object toJSON();
readonly attribute DOMString requestId;
readonly attribute DOMString methodName;
readonly attribute object details;
[NewObject]
Promise<undefined> complete(
optional PaymentComplete result = "unknown",
optional PaymentCompleteDetails details = {}
);
[NewObject]
Promise<undefined> retry(optional PaymentValidationErrors errorFields = {});
};
Note
A PaymentResponse is returned when a user has selected a payment method and
approved a payment request.
MDN✅ PaymentResponse/retry
This feature is in all major engines.
Chrome 78+ Chrome Android ? Edge ? Edge Mobile ? Firefox 55+ Firefox Android ?
Opera 47+ Opera Android 43+ Safari 12.1+ Safari iOS 11.3+ Samsung Internet 10.0+
WebView Android No
11.1 RETRY() METHOD
Note
If a PaymentResponse is found to be erroneous (e.g., a payment instrument has
expired or shipping information is invalid), the retry() method affords the end
user the ability to fix input errors and try to get the merchant to processed
the payment again. The passed PaymentValidationErrors serve as hints as to where
input errors have occurred in the PaymentResponse, which the end user needs to
correct.
However, an end user may decide, upon inspection of the PaymentValidationErrors,
to provide an entirely new set of values for the PaymentResponse. For example,
the user might switch to a an entirely different payment instrument and/or
provide an entirely different shipping address.
As such, merchants need to be prepared to completely revalidate a
PaymentResponse once the [[retryPromise]] settles.
Lastly, as a PaymentResponse is inherently tied to a particular payment handler
via a PaymentRequest, it is not possible for the end user to switch to a
different payment handler during retry().
The retry(errorFields) method MUST act as follows:
1. Let response be this.
2. Let request be response.[[request]].
3. Let document be request's relevant global object's associated Document.
4. If document is not fully active, then return a promise rejected with an
"AbortError" DOMException. tests: 1
* rejects_if_not_active 🔒💪
5. If response.[[complete]] is true, return a promise rejected with an
"InvalidStateError" DOMException.
6. If response.[[retryPromise]] is not null, return a promise rejected with an
"InvalidStateError" DOMException.
7. Set request.[[state]] to "interactive".
8. Let retryPromise be a new promise.
9. Set response.[[retryPromise]] to retryPromise.
10. If errorFields was passed:
1. If errorFields.paymentMethod member was passed, and if required by the
specification that defines response.methodName, then convert
errorFields's paymentMethod member to an IDL value of the type specified
there. Otherwise, convert to object. tests: 1
* retry-shows-error-member 🔒💪
2. Set request's payment-relevant browsing context's payment request is
showing boolean to false.
3. 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.
4. 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. In the case where the value of a member is the
empty string, the user agent MAY substitute a value with a suitable
error message.
11. Otherwise, if errorFields was not passed, signal to the end user to attempt
to retry the payment. Re-enable any UI element that affords the end user
the ability to retry accepting the payment request.
12. If document stops being fully active while the user interface is being
shown, or no longer is by the time this step is reached, then: tests: 1
* rejects_if_not_active 🔒💪
1. Close down the user interface.
2. Set request's payment-relevant browsing context's payment request is
showing boolean to false.
13. Finally, when retryPromise settles, set response.[[retryPromise]] to null.
14. 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.
11.1.1 PAYMENTVALIDATIONERRORS DICTIONARY
WebIDLdictionary PaymentValidationErrors {
DOMString error;
object paymentMethod;
};
error member A general description of an error with the payment from which the
user can attempt to recover. For example, the user may recover by retrying the
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.
Note: Internationalization of the error
The language and direction of the error may often be determined from information
inherited from the document. However, this approach may not suffice for some use
cases. The working group intends to fix this in a future version by aligning
with general approaches for the Web that are in development.
paymentMethod member A payment method specific errors.
MDN✅ PaymentResponse/methodName
This feature is in all major engines.
Chrome 60+ Chrome Android 53+ Edge 15+ Edge Mobile ? Firefox 55+ Firefox Android
? Opera ? Opera Android ? Safari 11.1+ Safari iOS ? Samsung Internet ? WebView
Android No
11.2 METHODNAME ATTRIBUTE
The payment method identifier for the payment method that the user selected to
fulfill the transaction.
tests: 1
* methodName-attribute 🔒💪
MDN✅ PaymentResponse/details
This feature is in all major engines.
Chrome 60+ Chrome Android 53+ Edge 15+ Edge Mobile ? Firefox 55+ Firefox Android
? Opera ? Opera Android ? Safari 11.1+ Safari iOS ? Samsung Internet ? WebView
Android No
11.3 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 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.
MDN✅ PaymentResponse/requestId
This feature is in all major engines.
Chrome 60+ Chrome Android ? Edge 16+ Edge Mobile ? Firefox 55+ Firefox Android ?
Opera ? Opera Android 43+ Safari 11.1+ Safari iOS ? Samsung Internet ? WebView
Android No
11.4 REQUESTID ATTRIBUTE
The corresponding payment request id that spawned this payment response.
tests: 1
* requestId-attribute 🔒💪
MDN✅ PaymentResponse/complete
This feature is in all major engines.
Chrome 60+ Chrome Android 53+ Edge 15+ Edge Mobile ? Firefox 55+ Firefox Android
? Opera ? Opera Android ? Safari 11.1+ Safari iOS ? Samsung Internet ? WebView
Android No
11.5 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 SHOULD
NOT offer a cancel command because acceptance of the payment request has been
returned. However, if something goes wrong and the developer never calls
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() method MUST act as follows:
tests: 1
* complete-method 🔒💪
1. Let response be this.
2. If response.[[complete]] is true, return a promise rejected with an
"InvalidStateError" DOMException.
3. If response.[[retryPromise]] is not null, return a promise rejected with an
"InvalidStateError" DOMException.
4. Let promise be a new promise.
5. Let serializedData be the result of serialize details.data into a JSON
string.
6. If serializing throws an exception, return a promise rejected with that
exception.
7. If required by the specification that defines the response.methodName:
1. Let json be the result of calling JSON's parse() with serializedData.
2. Let idl be the result of converting json to an IDL value of the type
specified by the specification that defines the response.methodName.
3. If the conversion to an IDL value throws an exception, return a promise
rejected with that exception.
4. If required by the specification that defines the response.methodName,
validate the members of idl. If a member's value is invalid, return a
promise rejected with a TypeError.
Note: Opportunity to recover
The steps above assures that errors that could result from IDL type
conversion and/or validation are caught as early as possible, giving the
developer an opportunity to recover.
8. Set response.[[complete]] to true.
9. Return promise and perform the remaining steps in parallel.
10. 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 request's payment-relevant browsing context's payment request is
showing boolean to false.
11. Otherwise:
1. Close down any remaining user interface. The user agent MAY use the
value result and serializedData to influence the user experience.
2. Set request's payment-relevant browsing context's payment request is
showing boolean to false.
3. Resolve promise with undefined.
11.6 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.
MDN Headers/Feature-Policy/payment
Chrome 60+ Chrome Android ? Edge ? Edge Mobile ? Firefox 74+ Firefox Android ?
Opera ? Opera Android ? Safari No Safari iOS ? Samsung Internet ? WebView
Android ?
MDN🚫 Headers/Permissions-Policy/payment
This feature has limited support.
Chrome ? Chrome Android ? Edge ? Edge Mobile ? Firefox 74+ Firefox Android ?
Opera ? Opera Android ? Safari No Safari iOS ? Samsung Internet ? WebView
Android ?
12. PERMISSIONS POLICY INTEGRATION
This specification defines a policy-controlled feature identified by the string
"payment" [permissions-policy]. Its default allowlist is 'self'.
Note
A document’s permissions policy determines whether any content in that document
is allowed to construct PaymentRequest instances. If disabled in any document,
no content in the document will be allowed to use the PaymentRequest constructor
(trying to create an instance will throw).
13. EVENTS
MDN✅ PaymentRequest/paymentmethodchange_event
This feature is in all major engines.
Chrome 76+ Chrome Android ? Edge ? Edge Mobile ? Firefox 55+ Firefox Android ?
Opera 47+ Opera Android 44+ Safari 12.1+ Safari iOS ? Samsung Internet ? WebView
Android No
13.1 SUMMARY
This section is non-normative.
Event name Interface Dispatched when… Target paymentmethodchange
PaymentMethodChangeEvent The user chooses a different payment method within a
payment handler. PaymentRequest
MDN✅ PaymentMethodChangeEvent
This feature is in all major engines.
Chrome 76+ Chrome Android ? Edge ? Edge Mobile ? Firefox 55+ Firefox Android ?
Opera ? Opera Android ? Safari 12.1+ Safari iOS ? Samsung Internet ? WebView
Android No
MDN✅ PaymentMethodChangeEvent/PaymentMethodChangeEvent
This feature is in all major engines.
Chrome 76+ Chrome Android ? Edge ? Edge Mobile ? Firefox 55+ Firefox Android ?
Opera ? Opera Android ? Safari 12.1+ Safari iOS ? Samsung Internet ? WebView
Android No
13.2 PAYMENTMETHODCHANGEEVENT INTERFACE
WebIDL[SecureContext, Exposed=Window]
interface PaymentMethodChangeEvent : PaymentRequestUpdateEvent {
constructor(DOMString type, optional PaymentMethodChangeEventInit eventInitDict = {});
readonly attribute DOMString methodName;
readonly attribute object? methodDetails;
};
MDN✅ PaymentMethodChangeEvent/methodDetails
This feature is in all major engines.
Chrome 76+ Chrome Android ? Edge ? Edge Mobile ? Firefox 55+ Firefox Android ?
Opera ? Opera Android ? Safari 12.1+ Safari iOS ? Samsung Internet ? WebView
Android No
13.2.1 METHODDETAILS ATTRIBUTE
When getting, returns the value it was initialized with. See methodDetails
member of PaymentMethodChangeEventInit for more information.
MDN✅ PaymentMethodChangeEvent/methodName
This feature is in all major engines.
Chrome 76+ Chrome Android ? Edge ? Edge Mobile ? Firefox 55+ Firefox Android ?
Opera ? Opera Android ? Safari 12.1+ Safari iOS ? Samsung Internet ? WebView
Android No
13.2.2 METHODNAME ATTRIBUTE
When getting, returns the value it was initialized with. See methodName member
of PaymentMethodChangeEventInit for more information.
13.2.3 PAYMENTMETHODCHANGEEVENTINIT DICTIONARY
WebIDLdictionary PaymentMethodChangeEventInit : PaymentRequestUpdateEventInit {
DOMString methodName = "";
object? methodDetails = null;
};
methodName member A string representing the payment method identifier.
methodDetails member An object representing some data from the payment method,
or null.
MDN✅ PaymentRequestUpdateEvent
This feature is in all major engines.
Chrome 60+ Chrome Android 53+ Edge 15+ Edge Mobile ? Firefox 55+ Firefox Android
? Opera ? Opera Android ? Safari 11.1+ Safari iOS ? Samsung Internet ? WebView
Android No
13.3 PAYMENTREQUESTUPDATEEVENT INTERFACE
WebIDL[SecureContext, Exposed=Window]
interface PaymentRequestUpdateEvent : Event {
constructor(DOMString type, optional PaymentRequestUpdateEventInit eventInitDict = {});
undefined updateWith(Promise<PaymentDetailsUpdate> detailsPromise);
};
The PaymentRequestUpdateEvent enables developers to update the details of the
payment request in response to a user interaction.
MDN✅ PaymentRequestUpdateEvent/PaymentRequestUpdateEvent
This feature is in all major engines.
Chrome 60+ Chrome Android 53+ Edge 15+ Edge Mobile ? Firefox 55+ Firefox Android
? Opera ? Opera Android ? Safari 11.1+ Safari iOS ? Samsung Internet ? WebView
Android No
13.3.1 CONSTRUCTOR
The PaymentRequestUpdateEvent's constructor(type, eventInitDict) MUST act as
follows:
tests: 2
* constructor 🔒
* constructor
1. Let event be the result of calling the constructor of
PaymentRequestUpdateEvent with type and eventInitDict.
2. Set event.[[waitForUpdate]] to false.
3. Return event.
MDN✅ PaymentRequestUpdateEvent/updateWith
This feature is in all major engines.
Chrome 60+ Chrome Android 53+ Edge 15+ Edge Mobile ? Firefox 55+ Firefox Android
? Opera ? Opera Android ? Safari 11.1+ Safari iOS ? Samsung Internet ? WebView
Android No
13.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().
Additionally, [[waitForUpdate]] prevents reuse of PaymentRequestUpdateEvent.
The updateWith() with detailsPromise method MUST act as follows:
tests: 1
* updatewith-method 🔒
1. Let event be this.
2. If event's isTrusted attribute is false, then throw an "InvalidStateError"
DOMException.
3. If event.[[waitForUpdate]] is true, then throw an "InvalidStateError"
DOMException.
4. If event's target is an instance of PaymentResponse, let request be event's
target's [[request]].
5. Otherwise, let request be the value of event's target.
6. Assert: request is an instance of PaymentRequest.
7. If request.[[state]] is not "interactive", then throw an
"InvalidStateError" DOMException.
8. If request.[[updating]] is true, then throw an "InvalidStateError"
DOMException.
9. Set event's stop propagation flag and stop immediate propagation flag.
10. Set event.[[waitForUpdate]] to true.
11. Let pmi be null.
12. If event has a methodName attribute, set pmi to the methodName attribute's
value.
13. Run the update a PaymentRequest's details algorithm with detailsPromise,
request, and pmi.
13.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.
13.3.4 PAYMENTREQUESTUPDATEEVENTINIT DICTIONARY
WebIDLdictionary PaymentRequestUpdateEventInit : EventInit {};
14. 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.
14.1 CAN MAKE PAYMENT ALGORITHM
The can make payment algorithm checks if the user agent supports making payment
with the payment methods with which the PaymentRequest was constructed.
1. Let request be the PaymentRequest object on which the method was called.
2. If request.[[state]] is not "created", then return a promise rejected with
an "InvalidStateError" DOMException.
3. Optionally, at the top-level browsing context'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 calling method for fingerprinting purposes, such as creating
PaymentRequest objects with a variety of supported payment methods and
triggering the can make payment algorithm on them one after the other. For
example, a user agent may restrict the number of successful calls that can
be made based on the top-level browsing context or the time period in which
those calls were made.
4. Let hasHandlerPromise be a new promise.
5. Return hasHandlerPromise, and perform the remaining steps in parallel.
6. For each paymentMethod tuple in request. [[serializedMethodData]]:
1. Let identifier be the first element in the paymentMethod tuple.
2. If the user agent has a payment handler that supports handling payment
requests for identifier, resolve hasHandlerPromise with true and
terminate this algorithm.
7. Resolve hasHandlerPromise with false.
14.2 PAYMENT METHOD CHANGED ALGORITHM
A payment handler MAY run the payment method changed algorithm when the user
changes payment method with methodDetails, which is a dictionary or an object or
null, and a methodName, which is a DOMString that represents the payment method
identifier of the payment handler the user is interacting with.
1. Let request be the PaymentRequest object that the user is interacting with.
2. Queue a task on the user interaction task source to run the following steps:
1. Assert: request.[[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.
14.3 PAYMENTREQUEST UPDATED ALGORITHM
The PaymentRequest updated algorithm is run by other algorithms above to fire an
event to indicate that a user has made a change to a PaymentRequest called
request with an event name of name:
1. Assert: request.[[updating]] is false. Only one update can take place at a
time.
2. Assert: request.[[state]] is "interactive".
3. Let event be the result of creating an event using the
PaymentRequestUpdateEvent interface.
4. Initialize event's type attribute to name.
5. Dispatch event at request.
6. If event.[[waitForUpdate]] is true, disable any part of the user interface
that could cause another update event to be fired.
7. Otherwise, set event.[[waitForUpdate]] to true.
14.4 USER ACCEPTS THE PAYMENT REQUEST ALGORITHM
The user accepts the payment request algorithm runs when the user accepts the
payment request and confirms that they want to pay. It MUST queue a task on the
user interaction task source to perform the following steps:
1. Let request be the PaymentRequest object that the user is interacting with.
2. If the request.[[updating]] is true, then terminate this algorithm and take
no further action. The user agent user interface SHOULD ensure that this
never occurs.
3. If request.[[state]] is not "interactive", then terminate this algorithm
and take no further action. The user agent user interface SHOULD ensure
that this never occurs.
4. Let isRetry be true if request.[[response]] is not null, false otherwise.
5. Let response be request.[[response]] if isRetry is true, or a new
PaymentResponse otherwise.
6. If isRetry is 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.
7. Let handler be request.[[handler]].
8. Set the methodName attribute value of response to the payment method
identifier of handler.
9. Set the details attribute value of response to an object resulting from
running the handler's steps to respond to a payment request.
10. Set request.[[state]] to "closed".
11. If isRetry is true, resolve response.[[retryPromise]] with undefined.
Otherwise, resolve request.[[acceptPromise]] with response.
14.5 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:
tests: 1
* user-abort-algorithm 🔒💪
1. Let request be the PaymentRequest object that the user is interacting with.
2. 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.
3. Set request.[[state]] to "closed".
4. Set request's payment-relevant browsing context's payment request is showing
boolean to false.
5. Let error be an "AbortError" DOMException.
6. Let response be request.[[response]].
7. If response is not null:
1. Set response.[[complete]] to true.
2. Assert: response.[[retryPromise]] is not null.
3. Reject response.[[retryPromise]] with error.
8. Otherwise, reject request.[[acceptPromise]] with error.
9. Abort the current user interaction and close down any remaining user
interface.
14.6 UPDATE A PAYMENTREQUEST'S DETAILS ALGORITHM
The update a PaymentRequest's details algorithm takes a PaymentDetailsUpdate
detailsPromise, a PaymentRequest request, and pmi that is either a DOMString or
null (a payment method identifier). The steps are conditional on the
detailsPromise settling. If detailsPromise never settles then the payment
request is blocked. The user agent SHOULD provide the user with a means to abort
a payment request. Implementations MAY choose to implement a timeout for pending
updates if detailsPromise doesn't settle in a reasonable amount of time.
In the case where a timeout occurs, or the user manually aborts, or the payment
handler decides to abort this particular payment, the user agent MUST run the
user aborts the payment request algorithm.
1. Set request.[[updating]] to true.
2. In parallel, disable the user interface that allows the user to accept the
payment request. This is to ensure that the payment is not accepted until
the user interface is updated with any new details.
3. Upon rejection of detailsPromise:
1. Abort the update with request and an "AbortError" DOMException.
4. Upon fulfillment of detailsPromise with value value:
1. Let details be the result of converting value to a PaymentDetailsUpdate
dictionary. If this throw an exception, abort the update with request and
with the thrown exception.
2. Let serializedModifierData be an empty list.
3. 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 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:
1. 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:
1. 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 serialize
modifier.data into a JSON string. If it throws an exception,
then abort the update with request and that exception.
5. Add serializedData to serializedModifierData.
6. Remove the data member of modifier, if it is present.
4. If the paymentMethodErrors member is present and identifier is not null:
1. If required by the specification that defines the pmi, then convert
paymentMethodErrors to an IDL value.
2. If conversion results in a exception error, abort the update with
error.
3. The payment handler SHOULD display an error for each relevant
erroneous field of paymentMethodErrors.
5. 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 modifiers member of details is present, then:
1. Set request.[[details]].modifiers to details.modifiers.
2. Set request.[[serializedModifierData]] to serializedModifierData.
5. Set request.[[updating]] to false.
6. Update the user interface based on any changed values in request. Re-enable
user interface elements disabled prior to running this algorithm.
14.6.1 ABORT THE UPDATE
To abort the update with a PaymentRequest request and exception exception:
1. Optionally, show an error message to the user when letting them know an
error has occurred.
2. Abort the current user interaction and close down any remaining user
interface.
3. Queue a task on the user interaction task source to perform the following
steps:
1. Set request's payment-relevant browsing context'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.
4. 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 PaymentResponse's [[complete]] internal slot
will be set to true (i.e., it can no longer be used).
15. PRIVACY AND SECURITY CONSIDERATIONS
15.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 invoked
while the relevant Window has transient activation (e.g., via a click or press).
To avoid a confusing user experience, this specification limits the user agent
to displaying one at a time via the show() method. In addition, the user agent
can limit the rate at which a page can call show().
15.2 SECURE CONTEXTS
This section is non-normative.
The API defined in this specification is only exposed in a secure context - see
also the Secure Contexts specification for more details. In practice, this means
that this API is only available over HTTPS. This is to limit the possibility of
payment method data (e.g., credit card numbers) being sent in the clear.
15.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 allow attribute.
Payment handlers have access to both the origin that hosts the iframe and the
origin of the iframe content (where the PaymentRequest initiates).
15.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.
15.5 HOW USER AGENTS MATCH PAYMENT HANDLERS
This section is non-normative.
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.
15.6 DATA USAGE
Payment method owners establish the privacy policies for how user data collected
for the payment method may be used. Payment Request API sets a clear expectation
that data will be used for the purposes of completing a transaction, and user
experiences associated with this API convey that intention. It is the
responsibility of the payee to ensure that any data usage conforms to payment
method policies. For any permitted usage beyond completion of the transaction,
the payee should clearly communicate that usage to the user.
15.7 EXPOSING USER INFORMATION
The user agent MUST NOT share information about the user with a developer
without user consent.
In particular, the PaymentMethodData's data and PaymentResponse's details
members allow for the arbitrary exchange of data. In light of the wide range of
data models used by existing payment methods, prescribing data specifics in this
API would limit its usefulness. The details member carries data from the payment
handler, whether Web-based (as defined by the Payment Handler API) or
proprietary. The user agent MUST NOT support payment handlers unless they
include adequate user consent mechanisms (such as awareness of parties to the
transaction and mechanisms for demonstrating the intention to share data).
The user agent MUST NOT share the values of the displayItems member or
additionalDisplayItems member for any purpose other than to facilitate
completion of the transaction.
The PaymentMethodChangeEvent enables the payee to update the displayed total
based on information specific to a selected payment method. For example, the
billing address associated with a selected payment method might affect the tax
computation (e.g., VAT), and it is desirable that the user interface accurately
display the total before the payer completes the transaction. At the same time,
it is desirable to share as little information as possible prior to completion
of the payment. Therefore, when a payment method defines the steps for when a
user changes payment method, it is important to minimize the data shared via the
PaymentMethodChangeEvent's methodDetails attribute. Requirements and approaches
for minimizing shared data are likely to vary by payment method.
Where sharing of privacy-sensitive information might not be obvious to users
(e.g., when changing payment methods), it is RECOMMENDED that user agents inform
the user of exactly what information is being shared with a merchant.
15.8 CANMAKEPAYMENT() PROTECTIONS
The canMakePayment() method provides feature detection for different payment
methods. It may become a fingerprinting vector if in the future, a large number
of payment methods are available. User agents are expected to protect the user
from abuse of the method. For example, user agents can reduce user
fingerprinting by:
* Rate-limiting the frequency of calls with different parameters.
For rate-limiting the user agent might look at repeated calls from:
* the same registrable domain.
* the top-level browsing context. Alternatively, the user agent may block
access to the API entirely for origins known to be bad actors.
* the origin of an iframe or popup window.
These rate-limiting techniques intend to increase the cost associated with
repeated calls, whether it is the cost of managing multiple registrable domains
or the user experience friction of opening multiple windows (tabs or pop-ups).
15.9 USER ACTIVATION REQUIREMENT
If the user agent does not require user activation as part of the show() method,
some additional security mitigations should be considered. Not requiring user
activation increases the risk of spam and click-jacking attacks, by allowing a
Payment Request UI to be initiated without the user interacting with the page
immediately beforehand.
In order to mitigate spam, the user agent may decide to enforce a user
activation requirement after some threshold, for example after the user has
already been shown a Payment Request UI without a user activation on the current
page. In order to mitigate click-jacking attacks, the user agent may implement a
time threshold in which clicks are ignored immediately after a dialog is shown.
Another relevant mitigation exists in step 6 of show(), where the document must
be visible in order to initiate the user interaction.
16. ACCESSIBILITY CONSIDERATIONS
This section is non-normative.
For the user-facing aspects of Payment Request API, implementations integrate
with platform accessibility APIs via form controls and other input modalities.
17. DEPENDENCIES
This specification relies on several other underlying specifications.
ECMAScript The term internal slot is defined [ECMASCRIPT].
18. 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, OPTIONAL, RECOMMENDED, SHOULD, and SHOULD NOT
in this document are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown here.
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
WebIDL[SecureContext, Exposed=Window]
interface PaymentRequest : EventTarget {
constructor(
sequence<PaymentMethodData> methodData,
PaymentDetailsInit details
);
[NewObject]
Promise<PaymentResponse> show(optional Promise<PaymentDetailsUpdate> detailsPromise);
[NewObject]
Promise<undefined> abort();
[NewObject]
Promise<boolean> canMakePayment();
readonly attribute DOMString id;
attribute EventHandler onpaymentmethodchange;
};
dictionary PaymentMethodData {
required DOMString supportedMethods;
object data;
};
dictionary PaymentCurrencyAmount {
required DOMString currency;
required DOMString value;
};
dictionary PaymentDetailsBase {
sequence<PaymentItem> displayItems;
sequence<PaymentDetailsModifier> modifiers;
};
dictionary PaymentDetailsInit : PaymentDetailsBase {
DOMString id;
required PaymentItem total;
};
dictionary PaymentDetailsUpdate : PaymentDetailsBase {
PaymentItem total;
object paymentMethodErrors;
};
dictionary PaymentDetailsModifier {
required DOMString supportedMethods;
PaymentItem total;
sequence<PaymentItem> additionalDisplayItems;
object data;
};
dictionary PaymentItem {
required DOMString label;
required PaymentCurrencyAmount amount;
boolean pending = false;
};
dictionary PaymentCompleteDetails {
object? data = null;
};
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;
[NewObject]
Promise<undefined> complete(
optional PaymentComplete result = "unknown",
optional PaymentCompleteDetails details = {}
);
[NewObject]
Promise<undefined> retry(optional PaymentValidationErrors errorFields = {});
};
dictionary PaymentValidationErrors {
DOMString error;
object paymentMethod;
};
[SecureContext, Exposed=Window]
interface PaymentMethodChangeEvent : PaymentRequestUpdateEvent {
constructor(DOMString type, optional PaymentMethodChangeEventInit eventInitDict = {});
readonly attribute DOMString methodName;
readonly attribute object? methodDetails;
};
dictionary PaymentMethodChangeEventInit : PaymentRequestUpdateEventInit {
DOMString methodName = "";
object? methodDetails = null;
};
[SecureContext, Exposed=Window]
interface PaymentRequestUpdateEvent : Event {
constructor(DOMString type, optional PaymentRequestUpdateEventInit eventInitDict = {});
undefined 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. CHANGELOG
Changes from between CR2 until now:
* [Spec] Relax user activation requirement for show() (#1009)
* [Spec] Only allow show() to be called in a foreground tab (#1005)
* [Spec] Fix broken reference to permissions-policy (#1007)
* remove note since in practice we have a 1.1 branch (#1001)
* Define concepts for converting and validating `.data` (#977)
* passing data on complete() (#982)
* Validate .data on construction (#976)
* Add internationalization support for human readable labels (#971)
* Don't set state to closed when transient acttivation rejects
* Reject with SecurityError when no transient activation (#961)
* Drop PaymentAddress, shipping + billing address support (#955)
* Recommend Payment UI matches doc's language (#944)
* Drop metion of ¤
* Added based on issue 936 (#937)
* Consume user activation (#916)
* Remove hasEnrolledInstrument() (#930)
* Remove merchant validation (#929)
* Deprecate allowpaymentrequest attribute (#928)
* Remove recommendation to localize sheet based on body element (#896)
* Remove requirement to reject after document is inactive (#875)
* Add PaymentRequest.prototype.hasEnrolledInstrument() (#833)
Changes from between CR1 and CR2:
* Changes stemming from privacy review: (#856)
* Set [[waitForUpdate]] to true on dispatch of payerdetailchange (#857)
* Add privacy protection to MerchantValidationEvent's validationURL (#850)
* Describe privacy inplications of changing payment method (#849)
* Redact dependentLocality from shippingAddress (#846)
* Changes resulting from 28 February PING privacy review (#843)
* Do .data IDL conversion in constructor (#829)
* Integrate with Feature Policy (#822)
* Remove regionCode attribute (#823)
* Clarify retry() when errorFields are not passed (#825)
* Attach 'payment request is showing boolean' to top-level browsing con…
* Clarify when the user can abort the payment request algorithm (#810)
* Warn when errorFields don't match request[[options]] (#807)
* Support requesting billing address (#749)
* Added section and paragraph on accessibility considerations (#802)
* Change what canMakePayment() means (#806)
* Remove PaymentAddress' languageCode (#765)
* Remove PaymentItem.type (#794)
* Rename PayerErrorFields to PayerErrors (#789)
* Add paymentMethodErrors, payerErrors, to PaymentDetailsUpdate (#768)
* Add MerchantValidationEvent.prototype.methodName (#776)
* Add support for merchant validation (#751)
* Support fine-grained errors for payment methods (#752)
* Add error member to PaymentValidationErrors (#747)
* Check doc fully active during response.complete() (#748)
* Drop prefixes, suffixes from error field members (#745)
* Added information about redactList to privacy consideration (#738)
* Add PaymentResponse.prototype.onpayerdetailchange (#724)
* retry() interacting with abort the update (#723)
* teach retry() about payerErrors (#721)
* Define PaymentResponse.prototype.retry() method (#720)
* add PaymentMethodChangeEvent event (#695)
* Add fine-grained errors reporting for PaymentAddress (#712)
* add PaymentAddress.regionCode attribute (#690)
* remove currencySystem member (#694)
* add redactList for PaymentAddress (#654)
* show() must be triggered by user activation
* Feat: allow show() to take optional detailsPromise
* Feat: adds PaymentItemType enum + PaymentItem.type (#666)
* Add localization hint for payment sheet (#656)
* Return event, because useful
* privacy: dont share line items (#670)
* Assure PaymentRequest.id is a UUID (closes #588)
D. REFERENCES
D.1 NORMATIVE REFERENCES
[dom] DOM Standard. Anne van Kesteren. WHATWG. Living Standard. URL:
https://dom.spec.whatwg.org/ [ecma-402] ECMAScript Internationalization API
Specification. Ecma International. URL: https://tc39.es/ecma402/ [ECMASCRIPT]
ECMAScript Language Specification. Ecma International. URL:
https://tc39.es/ecma262/multipage/ [fetch] Fetch Standard. Anne van Kesteren.
WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/ [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/ [ISO4217] Currency codes - ISO 4217. ISO. 2015.
International Standard. URL:
http://www.iso.org/iso/home/standards/currency_codes.htm [payment-handler]
Payment Handler API. Adrian Hope-Bailie; Ian Jacobs; Rouslan Solomakhin; Jinho
Bang. W3C. 25 January 2023. W3C Working Draft. URL:
https://www.w3.org/TR/payment-handler/ [payment-method-id] Payment Method
Identifiers. Marcos Caceres. W3C. 8 September 2022. W3C Recommendation. URL:
https://www.w3.org/TR/payment-method-id/ [permissions-policy] Permissions
Policy. Ian Clelland. W3C. 18 December 2023. W3C Working Draft. URL:
https://www.w3.org/TR/permissions-policy-1/ [RFC2119] Key words for use in RFCs
to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current
Practice. URL: https://www.rfc-editor.org/rfc/rfc2119 [RFC4122] A Universally
Unique IDentifier (UUID) URN Namespace. P. Leach; M. Mealling; R. Salz. IETF.
July 2005. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc4122
[RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba.
IETF. May 2017. Best Current Practice. URL:
https://www.rfc-editor.org/rfc/rfc8174 [url] URL Standard. Anne van Kesteren.
WHATWG. Living Standard. URL: https://url.spec.whatwg.org/ [WEBIDL] Web IDL
Standard. Edgar Chen; Timothy Gu. WHATWG. Living Standard. URL:
https://webidl.spec.whatwg.org/
D.2 INFORMATIVE REFERENCES
[rfc6454] The Web Origin Concept. A. Barth. IETF. December 2011. Proposed
Standard. URL: https://www.rfc-editor.org/rfc/rfc6454 [secure-contexts] Secure
Contexts. Mike West. W3C. 10 November 2023. W3C Candidate Recommendation. URL:
https://www.w3.org/TR/secure-contexts/
↑
Permalink
Referenced in:
* § 1. Introduction (2) (3) (4)
* § 1.1 Goals and scope
* § 2. Examples of usage
* § 2.1 Declaring multiple ways of paying (2)
* § 3.1 Constructor (2)
* § 3.5 canMakePayment() method
* § 4. PaymentMethodData dictionary (2) (3)
* § 6.3 PaymentDetailsUpdate dictionary
* § 7. PaymentDetailsModifier dictionary (2)
* § 9. PaymentCompleteDetails dictionary
* § 11.2 methodName attribute
* § 11.3 details attribute (2)
* § 13.1 Summary
* § 14.1 Can make payment algorithm (2)
* § 14.2 Payment method changed algorithm
* § 15.4 Encryption of data fields (2)
* § 15.6 Data usage
* § 15.7 Exposing user information (2) (3) (4)
Permalink
Referenced in:
* § 1.1 Goals and scope (2) (3)
Permalink
Referenced in:
* § 1. Introduction
* § 3.1 Constructor (2)
* § 3.3 show() method
Permalink
Referenced in:
* § 3.1 Constructor
Permalink exported
Referenced in:
* § 3. PaymentRequest interface
* § 3.3 show() method (2) (3) (4)
* § 3.4 abort() method
* § 3.7 Internal Slots
* § 11.1 retry() method (2)
* § 13.1 Summary
* § 14.1 Can make payment algorithm
* § 14.2 Payment method changed algorithm (2)
* § 14.6 Update a PaymentRequest's details algorithm (2)
* § 15.3 Cross-origin payment requests
* § 15.5 How user agents match payment handlers
Permalink
Referenced in:
* § 3.3 show() method
Permalink
Referenced in:
* § 14.4 User accepts the payment request algorithm
Permalink
Referenced in:
* § 15.7 Exposing user information
Permalink exported IDL
Referenced in:
* § 2. Examples of usage (2)
* § 2.1 Declaring multiple ways of paying
* § 2.2 Describing what is being paid for
* § 2.4 Constructing a PaymentRequest
* § 3. PaymentRequest interface (2) (3) (4)
* § 3.1 Constructor (2)
* § 3.2 id attribute
* § 3.6 onpaymentmethodchange attribute
* § 3.7 Internal Slots (2) (3)
* § 6.1 PaymentDetailsBase dictionary
* § 11.1 retry() method
* § 11.6 Internal Slots
* § 12. Permissions Policy integration (2)
* § 13.1 Summary
* § 13.3.2 updateWith() method
* § 14. Algorithms
* § 14.1 Can make payment algorithm (2) (3)
* § 14.2 Payment method changed algorithm
* § 14.3 PaymentRequest updated algorithm
* § 14.4 User accepts the payment request algorithm
* § 14.5 User aborts the payment request algorithm
* § 14.6 Update a PaymentRequest's details algorithm (2) (3)
* § 14.6.1 Abort the update
* § 15.3 Cross-origin payment requests
* § 15.4 Encryption of data fields
* § A. IDL Index
Permalink exported
Referenced in:
* Not referenced in this document.
Permalink
Referenced in:
* § 3. PaymentRequest interface
* § 3.3 show() method (2) (3) (4)
* § 11.1 retry() method (2)
* § 11.5 complete() method (2)
* § 14.5 User aborts the payment request algorithm
* § 14.6.1 Abort the update
Permalink
Referenced in:
* § 3. PaymentRequest interface
* § 3.3 show() method (2) (3) (4) (5)
* § 11.1 retry() method (2) (3)
* § 11.5 complete() method (2)
* § 14.5 User aborts the payment request algorithm
* § 14.6.1 Abort the update
Permalink
Referenced in:
* § 6.2 PaymentDetailsInit dictionary
Permalink exported IDL
Referenced in:
* § 3. PaymentRequest interface
* § 3.2 id attribute
* § 11.4 requestId attribute
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 2. Examples of usage (2)
* § 3. PaymentRequest interface
* § 3.3 show() method (2) (3) (4) (5) (6)
* § 3.4 abort() method
* § 3.7 Internal Slots (2)
* § 14.6 Update a PaymentRequest's details algorithm
* § 15.1 User protections with show() method (2) (3)
* § 15.5 How user agents match payment handlers
* § 15.9 User activation requirement (2)
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 3. PaymentRequest interface
* § 3.4 abort() method (2) (3) (4)
* § 3.7 Internal Slots
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 3. PaymentRequest interface
* § 3.5 canMakePayment() method (2) (3)
* § 15.5 How user agents match payment handlers
* § 15.8 canMakePayment() protections
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 3. PaymentRequest interface
* § 3.6 onpaymentmethodchange attribute
* § A. IDL Index
Permalink exported
Referenced in:
* § 3.1 Constructor
* § 3.3 show() method
* § 14.1 Can make payment algorithm
Permalink exported
Referenced in:
* § 3.1 Constructor
* § 3.3 show() method (2) (3) (4)
* § 3.7 Internal Slots
* § 14.6 Update a PaymentRequest's details algorithm
Permalink exported
Referenced in:
* § 3.1 Constructor
* § 3.2 id attribute
* § 3.7 Internal Slots
* § 14.4 User accepts the payment request algorithm
* § 14.6 Update a PaymentRequest's details algorithm (2) (3)
Permalink
Referenced in:
* § 3.1 Constructor
* § 3.3 show() method (2) (3) (4) (5) (6)
* § 3.4 abort() method (2)
* § 11.1 retry() method
* § 13.3.2 updateWith() method
* § 14. Algorithms
* § 14.1 Can make payment algorithm
* § 14.2 Payment method changed algorithm
* § 14.3 PaymentRequest updated algorithm
* § 14.4 User accepts the payment request algorithm (2)
* § 14.5 User aborts the payment request algorithm (2)
* § 14.6.1 Abort the update
Permalink exported
Referenced in:
* § 3.4 abort() method
* § 3.7 Internal Slots (2) (3) (4) (5)
Permalink
Referenced in:
* § 3.1 Constructor
* § 3.3 show() method
* § 3.7 Internal Slots
* § 14.1 Can make payment algorithm
Permalink
Referenced in:
* § 3.3 show() method
* § 3.4 abort() method
* § 3.7 Internal Slots
* § 11.1 retry() method
* § 13.3.2 updateWith() method
* § 14. Algorithms
* § 14.2 Payment method changed algorithm
* § 14.3 PaymentRequest updated algorithm
* § 14.4 User accepts the payment request algorithm
* § 14.5 User aborts the payment request algorithm
Permalink
Referenced in:
* § 3.3 show() method (2) (3) (4)
* § 3.4 abort() method
* § 3.7 Internal Slots (2)
* § 14.4 User accepts the payment request algorithm
* § 14.5 User aborts the payment request algorithm
* § 14.6.1 Abort the update
* § 14.6 Update a PaymentRequest's details algorithm
Permalink
Referenced in:
* § 3.1 Constructor
* § 13.3.2 updateWith() method
* § 14.2 Payment method changed algorithm
* § 14.3 PaymentRequest updated algorithm
* § 14.4 User accepts the payment request algorithm
* § 14.6 Update a PaymentRequest's details algorithm (2)
* § 14.6.1 Abort the update
Permalink
Referenced in:
* § 3.3 show() method
* § 3.4 abort() method (2)
* § 11.5 complete() method
* § 14.4 User accepts the payment request algorithm
* § 14.5 User aborts the payment request algorithm
* § 14.6.1 Abort the update
* § 14.6 Update a PaymentRequest's details algorithm
Permalink
Referenced in:
* § 3.1 Constructor
* § 3.4 abort() method (2)
* § 14.4 User accepts the payment request algorithm (2) (3)
* § 14.5 User aborts the payment request algorithm
* § 14.6.1 Abort the update
Permalink
Referenced in:
* § 3.1 Constructor
* § 3.3 show() method (2)
* § 14.4 User accepts the payment request algorithm
Permalink exported IDL
Referenced in:
* § 1. Introduction (2)
* § 2. Examples of usage
* § 2.1 Declaring multiple ways of paying
* § 3. PaymentRequest interface
* § 3.1 Constructor
* § 4. PaymentMethodData dictionary (2)
* § 15.7 Exposing user information
* § A. IDL Index (2)
Permalink exported IDL
Referenced in:
* § 3.1 Constructor (2) (3) (4) (5) (6)
* § 4. PaymentMethodData dictionary
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 1. Introduction (2) (3)
* § 3.1 Constructor (2) (3)
* § 4. PaymentMethodData dictionary
* § 15.7 Exposing user information
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 5. PaymentCurrencyAmount dictionary (2)
* § 5.1 Validity checkers (2)
* § 8. PaymentItem dictionary (2)
* § A. IDL Index (2)
Permalink exported IDL
Referenced in:
* § 5. PaymentCurrencyAmount dictionary (2)
* § 5.1 Validity checkers (2) (3)
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 5. PaymentCurrencyAmount dictionary
* § 5.1 Validity checkers (2) (3)
* § 6.2 PaymentDetailsInit dictionary
* § 6.3 PaymentDetailsUpdate dictionary
* § A. IDL Index
Permalink
Referenced in:
* § 5. PaymentCurrencyAmount dictionary
* § 5.1 Validity checkers
Permalink
Referenced in:
* § 3.1 Constructor (2)
* § 5. PaymentCurrencyAmount dictionary
* § 5.1 Validity checkers
* § 14.6 Update a PaymentRequest's details algorithm (2)
Permalink
Referenced in:
* § 3.1 Constructor (2)
* § 14.6 Update a PaymentRequest's details algorithm (2)
Permalink exported IDL
Referenced in:
* § 3.7 Internal Slots
* § 6.1 PaymentDetailsBase dictionary
* § 6.2 PaymentDetailsInit dictionary (2)
* § 6.3 PaymentDetailsUpdate dictionary (2)
* § 7. PaymentDetailsModifier dictionary (2)
* § 8. PaymentItem dictionary
* § A. IDL Index (2) (3)
Permalink exported IDL
Referenced in:
* § 3.1 Constructor (2)
* § 6.1 PaymentDetailsBase dictionary
* § 7. PaymentDetailsModifier dictionary (2)
* § 14.6 Update a PaymentRequest's details algorithm (2) (3) (4) (5)
* § 15.7 Exposing user information
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 3.1 Constructor (2) (3)
* § 3.7 Internal Slots (2)
* § 6.1 PaymentDetailsBase dictionary
* § 14.6 Update a PaymentRequest's details algorithm (2) (3) (4) (5)
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 2. Examples of usage
* § 3. PaymentRequest interface
* § 3.1 Constructor
* § 6.2 PaymentDetailsInit dictionary (2) (3) (4)
* § 7. PaymentDetailsModifier dictionary
* § A. IDL Index (2)
Permalink exported IDL
Referenced in:
* § 3.1 Constructor (2)
* § 3.2 id attribute (2)
* § 6.2 PaymentDetailsInit dictionary (2)
* § 14.4 User accepts the payment request algorithm
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 3.1 Constructor
* § 6.1 PaymentDetailsBase dictionary
* § 6.2 PaymentDetailsInit dictionary (2)
* § 7. PaymentDetailsModifier dictionary
* § 14.6 Update a PaymentRequest's details algorithm
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 3. PaymentRequest interface
* § 6.3 PaymentDetailsUpdate dictionary (2) (3) (4)
* § 13.3 PaymentRequestUpdateEvent interface
* § 13.3.2 updateWith() method
* § 14.6 Update a PaymentRequest's details algorithm (2)
* § A. IDL Index (2) (3)
Permalink exported IDL
Referenced in:
* § 6.3 PaymentDetailsUpdate dictionary (2)
* § 14.6 Update a PaymentRequest's details algorithm (2) (3) (4)
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 6.3 PaymentDetailsUpdate dictionary
* § 14.6 Update a PaymentRequest's details algorithm (2) (3)
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 3.1 Constructor
* § 3.7 Internal Slots
* § 6.1 PaymentDetailsBase dictionary (2)
* § 7. PaymentDetailsModifier dictionary (2) (3)
* § 14.6 Update a PaymentRequest's details algorithm
* § A. IDL Index (2)
Permalink exported IDL
Referenced in:
* § 3.1 Constructor
* § 7. PaymentDetailsModifier dictionary (2) (3)
* § 14.6 Update a PaymentRequest's details algorithm
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 3.1 Constructor (2)
* § 7. PaymentDetailsModifier dictionary (2) (3)
* § 14.6 Update a PaymentRequest's details algorithm (2)
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 3.1 Constructor (2)
* § 7. PaymentDetailsModifier dictionary (2)
* § 14.6 Update a PaymentRequest's details algorithm (2)
* § 15.7 Exposing user information
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 3.1 Constructor (2) (3)
* § 3.7 Internal Slots (2)
* § 7. PaymentDetailsModifier dictionary
* § 14.6 Update a PaymentRequest's details algorithm (2) (3)
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 6.1 PaymentDetailsBase dictionary (2)
* § 6.2 PaymentDetailsInit dictionary (2)
* § 6.3 PaymentDetailsUpdate dictionary (2)
* § 7. PaymentDetailsModifier dictionary (2) (3) (4)
* § 8. PaymentItem dictionary (2)
* § 14.6 Update a PaymentRequest's details algorithm
* § A. IDL Index (2) (3) (4) (5) (6)
Permalink exported IDL
Referenced in:
* § 8. PaymentItem dictionary (2)
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 3.1 Constructor (2) (3) (4)
* § 6.2 PaymentDetailsInit dictionary
* § 6.3 PaymentDetailsUpdate dictionary (2)
* § 8. PaymentItem dictionary (2)
* § 14.6 Update a PaymentRequest's details algorithm (2) (3) (4)
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 8. PaymentItem dictionary
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 9. PaymentCompleteDetails dictionary (2) (3)
* § 11. PaymentResponse interface
* § A. IDL Index (2)
Permalink exported IDL
Referenced in:
* § 9. PaymentCompleteDetails dictionary
* § 11.5 complete() method
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 10. PaymentComplete enum
* § 11. PaymentResponse interface
* § A. IDL Index (2)
Permalink exported IDL
Referenced in:
* § 10. PaymentComplete enum
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 10. PaymentComplete enum
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 10. PaymentComplete enum
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 2. Examples of usage
* § 2.5 POSTing payment response back to a server (2)
* § 3. PaymentRequest interface
* § 3.7 Internal Slots
* § 9. PaymentCompleteDetails dictionary
* § 11. PaymentResponse interface (2)
* § 11.1 retry() method (2) (3) (4) (5)
* § 11.5 complete() method
* § 11.6 Internal Slots (2)
* § 13.3.2 updateWith() method
* § 14.4 User accepts the payment request algorithm
* § 14.6 Update a PaymentRequest's details algorithm
* § 15.7 Exposing user information
* § A. IDL Index (2)
Permalink exported IDL
Referenced in:
* § 11. PaymentResponse interface
* § 11.1 retry() method (2)
* § 14.6 Update a PaymentRequest's details algorithm
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 11. PaymentResponse interface
* § 11.1 retry() method (2)
* § 11.1.1 PaymentValidationErrors dictionary (2)
* § A. IDL Index (2)
Permalink exported IDL
Referenced in:
* § 11.1 retry() method
* § 11.1.1 PaymentValidationErrors dictionary (2) (3)
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 11.1 retry() method (2)
* § 11.1.1 PaymentValidationErrors dictionary
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 11. PaymentResponse interface
* § 11.1 retry() method
* § 11.5 complete() method (2) (3)
* § 14.4 User accepts the payment request algorithm
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 11. PaymentResponse interface
* § 14.4 User accepts the payment request algorithm
* § 15.7 Exposing user information (2)
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 11. PaymentResponse interface
* § 14.4 User accepts the payment request algorithm
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 11. PaymentResponse interface
* § 11.5 complete() method (2) (3) (4) (5) (6) (7)
* § 11.6 Internal Slots
* § A. IDL Index
Permalink
Referenced in:
* § 11.1 retry() method
* § 11.5 complete() method (2)
* § 14.4 User accepts the payment request algorithm
* § 14.5 User aborts the payment request algorithm
* § 14.6.1 Abort the update
* § 14.6 Update a PaymentRequest's details algorithm
Permalink
Referenced in:
* § 11.1 retry() method
* § 13.3.2 updateWith() method
* § 14.4 User accepts the payment request algorithm
Permalink
Referenced in:
* § 3.4 abort() method
* § 11.1 retry() method (2) (3) (4)
* § 11.5 complete() method
* § 14.4 User accepts the payment request algorithm (2)
* § 14.5 User aborts the payment request algorithm (2)
* § 14.6.1 Abort the update (2)
* § 14.6 Update a PaymentRequest's details algorithm
Permalink
Referenced in:
* § 3.1 Constructor
Permalink
Referenced in:
* § 3.6 onpaymentmethodchange attribute
* § 14.2 Payment method changed algorithm
Permalink exported IDL
Referenced in:
* § 3.6 onpaymentmethodchange attribute
* § 13.1 Summary
* § 13.2 PaymentMethodChangeEvent interface
* § 14.2 Payment method changed algorithm
* § 15.7 Exposing user information (2)
* § A. IDL Index
Permalink exported
Referenced in:
* Not referenced in this document.
Permalink exported IDL
Referenced in:
* § 13.2 PaymentMethodChangeEvent interface
* § 14.2 Payment method changed algorithm
* § 15.7 Exposing user information
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 13.2 PaymentMethodChangeEvent interface
* § 13.3.2 updateWith() method (2)
* § 14.2 Payment method changed algorithm
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 13.2 PaymentMethodChangeEvent interface
* § 13.2.1 methodDetails attribute
* § 13.2.2 methodName attribute
* § 13.2.3 PaymentMethodChangeEventInit dictionary
* § A. IDL Index (2)
Permalink exported IDL
Referenced in:
* § 13.2.2 methodName attribute
* § 13.2.3 PaymentMethodChangeEventInit dictionary
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 13.2.1 methodDetails attribute
* § 13.2.3 PaymentMethodChangeEventInit dictionary
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 13.2 PaymentMethodChangeEvent interface
* § 13.3 PaymentRequestUpdateEvent interface (2)
* § 13.3.1 Constructor (2)
* § 13.3.2 updateWith() method
* § 13.3.3 Internal Slots
* § 14.3 PaymentRequest updated algorithm
* § A. IDL Index (2)
Permalink exported IDL
Referenced in:
* § 13.3 PaymentRequestUpdateEvent interface
* § 13.3.1 Constructor
* § A. IDL Index
Permalink exported IDL
Referenced in:
* § 3.7 Internal Slots (2)
* § 6.3 PaymentDetailsUpdate dictionary
* § 13.3 PaymentRequestUpdateEvent interface
* § 13.3.2 updateWith() method (2) (3)
* § 13.3.3 Internal Slots
* § A. IDL Index
Permalink
Referenced in:
* § 13.3.1 Constructor
* § 13.3.2 updateWith() method (2) (3)
* § 14.3 PaymentRequest updated algorithm (2)
Permalink exported IDL
Referenced in:
* § 13.2.3 PaymentMethodChangeEventInit dictionary
* § 13.3 PaymentRequestUpdateEvent interface
* § 13.3.4 PaymentRequestUpdateEventInit dictionary
* § A. IDL Index (2) (3)
Permalink
Referenced in:
* § 3.5 canMakePayment() method
* § 14.1 Can make payment algorithm
Permalink exported
Referenced in:
* § 15.7 Exposing user information
Permalink
Referenced in:
* Not referenced in this document.
Permalink exported
Referenced in:
* § 3.3 show() method (2)
* § 3.7 Internal Slots
* § 11.1 retry() method
* § 11.6 Internal Slots
Permalink
Referenced in:
* § 3.3 show() method (2)
* § 3.4 abort() method
* § 3.7 Internal Slots
* § 11.1 retry() method
* § 11.6 Internal Slots
* § 14.6 Update a PaymentRequest's details algorithm
Permalink
Referenced in:
* § 3.3 show() method (2)
* § 13.3.2 updateWith() method
Permalink exported
Referenced in:
* § 11.1 retry() method
* § 14.6 Update a PaymentRequest's details algorithm (2) (3) (4) (5) (6) (7)
(8) (9) (10) (11)
Permalink
Referenced in:
* § 1. Introduction
* § 3. PaymentRequest interface (2)
* § 3.3 show() method (2) (3) (4)
* § 3.4 abort() method (2) (3)
* § 3.5 canMakePayment() method
* § 6.1 PaymentDetailsBase dictionary
* § 6.2 PaymentDetailsInit dictionary
* § 8. PaymentItem dictionary (2)
* § 10. PaymentComplete enum (2) (3)
* § 11.1 retry() method
* § 11.5 complete() method (2)
* § 13.3.2 updateWith() method
* § 14. Algorithms
* § 14.1 Can make payment algorithm
* § 14.4 User accepts the payment request algorithm (2)
* § 14.5 User aborts the payment request algorithm
* § 15.7 Exposing user information (2) (3)