@marcoscaceres @romandev

Does it make sense for us to have a paymentRequestAborted event or similar that is raised:

1. If the user cancels the payment from the payment sheet, or
2. If the merchant website aborts the payment request
3. If the window that was opened through openWindow is closed by the user

I would prefer to add AbrotPaymentEvent for merchant-initiated abort and a "window closed promise" for user-initiated abort. A promise has the nice property that it's impossible to miss it by starting to listen for it too late. Correct me if I'm wrong here.

• AbortPaymentEvent
  • Sent by the merchant website via PaymentRequest.abort().
  • Payment Handler can choose to respondWIth(true) or respondWith(false) to indicate whether it's acceptable to interrupt it in the current state.
  • Example:

    self.addEventListener('abortpayment', evt => {
      // Easy-going payment handler.
      evt.respondWith(true);
    });

• "Window closed promise"
  • Sent by the user agent when the user closes the payment handler window.
  • Payment Handler does not have a choice on how to respond: the user has already closed the payment handler window.
  • Example:

    self.addEventListener('paymentrequest', paymentRequestEvent => {
      paymentRequestEvent.respondWith(new Promise((resolve, reject) => {
        let userConfirmedPayment = false;
        paymentRequestEvent.openWindow("https://bobpay.xyz/").then(windowClient => {
    
          // Handle user closing the payment handler window.
          windowClient.windowClosed.then(() => {
            if (!userConfirmedPayment) {
              // User closed the window before confirming the payment.
              reject(err);
            }
          });
    
        }).catch(err => {
          // Was not able to open the window in the first place.
          reject(err);
        });
      }));
    });

This situation would be ideal, but I'm not sure whether this is how

@rsolomakhin,

(Seems reasonable but I am not a promise expert.)