PaymentRequest - Bluetooth connector

[cyberphone]

As far as I know Apple Pay in the Mac/iPhone "combo" uses Bluetooth to achieve an integrated and convenient payment solution.

Although one can use Web Bluetooth this has major shortcomings and (probably) requires the user to grant each Merchant access to the Bluetooth connector.

With a dedicated interface this is not necessary since the Merchant never talks directly to Bluetooth channel (it isn't even aware of it). For the Merchant it is just PaymentRequest.

I believe this builds on the very same idea:
https://www.blog.google/technology/safety-security/your-android-phone-is-a-security-key/
Here it is rather a FIDO2 interface.

[cyberphone]

Unlike the proprietary Chrome PaymentRequest Android interface, the Bluetooth counterpart must be universal. It can probably reuse the platform used by FIDO/WebAuth making the task quite reasonable.

In addition to being "phish-safe", this solution would eliminate quirky QR solutions or solutions using mobile phone numbers for establishing a trusted link between the Web application running a PC/Mac and a mobile wallet.

[marcoscaceres]

Although one can use Web Bluetooth this has major shortcomings and (probably) requires the user to grant each Merchant access to the Bluetooth connector.

I think it would be granted to the payment handler, not the merchant's website. Thus there would only be one prompt.

[cyberphone]

This proposal is unrelated to W3C's PaymentHandler, it builds on forwarding the PaymentRequest to a native mode mobile wallet which I believe is analogous to the FIDO2/WebAuthn use case.

[marcoscaceres]

The Payment Request API relies on some payment handler (e.g., basic card, apple pay, BlueTooth Terminal-0-matic) showing some UI... so I'm not following how it's unrelated to payment handler?

[cyberphone]

Sorry, it was a terminology issue. I thought you referred to the W3C PaymentHandler.

Anyway, what do you think about the proposal?

[marcoscaceres]

Anyway, what do you think about the proposal?

The proposal is fine, but I think it could be handled by any old payment handler. It doesn't seem to be in scope for Payment Request?

[cyberphone]

The proposal is fine, but I think it could be handled by any old payment handler.

Please explain how

[marcoscaceres]

you would create a payment handler and it would call the show window API when required to show the payment sheet... in the payment sheet, you would use the BlueTooth API to pair with the hardware. The user would grant access once. The browser would remember that "https://blue-tooth.payment.com" is allowed to use BlueTooth in the payment sheet.

Then if you got to another website and try to pay, the browser already knows that "https://blue-tooth.payment.com" already has the permission grant... so if the user chooses to pay with that payment handler, it just works (TM).

[cyberphone]

The idea was creating a counterpart to FIDO2/WebAuthn by defining a standardized interface between the Web and a bluetooth-connected device. The interface would follow the PaymentRequest API since it effectively works under the same umbrella. There would in similarity to FIDO2/WebAuthn be nothing to install in the PC/Mac end.

https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-client-to-authenticator-protocol-v2.0-rd-20180702.html

[marcoscaceres]

We generally don’t want to do specialized APIs like that. Ideally, we would make Web Bluetooth work.

[cyberphone]

This (mobile wallet + PC) is probably the biggest PaymentRequest use case after the mobile Web. I'm merely suggesting another way hooking into the PaymentRequest API, not a new API.

I leave it there and hope that you and team evaluate the different approaches. Since there already is a predecessor (Apple Pay), this should be reasonably simple.

Note that for the Merchant the code for the Mobile Web and the PC Web would be identical using the integrated approach.

[marcoscaceres]

I understand, but some UI needs to be shown, right? Like ApplePay (a payment handler) has a UI that does the interfacing with watch or phone.

Similarly here, won’t you need some kind of payment handler?

[cyberphone]

IMO, there would not be a need for a new UI in the PC/Web end; the PaymentRequest would only expose the additional matching payment alternatives acquired through the Bluetooth connection. It is like payment method "docking".

In the Mobile end, there would of course be a UI that should show the amount requested etc. This part would not differ from what for example Google Pay already does for Mobile Web.

There are a billion+ mobile wallets out there that could benefit from a solution that is standardized in the Merchant end while offering a better UI for users. This ought to be a great way to gain more traction for the PaymentRequest API. This is one step further towards "Converged Payments". The next step is the PoS terminal. Imagine, one protocol to rule them all! 😀