[w3c/payment-request] Drop support for "Push Payments" (#759)

That was a bit of a click-bait title, sorry. But, I do think we need to consider this.

Accommodating PaymentHandlers that may have completed the payment before the website receives a `PaymentResponse` is causing a lot of complications and is imposing a lot of constraints on the design. See thread about billing address (#27) as an example.  

The concern is this:

1. The website calls `PaymentRequest`
2. The user chooses to use a PaymentHandler to process the request and the request is therefor passed to the PaymentHandler.
3. The PaymentHandler supports some form of "push payment" and processes the payment before passing a response back to the browser.
4. The browser returns the `PaymentResponse` to the website.
5. There is an issue with the returned data (shipping address, billing address, payment method specific data).

At this point the user has paid the merchant but the amount is possibly incorrect.

## Proposal

PaymentHandlers that support "push payments" should return an opaque token back to the website along with a URL to which the merchant POSTs the token to execute the payment.

This would allow merchants to evaluate the returned data in the `PaymentResponse` before submitting the token to the URL to complete the payment.

We can standardize some properties of the token (amount authorised, expiry, the URL that it must be submitted to) but the security and integrity of the token is left to each payment method to define and this can be entirely opaque to the browser and the website.

## Bonus Proposal

This could be hidden from the merchant and done in the background by the browser when the website calls `PaymentResponse.complete()`?




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