Re: [w3c/browser-payment-api] Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? (#109)

A web app is necessarily much more restricted than a browser extension though. 

An approach that afaik does not violate existing security models is : Interact with merchant/payee to choose what to purchase, do secure interactions with payment app to approve purchase, and finally do post-purchase interactions with merchant and payment app together.  In principle, we could change the top context twice to do secure interactions with the payment app twice, but probably nobody wants that. 

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. 

Also, these secure context only impact the flow from the user's perspective.  A browser extension based payment app can certainly use rich interactions to actually do the payment. 

---
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-204328028