search

w3c / payment-request

Payment Request API
https://www.w3.org/TR/payment-request/
Other
489 stars 135 forks source link

Drop support for "Push Payments" #759

Open adrianhopebailie opened 6 years ago

adrianhopebailie commented 6 years ago

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

ianbjacobs commented 6 years ago

Adding this link to help with this discussion: https://github.com/w3c/payment-request/wiki/PushPayments

marcoscaceres commented 6 years ago

@adrianhopebailie thanks for the additional clarification. My working assumption had always been that push payments were akin to tokenized payments (your proposal above is what I had in mind!) - I think that was the source of misunderstanding and confusion on my part - particularly because I didn't understand how a payment could be processed without the merchant having agreed that it was ok to process it and that it was ok.

I've not given this a lot of thought yet, but there might be some relationship here to #646 (merchant validation): in that, there is a confirmation via .complete() in the MerchantValidationEvent. So, similarly for push payments, there could be a .complete() on a similar event to indicate that the push payment can be processed.

Anyway, let's finish off the billing thing and circle back to this.

ianbjacobs commented 6 years ago

Hi @adrianhopebailie,

Of the two proposals, I prefer the proposal where the merchant simply confirms the data before the payment handler initiates payment. That seems simpler to me than the merchant receiving the data, and having to launch a backend process itself, and payment systems having to set up REST services to receive that data, and standardizing the data that they would receive.