[w3c/payment-request] Response timeout could leave page/user in confused state. (#737)

>From [Gecko bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1447773 ), spec says:

> After the payment request has been accepted and the PaymentResponse returned to the caller but before the caller calls complete() the payment request user interface remains in a pending state. At this point the user interface ought not offer a cancel command because acceptance of the payment request has been returned. However, if something goes wrong and the developer never calls complete() then the user interface is blocked.
>
>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.

Problem is that the you have a race condition:

 1. the promise from `fetch("/make-payment", {body: response.toJSON()})` may take longer to resolve than the payment sheet being presented (e.g., 5 seconds in Browser X). 
 1. As the payment sheet is shutting down due to a timeout, `fetch()` promise resolves successfully (the user has been charged!).
 1. The merchant is now in an awkward position, having to inform the user that the payment actually went thought... but unable to use the payment sheet.  

We might need a new event to notify the merchant if the sheet has shut down on them. Otherwise, they will try to `.complete()` and response will just return a rejected promise.   

@domenic, @zkoch, @aestes, @adrianba, all, thoughts? 

-- 
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/737

Received on Tuesday, 26 June 2018 18:56:39 UTC