Re: [w3c/browser-payment-api] Why another API? (#203)

@tjconcept the handling of a payment request requires three parties on the Web: the initiator (merchant/payee), the payment app (user/payer) and a mediator.

This is the case today because there is not universal or open payment protocol (like HTTP for payments) that all participants have implemented.

It's necessary therefor for the payment request to list out all of the payment methods that the payee accepts and for the payer (through the payment app) to pick one.

Why is the mediator necessary? Because the user may have multiple payment apps that handle a variety of payment methods (and these may overlap) so a component is required in this system to mediate this process.

As in many other scenarios the browser sits between these two apps (website and payment app) to also protect the privacy of the user.

The next questions is why not have a generic cross-origin pipe for communication between the website and payment app? Well, that assumes that the payment app is a web app (it may be a native app, a browser extension, a piece of hardware etc).

It also assumes that the browser will be able to make good decisions to protect the user with no understanding of the semantics of what the user is doing.

We need the browser to know that the intent of the website is "get paid", not just "talk to another app" and be able to convey sufficient semantics in that "intent" to let the browser do a good job as the mediator.

The design of the API is such that the browser should never need to know semantics of payment methods (i.e. the difference between a bitcoin payment and a credit card payment) but enough about the transaction to provide the user with a secure, accessible and generally pleasant experience.

---
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/203#issuecomment-220974390