- From: Adrian Hope-Bailie <notifications@github.com>
- Date: Fri, 01 Apr 2016 03:29:25 -0700
- To: w3c/browser-payment-api <browser-payment-api@noreply.github.com>
- Message-ID: <w3c/browser-payment-api/issues/109/204342084@github.com>
> A web app is necessarily much more restricted than a browser extension though. Correct, that is why it has been proposed that payment apps may also take the form of extensions or native apps. > and finally do post-purchase interactions with merchant and payment app together What's the purpose of this final step? The current flow suggest that the user and merchant interact via the merchant's website until such time as the merchant is ready to initiate a payment request. They do that via the browser API which triggers the browser to perform it's function as mediator. The browser is aware of the payment apps the user has registered (web or native) and what payment methods these support. The browser looks at the payment methods that the merchant supports and based on this finds a common set which allows it to prompt the user to select a payment app from a list of apps that all support at least one payment method that the merchant supports. The user picks a payment app and the payment request is forwarded to the app. When the app has done it's processing (whatever that may be, depends on the payment method) it returns a payment response to the browser which in turn returns this to the merchant website in the form of a resolved promise that was returned when the original API call was made. This proposal suggests that there is a need for the merchant and payment app to interact prior to the return of the response and that we should standardize a way for this to happen via a callback URL which the payment app uses to establish a back-channel session with the merchant. > In particular, if the payment app has a rich interaction with the merchant from its secure context, then one should expect that payment apps occasionally get hacked by merchants who themselves got hacked. That's a risk anyways, but the hacker cannot ask "what is your balance or credit limit" without the rich interaction. This interface (directly between the merchant and payment app) will be via HTTP calls so I'm not sure there is a risk of the payment app getting hacked if the merchant is hacked? --- 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/browser-payment-api/issues/109#issuecomment-204342084
Received on Friday, 1 April 2016 10:30:28 UTC