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

> The current version of PaymentRequest doesn't do this particularly well.

I disagree. This use case has been top of mind for some time. It's quite easy for a Payment Handler (a Service Worker in the browser) to invoke a remote service over the Web when it is activated by a new Payment Request.

That remote service pushes a message to the user's phone and the user approves the payment in the app on their phone.

I use a similar interaction daily to login to Google services and login and approve payments in my online banking service.

> In this proposal I envision the phone docking into the browser and enumerating its payment methods.

Can you describe further what "docking" means? How does this pairing work and what OS-level APIs/features are required to allow this?

> For PaymentRequest it is just another driver.

It's important to get the terminology right here because I think you and @marcoscaceres may be talking across each other. `PaymentRequest` is simply and interface for passing a payment request to the browser and returning a response to the website. It doesn't define how the browser gets that response.

We have defined an abstract component called a "Payment Handler" which handles the request and returns the response and we have specified an API for payment handlers (implemented as service workers) on the Web to register themselves with the browser and accept and respond to payment requests.

If you want to define an alternative form of payment handler then I think that would need to be in the form of an alternative payment handler API that defines how the handler registers itself with the browser and how it handles payments.

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