Re: [w3c/payment-request] PaymentRequest - Bluetooth connector (#865)

Let me finish this issue with a few remarks:
- Extending payment solutions based on native payment handlers need solutions that are compatible with the distribution method used for native applications.  That is, bringing in a `ServiceWorker` etc. is hardly a viable option.  In fact, many native payment solutions do "by design" not even have a domain concept permitting them to host multiple payment credentials from independent payment providers in a single "wallet".   See also: https://github.com/w3c/payment-handler/issues/368
- The security model for such schemes (pretty much independent how they are architected), also departs from the "tradition", since the critical resources are in the connected device rather than in the desktop browser.  This is a bit similar to the Android Studio debugger, where it is the debugged device that asks its user if it is OK to be connected which is quite logical since debugging is potentially both privacy- and security-invasive.

The net effect of not having a useful DesktopWeb-2-MobileWallet solution is that `PaymentRequest` _cannot be used for this quite popular scenario_.  QR remains as the currently only credible solution and is also the method established by the Chinese and [_most of the_] European mobile phone based payment providers.

@rsolomakhin @danyao 

-- 
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/payment-request/issues/865#issuecomment-623059014