diff --git a/index.html b/index.html index 41d574b8..ab437f77 100644 --- a/index.html +++ b/index.html @@ -215,12 +215,12 @@
- A web page creates a PaymentRequest to make a payment request. + 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 the web - page to exchange information with the user agent while the user + 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 before approving or denying a payment request.
@@ -323,8 +323,9 @@
- The options object contains information about what - options the web page wishes to use from the payment request system. + The options object contains information the developer + needs from the user to perform the payment (e.g., the payer's + name and shipping address).
const options = { @@ -597,7 +598,7 @@
- The show() method is called when the page wants to begin + 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 @@ -709,13 +710,13 @@
- The abort() method is called if the web page wishes to tell + 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, a web page might choose to do this if the goods they are + 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. @@ -1650,7 +1651,7 @@
The PaymentShippingOption dictionary has members describing a - shipping option. A web page can provide the user with one or more + shipping option. Developers can provide the user with one or more shipping options by calling the updateWith() method in response to a change event. @@ -1719,7 +1720,7 @@
"unknown"
- The web page did not indicate success or failure and the user + The developer did not indicate success or failure and the user agent SHOULD NOT display UI indicating success or failure. @@ -1867,16 +1868,16 @@
After the payment request has been accepted and the - PaymentResponse returned to the page but before the page calls - complete() the payment request user interface remains in a - pending state. At this point the user interface ought not offer a + PaymentResponse returned to the caller but before the caller + calls complete() the payment request user interface remains in + a pending state. At this point the user interface ought not offer a cancel command because acceptance of the payment request has been - returned. However, if something goes wrong and the page never calls - complete() then the user interface is blocked. + 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 the page to - call complete(). If the timeout expires then the + 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.
@@ -1998,11 +1999,11 @@};
- The PaymentRequestUpdateEvent enables the web page to update + The PaymentRequestUpdateEvent enables developers to update the details of the payment request in response to a user interaction.
- If the web page wishes to update the payment request then it should + 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 SHOULD present to the user. @@ -2016,7 +2017,7 @@
updateWith() method
- If the web page wishes to update the payment request then it should + 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. @@ -2056,8 +2057,8 @@
The user agent SHOULD 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 web page has made - changes required by the change. The web page MUST settle the + that the payment is not accepted until developers have made + changes required by the change. Developers MUST settle the detailsPromise to indicate that the payment request is valid again. @@ -2365,7 +2366,7 @@
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 web page hasn't successfully handled the change + 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 @@ -2684,8 +2685,8 @@
Exposing user information
- The user agent MUST NOT share information about the user to - the web page (such as the shipping address) without user consent. + The user agent MUST NOT share information about the user + with a developer (e.g., the shipping address) without user consent.
@@ -2693,7 +2694,7 @@ Exposing available payment methods
- A page might try to call the payment request API repeatedly with only + Developers might try to call the payment request API repeatedly with only one payment method identifier to try to determine what payment methods a user agent has installed. There may be legitimate scenarios for calling repeatedly (for example, to control the order