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

[Rouslan Solomakhin]

Contact emails
rou...@chromium.org

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

https://w3c.github.io/payment-method-id/#standardized-payment-method-identifiers
https://w3c.github.io/payment-method-basic-card/

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]

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]

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]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWHgpQhw-jxE-AN90j83ODdJ1A_uQzk1DSW1qfgL-T18kw%40mail.gmail.com.

[Rouslan Solomakhin]

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]

As a follow up, the use counter is currently in Beta: https://chromiumdash.appspot.com/commit/9597ec506faee7258037f2e92c55057ef439279b

So far no data has been collected: https://chromestatus.com/metrics/feature/timeline/popularity/3750

[Mike West]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWGbauUimpHK%2BXO7ZbwX3REfYKsPpoZuMULwniqLzG_e1g%40mail.gmail.com.

[Rouslan Solomakhin]

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]

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.

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.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWHgpQhw-jxE-AN90j83ODdJ1A_uQzk1DSW1qfgL-T18kw%40mail.gmail.com.

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

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.

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.

--
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/CAMMzaWHgpQhw-jxE-AN90j83ODdJ1A_uQzk1DSW1qfgL-T18kw%40mail.gmail.com.

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

LGTM1.

-mike

[Yoav Weiss]

LGTM2

[Chris Harrelson]

Lgtm3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXc93Vpo2rurQ49ExnUd0tN5erXe2E8PxK5m0-XbPCpJA%40mail.gmail.com.