Drop support for "Push Payments"

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()?

Start by reading this issue and the referenced billing-address thread (#27). The payload names no repository files, tests, or entry points. Done would require an agreed specification for handling push-payment tokens and completion behavior, rather than an isolated code change.