-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop support for "Push Payments" #759
Comments
Adding this link to help with this discussion: |
@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 Anyway, let's finish off the billing thing and circle back to this. |
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. |
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:
PaymentRequest
PaymentResponse
to the website.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()
?The text was updated successfully, but these errors were encountered: