diff --git a/index.html b/index.html index 4ee6796..0d3c82e 100644 --- a/index.html +++ b/index.html @@ -449,9 +449,9 @@

Network Considerations

(yet) address scenarios where the user agent does not receive the response (e.g., due to a crash or network outage). Network failure may be especially problematic in the - case of a push payment; see issue 224, and so the Working Group is considering whether the specification should include a standard way to learn how to query a component for payment state information. For example, many systems use backchannel communications, so one idea is for the payee to provide a callback URL. This would allow (but not require) the payment app to communicate with the payee server until such time as all parties are satisfied they share the same view of the payment response. An alternative would be to provide the payment app and the user agent a channel so that communication continues until all aprties are satisfied they share the same view of the payment response. This might involve caching payment responses. + case of a push payment; see issue 224, and so the Working Group is considering whether the specification should include a standard way to learn how to query a component for payment state information. For example, many systems use backchannel communications, so one idea is for the payee to provide a callback URL. This would allow (but not require) the payment app to communicate with the payee server until such time as all parties are satisfied they share the same view of the payment response. An alternative would be to provide the payment app and the user agent a channel so that communication continues until all parties are satisfied they share the same view of the payment response. This might involve caching payment responses.
  • This specification does not address communication between the payee server and the payee Web app, or between - the payment app and other parties (e.g., the payment app distibutor, or directly to the merchant).
    • + the payment app and other parties (e.g., the payment app distributor, or directly to the merchant). @@ -483,7 +483,7 @@

    Payment App Implementation Technology

    payment app identifier
    A unique identifier for a payment app (e.g., from a payment - method manifest file). This specification defines thses identifiers + method manifest file). This specification defines these identifiers as to be service worker scope URLs. As such, they are not expected to be dereferenced.
    @@ -539,7 +539,7 @@

    Payment App Selection States

    selected payment app
    the payment app whose option has been selected by the user to make a payment, but not yet invoked.
    -
    invoked payment app
    +
    invoked payment app
    the selected payment app that the user agent has invoked (executed) and passed payment app input data.
    @@ -783,7 +783,7 @@

    The getManifest method is used to - retreive the properties associated with a registered + retrieve the properties associated with a registered payment app.

    The getManifest method, when invoked, MUST run the @@ -806,14 +806,14 @@

    If there is no PaymentAppManifest associated with the Service Worker, reject promise with a DOMException whose name is "AbortError" - and teminate these steps. + and terminate these steps.
  • Retrieve the PaymentAppManifest associated with the Service Worker.
  • - Let manifest be the retreved PaymentAppManifest. + Let manifest be the retrieved PaymentAppManifest.
  • Resolve promise with manifest. @@ -1249,7 +1249,7 @@

    Payment App Invocation

    PaymentAppRequestData containing information about the payment being requested. The event also contains a function that allows the payment app to provide a payment response back to the - payee. Ths process is formally described in the following + payee. This process is formally described in the following sections.

    @@ -1332,7 +1332,7 @@

    e, that uses the PaymentRequestEvent interface, with the event type paymentrequest, which does not bubble, - is not cancelable, and has no default action.

    • + cannot be canceled, and has no default action.
  • Set the data attribute of e to a new PaymentAppRequestData instance, populated as described in @@ -1358,9 +1358,9 @@

    Payment Apps that require user input can open a payment window using the clients.openWindow() method defined in [[!SERVICE-WORKERS]]. - Absent user perferences that override such behavior, user interaction is + Absent user preferences that override such behavior, user interaction is required during payment requests, in the form of payment app selection. As - a consquence, the user agent MUST treat a paymentrequest event as + a consequence, the user agent MUST treat a paymentrequest event as user interaction for the purposes of determining whether the service worker is allowed to open a window.

    @@ -1420,7 +1420,7 @@

    Payment App Response

    When this Promise is resolved, the user agent MUST run the user accepts the payment request algorithm as defined in [[!PAYMENT-REQUEST-API]], replacing steps 6 and 7 with these steps or - their equiivalent: + their equivalent:

    1. @@ -1602,9 +1602,9 @@

      Data Validation

      -

      Incognito Mode

      +

      Private Browsing Mode

        -
      • When the Payment Request API is invoked in a browser's "incognito mode," the browser should launch browser-based payment apps in an incognito context. This will generally prevent sites from accessing any previously-stored information. In turn, this is likely to require either that the user log in to the payment app or re-enter payment instrument details.
        • +
      • When the Payment Request API is invoked in a "private browsing mode," the browser should launch browser-based payment apps in a private context. This will generally prevent sites from accessing any previously-stored information. In turn, this is likely to require either that the user log in to the payment app or re-enter payment instrument details.