Intent to Deprecate and Remove: Payment handlers for standardized payment method identifiers.

201 views
Skip to first unread message

Rouslan Solomakhin

unread,
Dec 16, 2020, 3:47:12 PM12/16/20
to blink-dev
Contact emails
rou...@chromium.org

Specification
https://w3c.github.io/payment-handler/#methoddata-attribute

Summary
Payment handlers today can receive "paymentrequest" events with non-URL, but standardized payment method identifiers, such as "basic-card" or "tokenized-card". This intent is to deprecate and remove this feature, so payment handlers will be able to use only URL-based payment method identifiers, such as "https://bobpay.xyz".

The reason is that standardized payment method identifiers do not have an allow-list or block-list and can be installed silently --- they are service workers with some payment related metadata and event handlers. A user could be surprised when the browser displays a little known payment handler (from a website they visited in passing) next to the user's credit cards during a payment flow. This concern has also been brought up by web developers: https://github.com/w3c/payment-handler/issues/379.

This intent is not for removing the ability of the browser itself from handling standardized payment method identifiers. The built-in browser UI for payment with credit card still can respond to requests for payment via "basic-card" standardized payment method.

Blink component
Blink>Payments

TAG review
None

TAG review status
Not applicable

Risks
We will proceed to first measure the number of users that are currently making payments via payment handlers with standardized payment method identifiers. We expect this number to be small, because our existing metrics show that "basic-card," for example, is a relatively small portion of all payment flows.

Interoperability and Compatibility
None - only Blink has implemented payment handlers.

    Gecko: No signal
    WebKit: No signal
    Web developers: No signals

Is this feature fully tested by web-platform-tests?
Yes.

Tracking bug
https://crbug.com/1159510

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5717324021628928

This intent message was generated by Chrome Platform Status.

Chris Harrelson

unread,
Dec 17, 2020, 3:30:56 PM12/17/20
to Rouslan Solomakhin, blink-dev
Hi,

Is there a risk that this removal would break any existing content with legitimate use-cases? If so, how much?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWFxVZn0H%3DgZkPCZ%2Bj13vjT-hqjtO44D7E8%3DwQ%2B-B-2jfQ%40mail.gmail.com.

Rouslan Solomakhin

unread,
Dec 17, 2020, 3:48:31 PM12/17/20
to Chris Harrelson, blink-dev
Hello,

We don't think there is a significant ris, because we've been pitching to 3rd party payment app providers to become payment handlers for "basic-card" for a couple of years now and have had no traction. Other payment methods have been allow-listed for payment handler use when they were demoed, but later gained no traction in production. We suspect that there are zero such payment handlers in production today. I'm adding a use counter just in case though: https://crrev.com/c/2595617.

If there are payment handlers with standardized payment method identifiers out there, then this change will make PaymentRequest.canMakePayment() and PaymentRequest.hasEnrolledInstrument() return false. Also, PaymentRequest.show() will return a NotSupportedError. The browser will behave as if the user never installed a payment handler. Usually merchants fallback to alternative methods of payment in such cases, such as HTML forms that the browser can autofill.

One special case is basic-card, where the browser can present its own UI for the user to add a card to the browser's autofill storage, which can then be used in the basic-card response to PaymentRequest.show(). However, we are separately considering removing the browser UI for basic-card, because it constitutes the majority of Web Payment code, but a minority of PaymentRequest usage in production.

Cheers,
Rouslan

Daniel Bratell

unread,
Jan 7, 2021, 2:25:52 PMJan 7
to Rouslan Solomakhin, Chris Harrelson, blink-dev

Looks like the use counter has not yet landed?

Is there any other counter that could be used as an upper limit on how many could be affected? If the true number is zero, maybe there is a proxy number that is close enough to zero as well.

/Daniel

Rouslan Solomakhin

unread,
Jan 11, 2021, 10:41:21 AMJan 11
to Daniel Bratell, Chris Harrelson, blink-dev
I have submitted the use counter to the commit queue today. Sorry for the delay -- this task has slipped between the cracks during the holiday season.

Our other counters show non-zero usage of related features, so let's wait for this counter to produce data before making the decision here.

Rouslan Solomakhin

unread,
Feb 2, 2021, 1:08:28 PMFeb 2
to Daniel Bratell, Chris Harrelson, blink-dev

Mike West

unread,
Feb 4, 2021, 3:16:25 PMFeb 4
to Rouslan Solomakhin, Daniel Bratell, Chris Harrelson, blink-dev
I looked internally at the histograms, and you're right. There's zero usage on Canary, Dev, and Beta. That's kinda suspicious? The web is large, and I kinda would have expected at least one hit. Are we confident that the counter is good?

If so, and there's literally zero usage through Beta, then this seems reasonable to just remove.

-mike

Rouslan Solomakhin

unread,
Feb 16, 2021, 4:41:51 PMFeb 16
to Mike West, Daniel Bratell, Chris Harrelson, blink-dev
My explorations show that the code path with the counter is being hit. The low usage reflects our understanding of the industry picture, however I would prefer to wait a few weeks until the counter is in stable to be absolutely confident that removal will be safe, if that's alright with you.

Yoav Weiss

unread,
Mar 18, 2021, 6:11:39 AMMar 18
to blink-dev, Rouslan Solomakhin, Daniel Bratell, Chris Harrelson, blink-dev, Mike West
Any news on the data front?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Rouslan Solomakhin

unread,
Mar 18, 2021, 9:06:39 AMMar 18
to Yoav Weiss, blink-dev, Daniel Bratell, Chris Harrelson, Mike West
Looks like our expectations were confirmed: There is no usage of this feature in production. OK to remove?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Mike West

unread,
Mar 18, 2021, 9:18:36 AMMar 18
to Rouslan Solomakhin, Yoav Weiss, blink-dev, Daniel Bratell, Chris Harrelson
LGTM1.

-mike

Yoav Weiss

unread,
Mar 18, 2021, 9:29:08 AMMar 18
to Mike West, Rouslan Solomakhin, blink-dev, Daniel Bratell, Chris Harrelson
LGTM2

Chris Harrelson

unread,
Mar 18, 2021, 10:55:43 AMMar 18
to Yoav Weiss, Mike West, Rouslan Solomakhin, blink-dev, Daniel Bratell
Reply all
Reply to author
Forward
0 new messages