In PaymentRequest, the statement "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."

Can the abort be delegated to a payment handler interface such that this statement invalid?

Let's make this only optional, please.

I think they would be fine, especially if this linked in with the state model such that when the status is 'processing' that calling abort() results in an exception. I could see additional states in his state model e.g. Interactive->pre-processing->processing which could more clearly specify the behaviour and set better expectations for users of the API.

Related to Issue 473 in PR

Per discussion on the Payment Apps TF call:

• We can't provide any guarantees that, once a payment request is delegated beyond the browser, it can be aborted. Web-based payment apps are only one type of app.
• We can improve the Payment Handler specification to include a mechanism of passing the abort request to a web-based payment app.

Proposal

Add a paymentRequestAborted event to the Payment Handler interface. The event will have a respondWith method that takes a boolean parameter indicating if the paymentRequest has been successfully aborted.

I've head support for this from payment app developers. There should be no expectation of rolling back or refunding a transaction in progress if .abort() is called, however.

Thanks Rouslan. As we discussed at the 23 May call [1], the sense I have is that an event (such as Adrian's proposal) would be a signal from the merchant, and the payment app could behave in a variety of ways (depending on payment method, status of payment, etc.) and inform the site of the outcome.

[1] https://www.w3.org/2017/05/23-apps-minutes#item08