"Refactoring" PaymentRequest

For the record only.

When the Web Payment API project started some of the primary motivations were as far as I recall (I was at the TPAC in Shenzhen 2013 where the idea was "sold"):
1. Simplify payment method selection (aka NASCAR issue)
2. Provide a standardized API for Merchants

Now, (in retrospect), we can see that that #1 is not in high demand; it is rather "skipping the list" these days.

Regarding #2 you only have to take a peek at Google Pay for Android to realize that the only standardized items are the input items "amount" and "currency", while processing and results are highly application specific.  In addition, there is no universal payment backend connector method.

That plans doesn't always evolve exactly as anticipated in not unique and___/is nothing to be ashamed of/_.

Therefore, I would seriously consider a revised effort that would not be payment related, but rather deal with Web applications depending on a "mediator".   It has been claimed that this would introduce additional_//_security and privacy issues compared to a dedicated payment API.  Since the existing PaymentRequest concept permits payment applications to exchange whatever information they want (only limited by permissions given by the platform to be more exact), /_and with any server_/, I believe this is based on a misconception.  However, feel free challenging this statement; life is about learning and I'm certainly not infallible!

The https://github.com/adrianhopebailie/modal-window/ seems like another reason for taking a fresh look at the "mediator" concept.  Such a scheme would also be easy to support with a generic BLE bridge where the "mediator" application runs in another device.

Would the proposed refactoring invalidate the current PaymentRequest API?  No, a properly designed "mediator" API can mirror /_any_//_API_/. A simple JS wrapper would though be required for 1-2-1 compatibility.

Thanx,
Anders Rundgren