Support for Abort() being delegated to Payment Handler

[mattsaxon]

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?

[rsolomakhin]

Let's make this only optional, please.

[mattsaxon]

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.

[mattsaxon]

Related to Issue 473 in PR

[adrianhopebailie]

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.

[rsolomakhin]

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.

[ianbjacobs]

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

[rsolomakhin]

Happy to review any pull requests.

[ianbjacobs]

@adrianhopebailie, would you be willing to write up a pull request with your proposal? See notes from the 6 June apps task force call. Thanks!

Ian

[rsolomakhin]

I sketched a quick proposal in pull request #170.

[adrianhopebailie]

@rsolomakhin beat me to it! Thanks Rouslan

[ianbjacobs]

Moved to a new pull request:
#207

Per discussion on 29 August, we are awaiting more implementation experience.

[1] https://www.w3.org/2017/08/29-apps-minutes.html#item03

[ianbjacobs]

After feedback from @marcoscaceres and further discussion with @rsolomakhin,
@rsolomakhin will close pull request #207 and submit a new one limited to what happens in the payment handler API. Separately, @rsolomakhin will propose a change to Payment Request where, as part of the abort() algorithm, if a payment handler has been selected by the user, the browser fires the relevant payment handler event for that payment handler.