Re: [w3c/payment-request] Clarify when the user can abort the payment request algorithm (#796)

> Ok, just want to clarify something here... as I alluded to above, there are two cases we need to deal with:
> 
> 1. `updateWith()` / `retry()` - use same update logic.
> 2. Before `complete()` is called (i.e., "...processing...") stage.

Not sure that retry() needs to be dealt with, actually. Once you retry() the request becomes interactive again, and I think the user abort algorithm already does the right thing in that state.

Here is how I think of these two cases:

1. request.[[updating]] is true
2. request.[[state]] is "closed"

> * Safari? @aestes?

Safari does seem to allow users to cancel during (2). I'll learn more about why this is.

> 
> The annoying part of 2 is that it can get stuck (hence the timeout):
> 
> > 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.

You can get stuck in (1) as well, since it's up to the merchant to resolve the PaymentDetailsUpdate promise. Safari imposes a timeout there too.

> So, question is, should a user be allowed to cancel by prior to calling `.complete()`? It should it be _only_ by timeout (in which case, Chrome might be accidentally doing it wrong)

I think users should not be allowed to cancel after they accept the payment. Once a PaymentResponse is returned to the merchant it's probably too late to expect the user abort to be honored in all cases, so users shouldn't be made to think otherwise.

Of course if the merchant calls retry() instead of complete(), then cancel should be allowed again until the next time the user accepts.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/796#issuecomment-439982841