Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Rouslan Solomakhin]

Eiji published the deprecation article to the Chromium blog: 
https://blog.chromium.org/2021/10/sunsetting-basic-card-payment-method-in.html. 
Thank you, Eiji!

On Thursday, September 30, 2021 at 4:29:03 AM UTC-4 Daniel Bratell wrote:

> LGTM3
>
> Thanks for making this change easier for web developers!
>
> /Daniel
> On 2021-09-29 23:14, Liquan (Max) Gu wrote:
>
> Thanks for the review!
>
> On Wednesday, September 29, 2021 at 2:07:18 AM UTC-4 mk...@chromium.org 
> wrote:
>
>> LGTM2. Thanks for following up on the feedback here. 
>>
>> -mike
>>
>>
>> On Wed, Sep 29, 2021 at 7:56 AM Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Wed, Sep 29, 2021 at 7:50 AM Eiji Kitamura  
>>> wrote:
>>>
 I'll be working on it.

>>>
>>> That's great! Thanks Eiji! :)
>>>  
>>>

 On Wed, Sep 29, 2021 at 2:48 PM Yoav Weiss  
 wrote:

> Thanks for fixing up the documentation. 
>
> LGTM1 to run a 4 milestone deprecation and then remove. I wonder if 
> it'd also make sense to write a dedicated announcement blog post, to 
> inform 
> folks that don't follow blink-dev of these changes.
>
> On Tue, Sep 28, 2021 at 7:29 PM Liquan (Max) Gu  
> wrote:
>
>> Yoav, MDN (PR 
>> ) and 
>> web.dev (PR ) 
>> have taken down the basic-card content.
>>
>> Is it enough to get our approval for deprecating basic-card?
>>
>> On Thu, Sep 23, 2021 at 9:12 PM Patrick Guerrero  
>> wrote:
>>
>>>
>>> https://www.google.com/adsense/new/u/0/pub-4013500751301578/payments/?place=USER_MANAGEMENT
>>>
>>> On Wednesday, September 22, 2021 at 11:59:57 AM UTC-6 Liquan (Max) 
>>> Gu wrote:
>>>
 Yep! We are working  
 with @Joe Medley on updating the MDN documentation.

 On Tue, Sep 21, 2021 at 2:32 AM Yoav Weiss  
 wrote:

>
>
> On Mon, Sep 20, 2021 at 9:16 PM Liquan (Max) Gu  
> wrote:
>
>> Rouslan has sent a bunch of emails to the owners of the 
>> documentation:
>>
>>- Samsung: 
>>   - Samsung is removing their doc referencing “basic-card”. 
>>   They will keep us posted. 
>>- web.dev: 
>>   - Eiji is updating web.dev with a PR 
>>    (
>>   preview 
>>   
>> 
>>   ). 
>>- whatwebcando  
>>   - Rouslan has requested Adam to remove it. No response yet. 
>>- MDN 
>>
>> 
>>: 
>>   - Rouslan filed https://github.com/mdn/content/issues/8828 
>> where 
>>   the owner is looking for someone with bandwidth to update  
>>
>>
> Would the team be able to write an initial draft and work with the 
> relevant tech writers? Fixing up MDN seems critical for this 
> deprecation to 
> be successful.
>  
>
>>
>>- Adyen 
>>
>> 
>>: 
>>   - They are reaching out to the owner to update the 
>>   article, or will connect Rouslan Solomakhin with the article 
>> author. (meeting 
>>   note 
>>   
>> 
>>   ). 
>>
>>
>>
>> On Mon, Sep 20, 2021 at 3:06 PM Yoav Weiss  
>> wrote:
>>
>>> Thanks! Any word on PRs to MDN and other existing documentation?
>>>
>>> On Mon, Sep 20, 2021 at 8:48 PM Liquan (Max) Gu <
>>> ma...@google.com> wrote:
>>>
 Hi folks, 

 Thanks for your patience. We ended up adding the timeline and 
 alternatives to 
 https://www.chromestatus.com/feature/573005107056. Eiji is 
 in the process of writing a blog post that will be published at 
 https://web.dev/payment-request-basic-card-deprecation which 
 is about the deprecation. I will add the web.dev article to 
 Chrome status once the article is ready. On the console warning 
 front, I am 
 in the process of adding basic-card deprecation to the Reporting 
 API 
 , 
 which will print a warning that links to the

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

['Liquan (Max) Gu' via blink-dev]

Thanks for the review!

On Wednesday, September 29, 2021 at 2:07:18 AM UTC-4 mk...@chromium.org 
wrote:

> LGTM2. Thanks for following up on the feedback here.
>
> -mike
>
>
> On Wed, Sep 29, 2021 at 7:56 AM Yoav Weiss  wrote:
>
>>
>>
>> On Wed, Sep 29, 2021 at 7:50 AM Eiji Kitamura  
>> wrote:
>>
>>> I'll be working on it.
>>>
>>
>> That's great! Thanks Eiji! :)
>>  
>>
>>>
>>> On Wed, Sep 29, 2021 at 2:48 PM Yoav Weiss  wrote:
>>>
 Thanks for fixing up the documentation.

 LGTM1 to run a 4 milestone deprecation and then remove. I wonder if 
 it'd also make sense to write a dedicated announcement blog post, to 
 inform 
 folks that don't follow blink-dev of these changes.

 On Tue, Sep 28, 2021 at 7:29 PM Liquan (Max) Gu  
 wrote:

> Yoav, MDN (PR 
> ) and 
> web.dev (PR ) have 
> taken down the basic-card content.
>
> Is it enough to get our approval for deprecating basic-card?
>
> On Thu, Sep 23, 2021 at 9:12 PM Patrick Guerrero  
> wrote:
>
>>
>> https://www.google.com/adsense/new/u/0/pub-4013500751301578/payments/?place=USER_MANAGEMENT
>>
>> On Wednesday, September 22, 2021 at 11:59:57 AM UTC-6 Liquan (Max) Gu 
>> wrote:
>>
>>> Yep! We are working  
>>> with @Joe Medley on updating the MDN documentation.
>>>
>>> On Tue, Sep 21, 2021 at 2:32 AM Yoav Weiss  
>>> wrote:
>>>


 On Mon, Sep 20, 2021 at 9:16 PM Liquan (Max) Gu  
 wrote:

> Rouslan has sent a bunch of emails to the owners of the 
> documentation:
>
>- Samsung:
>   - Samsung is removing their doc referencing “basic-card”. 
>   They will keep us posted.
>- web.dev:
>   - Eiji is updating web.dev with a PR 
>    (preview 
>   
> 
>   ).
>- whatwebcando 
>   - Rouslan has requested Adam to remove it. No response yet.
>- MDN 
>
> 
>:
>   - Rouslan filed https://github.com/mdn/content/issues/8828 
> where 
>   the owner is looking for someone with bandwidth to update 
>
>
 Would the team be able to write an initial draft and work with the 
 relevant tech writers? Fixing up MDN seems critical for this 
 deprecation to 
 be successful.
  

>
>- Adyen 
>
> 
>:
>   - They are reaching out to the owner to update the article, 
>   or will connect Rouslan Solomakhin with the article author. 
> (meeting 
>   note 
>   
> 
>   ).
>
>
>
> On Mon, Sep 20, 2021 at 3:06 PM Yoav Weiss  
> wrote:
>
>> Thanks! Any word on PRs to MDN and other existing documentation?
>>
>> On Mon, Sep 20, 2021 at 8:48 PM Liquan (Max) Gu  
>> wrote:
>>
>>> Hi folks,
>>>
>>> Thanks for your patience. We ended up adding the timeline and 
>>> alternatives to 
>>> https://www.chromestatus.com/feature/573005107056. Eiji is 
>>> in the process of writing a blog post that will be published at 
>>> https://web.dev/payment-request-basic-card-deprecation which is 
>>> about the deprecation. I will add the web.dev article to Chrome 
>>> status once the article is ready. On the console warning front, I 
>>> am in the 
>>> process of adding basic-card deprecation to the Reporting API 
>>> , 
>>> which will print a warning that links to the chrome status as below.
>>>
>>> [image: Screen Shot 2021-09-20 at 14.02.52.png]
>>>
>>> Does the whole thing look good to you? Please let us know. 
>>> Thanks!
>>>
>>> On Fri, Sep 17, 2021 at 7:06 AM Mike West  
>>> wrote:
>>>
 Technically, yes. Deprecation warnings should only land when 
 we're _actually_ going to deprecate a thing, and have a reasonable 
 schedule 
 to point to.

 Here, though, I think we have agre

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Mike West]

LGTM2. Thanks for following up on the feedback here.

-mike


On Wed, Sep 29, 2021 at 7:56 AM Yoav Weiss  wrote:

>
>
> On Wed, Sep 29, 2021 at 7:50 AM Eiji Kitamura 
> wrote:
>
>> I'll be working on it.
>>
>
> That's great! Thanks Eiji! :)
>
>
>>
>> On Wed, Sep 29, 2021 at 2:48 PM Yoav Weiss 
>> wrote:
>>
>>> Thanks for fixing up the documentation.
>>>
>>> LGTM1 to run a 4 milestone deprecation and then remove. I wonder if it'd
>>> also make sense to write a dedicated announcement blog post, to inform
>>> folks that don't follow blink-dev of these changes.
>>>
>>> On Tue, Sep 28, 2021 at 7:29 PM Liquan (Max) Gu 
>>> wrote:
>>>
 Yoav, MDN (PR
 ) and
 web.dev (PR ) have
 taken down the basic-card content.

 Is it enough to get our approval for deprecating basic-card?

 On Thu, Sep 23, 2021 at 9:12 PM Patrick Guerrero 
 wrote:

>
> https://www.google.com/adsense/new/u/0/pub-4013500751301578/payments/?place=USER_MANAGEMENT
>
> On Wednesday, September 22, 2021 at 11:59:57 AM UTC-6 Liquan (Max) Gu
> wrote:
>
>> Yep! We are working 
>> with @Joe Medley on updating the MDN documentation.
>>
>> On Tue, Sep 21, 2021 at 2:32 AM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Mon, Sep 20, 2021 at 9:16 PM Liquan (Max) Gu 
>>> wrote:
>>>
 Rouslan has sent a bunch of emails to the owners of the
 documentation:

- Samsung:
   - Samsung is removing their doc referencing “basic-card”.
   They will keep us posted.
- web.dev:
   - Eiji is updating web.dev with a PR
    (preview
   
 
   ).
- whatwebcando 
   - Rouslan has requested Adam to remove it. No response yet.
- MDN

 
:
   - Rouslan filed https://github.com/mdn/content/issues/8828 where
   the owner is looking for someone with bandwidth to update


>>> Would the team be able to write an initial draft and work with the
>>> relevant tech writers? Fixing up MDN seems critical for this 
>>> deprecation to
>>> be successful.
>>>
>>>

- Adyen

 
:
   - They are reaching out to the owner to update the article,
   or will connect Rouslan Solomakhin with the article author. 
 (meeting
   note
   
 
   ).



 On Mon, Sep 20, 2021 at 3:06 PM Yoav Weiss 
 wrote:

> Thanks! Any word on PRs to MDN and other existing documentation?
>
> On Mon, Sep 20, 2021 at 8:48 PM Liquan (Max) Gu 
> wrote:
>
>> Hi folks,
>>
>> Thanks for your patience. We ended up adding the timeline and
>> alternatives to
>> https://www.chromestatus.com/feature/573005107056. Eiji is
>> in the process of writing a blog post that will be published at
>> https://web.dev/payment-request-basic-card-deprecation which is
>> about the deprecation. I will add the web.dev article to Chrome
>> status once the article is ready. On the console warning front, I am 
>> in the
>> process of adding basic-card deprecation to the Reporting API
>> ,
>> which will print a warning that links to the chrome status as below.
>>
>> [image: Screen Shot 2021-09-20 at 14.02.52.png]
>>
>> Does the whole thing look good to you? Please let us know. Thanks!
>>
>> On Fri, Sep 17, 2021 at 7:06 AM Mike West 
>> wrote:
>>
>>> Technically, yes. Deprecation warnings should only land when
>>> we're _actually_ going to deprecate a thing, and have a reasonable 
>>> schedule
>>> to point to.
>>>
>>> Here, though, I think we have agreement that the deprecation
>>> itself is reasonable, and agreement on a schedule. We're only 
>>> blocking on
>>> documentation of alternatives and developer awareness, both of which
>>> deprecation warnings support. So, I'd LGTM CLs that added warnings 
>>> if you
>>> wan

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Yoav Weiss]

On Wed, Sep 29, 2021 at 7:50 AM Eiji Kitamura  wrote:

> I'll be working on it.
>

That's great! Thanks Eiji! :)


>
> On Wed, Sep 29, 2021 at 2:48 PM Yoav Weiss  wrote:
>
>> Thanks for fixing up the documentation.
>>
>> LGTM1 to run a 4 milestone deprecation and then remove. I wonder if it'd
>> also make sense to write a dedicated announcement blog post, to inform
>> folks that don't follow blink-dev of these changes.
>>
>> On Tue, Sep 28, 2021 at 7:29 PM Liquan (Max) Gu  wrote:
>>
>>> Yoav, MDN (PR
>>> ) and
>>> web.dev (PR ) have
>>> taken down the basic-card content.
>>>
>>> Is it enough to get our approval for deprecating basic-card?
>>>
>>> On Thu, Sep 23, 2021 at 9:12 PM Patrick Guerrero 
>>> wrote:
>>>

 https://www.google.com/adsense/new/u/0/pub-4013500751301578/payments/?place=USER_MANAGEMENT

 On Wednesday, September 22, 2021 at 11:59:57 AM UTC-6 Liquan (Max) Gu
 wrote:

> Yep! We are working  with @Joe
> Medley on updating the MDN documentation.
>
> On Tue, Sep 21, 2021 at 2:32 AM Yoav Weiss 
> wrote:
>
>>
>>
>> On Mon, Sep 20, 2021 at 9:16 PM Liquan (Max) Gu 
>> wrote:
>>
>>> Rouslan has sent a bunch of emails to the owners of the
>>> documentation:
>>>
>>>- Samsung:
>>>   - Samsung is removing their doc referencing “basic-card”.
>>>   They will keep us posted.
>>>- web.dev:
>>>   - Eiji is updating web.dev with a PR
>>>    (preview
>>>   
>>> 
>>>   ).
>>>- whatwebcando 
>>>   - Rouslan has requested Adam to remove it. No response yet.
>>>- MDN
>>>
>>> 
>>>:
>>>   - Rouslan filed https://github.com/mdn/content/issues/8828 where
>>>   the owner is looking for someone with bandwidth to update
>>>
>>>
>> Would the team be able to write an initial draft and work with the
>> relevant tech writers? Fixing up MDN seems critical for this deprecation 
>> to
>> be successful.
>>
>>
>>>
>>>- Adyen
>>>
>>> 
>>>:
>>>   - They are reaching out to the owner to update the article,
>>>   or will connect Rouslan Solomakhin with the article author. 
>>> (meeting
>>>   note
>>>   
>>> 
>>>   ).
>>>
>>>
>>>
>>> On Mon, Sep 20, 2021 at 3:06 PM Yoav Weiss 
>>> wrote:
>>>
 Thanks! Any word on PRs to MDN and other existing documentation?

 On Mon, Sep 20, 2021 at 8:48 PM Liquan (Max) Gu 
 wrote:

> Hi folks,
>
> Thanks for your patience. We ended up adding the timeline and
> alternatives to
> https://www.chromestatus.com/feature/573005107056. Eiji is in
> the process of writing a blog post that will be published at
> https://web.dev/payment-request-basic-card-deprecation which is
> about the deprecation. I will add the web.dev article to Chrome
> status once the article is ready. On the console warning front, I am 
> in the
> process of adding basic-card deprecation to the Reporting API
> ,
> which will print a warning that links to the chrome status as below.
>
> [image: Screen Shot 2021-09-20 at 14.02.52.png]
>
> Does the whole thing look good to you? Please let us know. Thanks!
>
> On Fri, Sep 17, 2021 at 7:06 AM Mike West 
> wrote:
>
>> Technically, yes. Deprecation warnings should only land when
>> we're _actually_ going to deprecate a thing, and have a reasonable 
>> schedule
>> to point to.
>>
>> Here, though, I think we have agreement that the deprecation
>> itself is reasonable, and agreement on a schedule. We're only 
>> blocking on
>> documentation of alternatives and developer awareness, both of which
>> deprecation warnings support. So, I'd LGTM CLs that added warnings 
>> if you
>> wanted to send them my way.
>>
>> -mike
>>
>>
>> On Thu, Sep 16, 2021 at 9:17 PM Rouslan Solomakhin <
>> rou...@chromium.org> wrote:
>>
>>> HI Mike,
>>>
>>> We've been working on upd

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Eiji Kitamura]

I'll be working on it.

On Wed, Sep 29, 2021 at 2:48 PM Yoav Weiss  wrote:

> Thanks for fixing up the documentation.
>
> LGTM1 to run a 4 milestone deprecation and then remove. I wonder if it'd
> also make sense to write a dedicated announcement blog post, to inform
> folks that don't follow blink-dev of these changes.
>
> On Tue, Sep 28, 2021 at 7:29 PM Liquan (Max) Gu  wrote:
>
>> Yoav, MDN (PR
>> ) and
>> web.dev (PR ) have
>> taken down the basic-card content.
>>
>> Is it enough to get our approval for deprecating basic-card?
>>
>> On Thu, Sep 23, 2021 at 9:12 PM Patrick Guerrero 
>> wrote:
>>
>>>
>>> https://www.google.com/adsense/new/u/0/pub-4013500751301578/payments/?place=USER_MANAGEMENT
>>>
>>> On Wednesday, September 22, 2021 at 11:59:57 AM UTC-6 Liquan (Max) Gu
>>> wrote:
>>>
 Yep! We are working  with @Joe
 Medley on updating the MDN documentation.

 On Tue, Sep 21, 2021 at 2:32 AM Yoav Weiss 
 wrote:

>
>
> On Mon, Sep 20, 2021 at 9:16 PM Liquan (Max) Gu 
> wrote:
>
>> Rouslan has sent a bunch of emails to the owners of the documentation:
>>
>>- Samsung:
>>   - Samsung is removing their doc referencing “basic-card”. They
>>   will keep us posted.
>>- web.dev:
>>   - Eiji is updating web.dev with a PR
>>    (preview
>>   
>> 
>>   ).
>>- whatwebcando 
>>   - Rouslan has requested Adam to remove it. No response yet.
>>- MDN
>>
>>:
>>   - Rouslan filed https://github.com/mdn/content/issues/8828 where
>>   the owner is looking for someone with bandwidth to update
>>
>>
> Would the team be able to write an initial draft and work with the
> relevant tech writers? Fixing up MDN seems critical for this deprecation 
> to
> be successful.
>
>
>>
>>- Adyen
>>
>> 
>>:
>>   - They are reaching out to the owner to update the article, or
>>   will connect Rouslan Solomakhin with the article author. (meeting
>>   note
>>   
>> 
>>   ).
>>
>>
>>
>> On Mon, Sep 20, 2021 at 3:06 PM Yoav Weiss 
>> wrote:
>>
>>> Thanks! Any word on PRs to MDN and other existing documentation?
>>>
>>> On Mon, Sep 20, 2021 at 8:48 PM Liquan (Max) Gu 
>>> wrote:
>>>
 Hi folks,

 Thanks for your patience. We ended up adding the timeline and
 alternatives to
 https://www.chromestatus.com/feature/573005107056. Eiji is in
 the process of writing a blog post that will be published at
 https://web.dev/payment-request-basic-card-deprecation which is
 about the deprecation. I will add the web.dev article to Chrome
 status once the article is ready. On the console warning front, I am 
 in the
 process of adding basic-card deprecation to the Reporting API
 ,
 which will print a warning that links to the chrome status as below.

 [image: Screen Shot 2021-09-20 at 14.02.52.png]

 Does the whole thing look good to you? Please let us know. Thanks!

 On Fri, Sep 17, 2021 at 7:06 AM Mike West 
 wrote:

> Technically, yes. Deprecation warnings should only land when we're
> _actually_ going to deprecate a thing, and have a reasonable schedule 
> to
> point to.
>
> Here, though, I think we have agreement that the deprecation
> itself is reasonable, and agreement on a schedule. We're only 
> blocking on
> documentation of alternatives and developer awareness, both of which
> deprecation warnings support. So, I'd LGTM CLs that added warnings if 
> you
> wanted to send them my way.
>
> -mike
>
>
> On Thu, Sep 16, 2021 at 9:17 PM Rouslan Solomakhin <
> rou...@chromium.org> wrote:
>
>> HI Mike,
>>
>> We've been working on updating our docs and reaching out to
>> external documentation owners as well. We will respond back to this 
>> email
>> thread once we have significant progress to report :-D
>>
>> By the way, do we need to ge

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Yoav Weiss]

Thanks for fixing up the documentation.

LGTM1 to run a 4 milestone deprecation and then remove. I wonder if it'd
also make sense to write a dedicated announcement blog post, to inform
folks that don't follow blink-dev of these changes.

On Tue, Sep 28, 2021 at 7:29 PM Liquan (Max) Gu  wrote:

> Yoav, MDN (PR
> ) and web.dev
> (PR ) have taken down
> the basic-card content.
>
> Is it enough to get our approval for deprecating basic-card?
>
> On Thu, Sep 23, 2021 at 9:12 PM Patrick Guerrero 
> wrote:
>
>>
>> https://www.google.com/adsense/new/u/0/pub-4013500751301578/payments/?place=USER_MANAGEMENT
>>
>> On Wednesday, September 22, 2021 at 11:59:57 AM UTC-6 Liquan (Max) Gu
>> wrote:
>>
>>> Yep! We are working  with @Joe
>>> Medley on updating the MDN documentation.
>>>
>>> On Tue, Sep 21, 2021 at 2:32 AM Yoav Weiss  wrote:
>>>


 On Mon, Sep 20, 2021 at 9:16 PM Liquan (Max) Gu 
 wrote:

> Rouslan has sent a bunch of emails to the owners of the documentation:
>
>- Samsung:
>   - Samsung is removing their doc referencing “basic-card”. They
>   will keep us posted.
>- web.dev:
>   - Eiji is updating web.dev with a PR
>    (preview
>   
>   ).
>- whatwebcando 
>   - Rouslan has requested Adam to remove it. No response yet.
>- MDN
>
>:
>   - Rouslan filed https://github.com/mdn/content/issues/8828 where
>   the owner is looking for someone with bandwidth to update
>
>
 Would the team be able to write an initial draft and work with the
 relevant tech writers? Fixing up MDN seems critical for this deprecation to
 be successful.


>
>- Adyen
>
> 
>:
>   - They are reaching out to the owner to update the article, or
>   will connect Rouslan Solomakhin with the article author. (meeting
>   note
>   
> 
>   ).
>
>
>
> On Mon, Sep 20, 2021 at 3:06 PM Yoav Weiss 
> wrote:
>
>> Thanks! Any word on PRs to MDN and other existing documentation?
>>
>> On Mon, Sep 20, 2021 at 8:48 PM Liquan (Max) Gu 
>> wrote:
>>
>>> Hi folks,
>>>
>>> Thanks for your patience. We ended up adding the timeline and
>>> alternatives to
>>> https://www.chromestatus.com/feature/573005107056. Eiji is in
>>> the process of writing a blog post that will be published at
>>> https://web.dev/payment-request-basic-card-deprecation which is
>>> about the deprecation. I will add the web.dev article to Chrome
>>> status once the article is ready. On the console warning front, I am in 
>>> the
>>> process of adding basic-card deprecation to the Reporting API
>>> ,
>>> which will print a warning that links to the chrome status as below.
>>>
>>> [image: Screen Shot 2021-09-20 at 14.02.52.png]
>>>
>>> Does the whole thing look good to you? Please let us know. Thanks!
>>>
>>> On Fri, Sep 17, 2021 at 7:06 AM Mike West 
>>> wrote:
>>>
 Technically, yes. Deprecation warnings should only land when we're
 _actually_ going to deprecate a thing, and have a reasonable schedule 
 to
 point to.

 Here, though, I think we have agreement that the deprecation itself
 is reasonable, and agreement on a schedule. We're only blocking on
 documentation of alternatives and developer awareness, both of which
 deprecation warnings support. So, I'd LGTM CLs that added warnings if 
 you
 wanted to send them my way.

 -mike


 On Thu, Sep 16, 2021 at 9:17 PM Rouslan Solomakhin <
 rou...@chromium.org> wrote:

> HI Mike,
>
> We've been working on updating our docs and reaching out to
> external documentation owners as well. We will respond back to this 
> email
> thread once we have significant progress to report :-D
>
> By the way, do we need to get blink-dev@ approval for starting to
> print deprecation warnings in the Developer Console? I'm not sure 
> whether
> Developer Console warnings are considered web-facing.
>
> Cheers,
> Rous

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

['Liquan (Max) Gu' via blink-dev]

Yoav, MDN (PR )
and web.dev (PR ) have
taken down the basic-card content.

Is it enough to get our approval for deprecating basic-card?

On Thu, Sep 23, 2021 at 9:12 PM Patrick Guerrero 
wrote:

>
> https://www.google.com/adsense/new/u/0/pub-4013500751301578/payments/?place=USER_MANAGEMENT
>
> On Wednesday, September 22, 2021 at 11:59:57 AM UTC-6 Liquan (Max) Gu
> wrote:
>
>> Yep! We are working  with @Joe
>> Medley on updating the MDN documentation.
>>
>> On Tue, Sep 21, 2021 at 2:32 AM Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Mon, Sep 20, 2021 at 9:16 PM Liquan (Max) Gu 
>>> wrote:
>>>
 Rouslan has sent a bunch of emails to the owners of the documentation:

- Samsung:
   - Samsung is removing their doc referencing “basic-card”. They
   will keep us posted.
- web.dev:
   - Eiji is updating web.dev with a PR
    (preview
   
   ).
- whatwebcando 
   - Rouslan has requested Adam to remove it. No response yet.
- MDN

:
   - Rouslan filed https://github.com/mdn/content/issues/8828 where
   the owner is looking for someone with bandwidth to update


>>> Would the team be able to write an initial draft and work with the
>>> relevant tech writers? Fixing up MDN seems critical for this deprecation to
>>> be successful.
>>>
>>>

- Adyen

 
:
   - They are reaching out to the owner to update the article, or
   will connect Rouslan Solomakhin with the article author. (meeting
   note
   
 
   ).



 On Mon, Sep 20, 2021 at 3:06 PM Yoav Weiss 
 wrote:

> Thanks! Any word on PRs to MDN and other existing documentation?
>
> On Mon, Sep 20, 2021 at 8:48 PM Liquan (Max) Gu 
> wrote:
>
>> Hi folks,
>>
>> Thanks for your patience. We ended up adding the timeline and
>> alternatives to https://www.chromestatus.com/feature/573005107056.
>> Eiji is in the process of writing a blog post that will be published at
>> https://web.dev/payment-request-basic-card-deprecation which is
>> about the deprecation. I will add the web.dev article to Chrome
>> status once the article is ready. On the console warning front, I am in 
>> the
>> process of adding basic-card deprecation to the Reporting API
>> ,
>> which will print a warning that links to the chrome status as below.
>>
>> [image: Screen Shot 2021-09-20 at 14.02.52.png]
>>
>> Does the whole thing look good to you? Please let us know. Thanks!
>>
>> On Fri, Sep 17, 2021 at 7:06 AM Mike West  wrote:
>>
>>> Technically, yes. Deprecation warnings should only land when we're
>>> _actually_ going to deprecate a thing, and have a reasonable schedule to
>>> point to.
>>>
>>> Here, though, I think we have agreement that the deprecation itself
>>> is reasonable, and agreement on a schedule. We're only blocking on
>>> documentation of alternatives and developer awareness, both of which
>>> deprecation warnings support. So, I'd LGTM CLs that added warnings if 
>>> you
>>> wanted to send them my way.
>>>
>>> -mike
>>>
>>>
>>> On Thu, Sep 16, 2021 at 9:17 PM Rouslan Solomakhin <
>>> rou...@chromium.org> wrote:
>>>
 HI Mike,

 We've been working on updating our docs and reaching out to
 external documentation owners as well. We will respond back to this 
 email
 thread once we have significant progress to report :-D

 By the way, do we need to get blink-dev@ approval for starting to
 print deprecation warnings in the Developer Console? I'm not sure 
 whether
 Developer Console warnings are considered web-facing.

 Cheers,
 Rouslan

 On Thu, Sep 16, 2021 at 3:11 PM Mike West 
 wrote:

> Hey folks,
>
> We talked about this in the API owners meeting tonight, and I
> think folks are conceptually on board with this deprecation along the
> timeline we talked about above (4 milestones). That said, there's 
> still
> practical concern that the messaging for developers currently doesn't 
>>>

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Mike West]

Technically, yes. Deprecation warnings should only land when we're
_actually_ going to deprecate a thing, and have a reasonable schedule to
point to.

Here, though, I think we have agreement that the deprecation itself is
reasonable, and agreement on a schedule. We're only blocking on
documentation of alternatives and developer awareness, both of which
deprecation warnings support. So, I'd LGTM CLs that added warnings if you
wanted to send them my way.

-mike


On Thu, Sep 16, 2021 at 9:17 PM Rouslan Solomakhin 
wrote:

> HI Mike,
>
> We've been working on updating our docs and reaching out to external
> documentation owners as well. We will respond back to this email thread
> once we have significant progress to report :-D
>
> By the way, do we need to get blink-dev@ approval for starting to print
> deprecation warnings in the Developer Console? I'm not sure whether
> Developer Console warnings are considered web-facing.
>
> Cheers,
> Rouslan
>
> On Thu, Sep 16, 2021 at 3:11 PM Mike West  wrote:
>
>> Hey folks,
>>
>> We talked about this in the API owners meeting tonight, and I think folks
>> are conceptually on board with this deprecation along the timeline we
>> talked about above (4 milestones). That said, there's still practical
>> concern that the messaging for developers currently doesn't match the
>> requirements y'all are creating by removing `basic-card`, and we'd be much
>> more comfortable moving forward if we had concrete docs to point developers
>> to in any deprecation warning so they they have a clear migration path.
>>
>> If you can land some documentation changes, I think you'll quickly get
>> LGTMs for deprecation/removal.
>>
>> -mike
>>
>>
>> On Thu, Sep 16, 2021 at 8:03 PM Daniel Bratell 
>> wrote:
>>
>>> Good, because if not, I think it will leave the standard in a strange
>>> mess where a majority of the documentation will use constructs that no
>>> longer exists and that will make everyone unhappy.
>>>
>>> /Daniel
>>> On 2021-09-09 22:22, Rouslan Solomakhin wrote:
>>>
>>> Yes, we absolutely can fixup the docs that we own and reach out to the
>>> owners of the docs that we don't own ourselves.
>>>
>>> On Thu, Sep 9, 2021 at 4:21 PM Yoav Weiss 
>>> wrote:
>>>
 Would you also be able to fix up the documentation out there that's
 pointing at basic-card?
 A few places I see at a glance are MDN
 ,
 WebFundementals
 ,
 Whatwebcando  , ayden.com
 
  and samsung
 .
 It seems like with a few PRs and a bit of outreach, we can make sure that
 the API's canonical documentation points people in the right direction.

 On Thu, Sep 9, 2021 at 9:28 PM Rouslan Solomakhin 
 wrote:

> Sure, let's do 4 milestones. We can put the deprecation message in the
> developer console in M96 and perform the removal in M100.
>
> On Thu, Sep 9, 2021 at 3:26 PM Mike West  wrote:
>
>> Ok. Does ~4-5 milestones (M100-101 sound good to you?)
>>
>> -mike
>>
>>
>> On Thu, Sep 9, 2021 at 9:20 PM Rouslan Solomakhin <
>> rous...@chromium.org> wrote:
>>
>>> > a deprecation period before removal isn't an unreasonable path
>>> forward. WDYT
>>>
>>> That sounds reasonable to us. We are planning a blog post, too, by
>>> the way.
>>>
>>> (Responding on behalf of Stephen and Max because they happen to be
>>> both OOO today.)
>>>
>>> On Thu, Sep 9, 2021 at 2:57 PM Mike West  wrote:
>>>
 Given the UKM-driven manual analysis, I'm willing to believe that
 sites using this mechanism won't crumble if it's removed. That said, 
 the
 deprecation in the spec that you pointed to above landed ~2 weeks ago.
 Perhaps it's reasonable to extend developers' ability to conduct
 transactions through this mechanism for a release or three before 
 removing
 it, warning in the console about the deprecation, blog posting, etc.

 Perhaps I'm being unreasonably cautious here (and I'm totally
 willing to hear reasons that might be the case!), but it seems to me 
 that a
 deprecation period before removal isn't an unreasonable path forward. 
 WDYT?

 -mike


 On Thu, Sep 9, 2021 at 5:46 PM Daniel Bratell 
 wrote:

> When I looked around to see what other methods were available, it
> seemed to me like all documentation and explainers included 
> basic-card as
> the standard method, and few of them used anything else. I wonder if 
>

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Rouslan Solomakhin]

HI Mike,

We've been working on updating our docs and reaching out to external
documentation owners as well. We will respond back to this email thread
once we have significant progress to report :-D

By the way, do we need to get blink-dev@ approval for starting to print
deprecation warnings in the Developer Console? I'm not sure whether
Developer Console warnings are considered web-facing.

Cheers,
Rouslan

On Thu, Sep 16, 2021 at 3:11 PM Mike West  wrote:

> Hey folks,
>
> We talked about this in the API owners meeting tonight, and I think folks
> are conceptually on board with this deprecation along the timeline we
> talked about above (4 milestones). That said, there's still practical
> concern that the messaging for developers currently doesn't match the
> requirements y'all are creating by removing `basic-card`, and we'd be much
> more comfortable moving forward if we had concrete docs to point developers
> to in any deprecation warning so they they have a clear migration path.
>
> If you can land some documentation changes, I think you'll quickly get
> LGTMs for deprecation/removal.
>
> -mike
>
>
> On Thu, Sep 16, 2021 at 8:03 PM Daniel Bratell 
> wrote:
>
>> Good, because if not, I think it will leave the standard in a strange
>> mess where a majority of the documentation will use constructs that no
>> longer exists and that will make everyone unhappy.
>>
>> /Daniel
>> On 2021-09-09 22:22, Rouslan Solomakhin wrote:
>>
>> Yes, we absolutely can fixup the docs that we own and reach out to the
>> owners of the docs that we don't own ourselves.
>>
>> On Thu, Sep 9, 2021 at 4:21 PM Yoav Weiss  wrote:
>>
>>> Would you also be able to fix up the documentation out there that's
>>> pointing at basic-card?
>>> A few places I see at a glance are MDN
>>> ,
>>> WebFundementals
>>> ,
>>> Whatwebcando  , ayden.com
>>> 
>>>  and samsung
>>> .
>>> It seems like with a few PRs and a bit of outreach, we can make sure that
>>> the API's canonical documentation points people in the right direction.
>>>
>>> On Thu, Sep 9, 2021 at 9:28 PM Rouslan Solomakhin 
>>> wrote:
>>>
 Sure, let's do 4 milestones. We can put the deprecation message in the
 developer console in M96 and perform the removal in M100.

 On Thu, Sep 9, 2021 at 3:26 PM Mike West  wrote:

> Ok. Does ~4-5 milestones (M100-101 sound good to you?)
>
> -mike
>
>
> On Thu, Sep 9, 2021 at 9:20 PM Rouslan Solomakhin <
> rous...@chromium.org> wrote:
>
>> > a deprecation period before removal isn't an unreasonable path
>> forward. WDYT
>>
>> That sounds reasonable to us. We are planning a blog post, too, by
>> the way.
>>
>> (Responding on behalf of Stephen and Max because they happen to be
>> both OOO today.)
>>
>> On Thu, Sep 9, 2021 at 2:57 PM Mike West  wrote:
>>
>>> Given the UKM-driven manual analysis, I'm willing to believe that
>>> sites using this mechanism won't crumble if it's removed. That said, the
>>> deprecation in the spec that you pointed to above landed ~2 weeks ago.
>>> Perhaps it's reasonable to extend developers' ability to conduct
>>> transactions through this mechanism for a release or three before 
>>> removing
>>> it, warning in the console about the deprecation, blog posting, etc.
>>>
>>> Perhaps I'm being unreasonably cautious here (and I'm totally
>>> willing to hear reasons that might be the case!), but it seems to me 
>>> that a
>>> deprecation period before removal isn't an unreasonable path forward. 
>>> WDYT?
>>>
>>> -mike
>>>
>>>
>>> On Thu, Sep 9, 2021 at 5:46 PM Daniel Bratell 
>>> wrote:
>>>
 When I looked around to see what other methods were available, it
 seemed to me like all documentation and explainers included basic-card 
 as
 the standard method, and few of them used anything else. I wonder if 
 that
 means that it's too early to deprecate before documentation and specs 
 is
 updated to suggest alternatives.

 /Daniel


 On 2021-09-09 14:14, Stephen Mcgruer wrote:

 > Can you clarify what breakage may look like for sites that may
 rely on it?

 If a site was *entirely* relying on basic-card to collect credit
 card details from their user, it would be impossible for the user to
 complete their checkout. So arguably 'site completely broken' from that
 perspective (assuming buying a thing is the main user journey).
>

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Mike West]

Hey folks,

We talked about this in the API owners meeting tonight, and I think folks
are conceptually on board with this deprecation along the timeline we
talked about above (4 milestones). That said, there's still practical
concern that the messaging for developers currently doesn't match the
requirements y'all are creating by removing `basic-card`, and we'd be much
more comfortable moving forward if we had concrete docs to point developers
to in any deprecation warning so they they have a clear migration path.

If you can land some documentation changes, I think you'll quickly get
LGTMs for deprecation/removal.

-mike


On Thu, Sep 16, 2021 at 8:03 PM Daniel Bratell  wrote:

> Good, because if not, I think it will leave the standard in a strange mess
> where a majority of the documentation will use constructs that no longer
> exists and that will make everyone unhappy.
>
> /Daniel
> On 2021-09-09 22:22, Rouslan Solomakhin wrote:
>
> Yes, we absolutely can fixup the docs that we own and reach out to the
> owners of the docs that we don't own ourselves.
>
> On Thu, Sep 9, 2021 at 4:21 PM Yoav Weiss  wrote:
>
>> Would you also be able to fix up the documentation out there that's
>> pointing at basic-card?
>> A few places I see at a glance are MDN
>> ,
>> WebFundementals
>> ,
>> Whatwebcando  , ayden.com
>> 
>>  and samsung
>> .
>> It seems like with a few PRs and a bit of outreach, we can make sure that
>> the API's canonical documentation points people in the right direction.
>>
>> On Thu, Sep 9, 2021 at 9:28 PM Rouslan Solomakhin 
>> wrote:
>>
>>> Sure, let's do 4 milestones. We can put the deprecation message in the
>>> developer console in M96 and perform the removal in M100.
>>>
>>> On Thu, Sep 9, 2021 at 3:26 PM Mike West  wrote:
>>>
 Ok. Does ~4-5 milestones (M100-101 sound good to you?)

 -mike


 On Thu, Sep 9, 2021 at 9:20 PM Rouslan Solomakhin 
 wrote:

> > a deprecation period before removal isn't an unreasonable path
> forward. WDYT
>
> That sounds reasonable to us. We are planning a blog post, too, by the
> way.
>
> (Responding on behalf of Stephen and Max because they happen to be
> both OOO today.)
>
> On Thu, Sep 9, 2021 at 2:57 PM Mike West  wrote:
>
>> Given the UKM-driven manual analysis, I'm willing to believe that
>> sites using this mechanism won't crumble if it's removed. That said, the
>> deprecation in the spec that you pointed to above landed ~2 weeks ago.
>> Perhaps it's reasonable to extend developers' ability to conduct
>> transactions through this mechanism for a release or three before 
>> removing
>> it, warning in the console about the deprecation, blog posting, etc.
>>
>> Perhaps I'm being unreasonably cautious here (and I'm totally willing
>> to hear reasons that might be the case!), but it seems to me that a
>> deprecation period before removal isn't an unreasonable path forward. 
>> WDYT?
>>
>> -mike
>>
>>
>> On Thu, Sep 9, 2021 at 5:46 PM Daniel Bratell 
>> wrote:
>>
>>> When I looked around to see what other methods were available, it
>>> seemed to me like all documentation and explainers included basic-card 
>>> as
>>> the standard method, and few of them used anything else. I wonder if 
>>> that
>>> means that it's too early to deprecate before documentation and specs is
>>> updated to suggest alternatives.
>>>
>>> /Daniel
>>>
>>>
>>> On 2021-09-09 14:14, Stephen Mcgruer wrote:
>>>
>>> > Can you clarify what breakage may look like for sites that may
>>> rely on it?
>>>
>>> If a site was *entirely* relying on basic-card to collect credit
>>> card details from their user, it would be impossible for the user to
>>> complete their checkout. So arguably 'site completely broken' from that
>>> perspective (assuming buying a thing is the main user journey).
>>>
>>> However, such a site would also be broken on Firefox and Safari
>>> today (unless serving user-agent specific code), and sites also tend to 
>>> not
>>> rely on just one approach to get paid. Sites will almost definitely 
>>> have a
>>> fallback mechanism, and it will likely be invisible to the user. For
>>> example:
>>>
>>> 1. Site checks `if (window.PaymentRequest)` - passes in Chrome and
>>> Safari, fails in Firefox.
>>> 2. Site calls `new
>>> PaymentRequest([basic-card-data]).canMakePayment()` (or `show()` 
>>> directly)
>>> - passes in Chrome today, fail

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Daniel Bratell]

Good, because if not, I think it will leave the standard in a strange 
mess where a majority of the documentation will use constructs that no 
longer exists and that will make everyone unhappy.


/Daniel

On 2021-09-09 22:22, Rouslan Solomakhin wrote:
Yes, we absolutely can fixup the docs that we own and reach out to the 
owners of the docs that we don't own ourselves.


On Thu, Sep 9, 2021 at 4:21 PM Yoav Weiss > wrote:


Would you also be able to fix up the documentation out there
that's pointing at basic-card?
A few places I see at a glance are MDN
,
WebFundementals

,
Whatwebcando  ,
ayden.com
 
and
samsung

.
It seems like with a few PRs and a bit of outreach, we can make
sure that the API's canonical documentation points people in the
right direction.

On Thu, Sep 9, 2021 at 9:28 PM Rouslan Solomakhin
mailto:rous...@chromium.org>> wrote:

Sure, let's do 4 milestones. We can put the deprecation
message in the developer console in M96 and perform the
removal in M100.

On Thu, Sep 9, 2021 at 3:26 PM Mike West mailto:mk...@chromium.org>> wrote:

Ok. Does ~4-5 milestones (M100-101 sound good to you?)

-mike


On Thu, Sep 9, 2021 at 9:20 PM Rouslan Solomakhin
mailto:rous...@chromium.org>> wrote:

> a deprecation period before removal isn't an
unreasonable path forward. WDYT

That sounds reasonable to us. We are planning a blog
post, too, by the way.

(Responding on behalf of Stephen and Max because they
happen to be both OOO today.)

On Thu, Sep 9, 2021 at 2:57 PM Mike West
mailto:mk...@chromium.org>> wrote:

Given the UKM-driven manual analysis, I'm willing
to believe that sites using this mechanism won't
crumble if it's removed. That said, the
deprecation in the spec that you pointed to above
landed ~2 weeks ago. Perhaps it's reasonable to
extend developers' ability to conduct transactions
through this mechanism for a release or three
before removing it, warning in the console about
the deprecation, blog posting, etc.

Perhaps I'm being unreasonably cautious here (and
I'm totally willing to hear reasons that might be
the case!), but it seems to me that a deprecation
period before removal isn't an unreasonable path
forward. WDYT?

-mike


On Thu, Sep 9, 2021 at 5:46 PM Daniel Bratell
mailto:bratel...@gmail.com>>
wrote:

When I looked around to see what other methods
were available, it seemed to me like all
documentation and explainers included
basic-card as the standard method, and few of
them used anything else. I wonder if that
means that it's too early to deprecate before
documentation and specs is updated to suggest
alternatives.

/Daniel


On 2021-09-09 14:14, Stephen Mcgruer wrote:

> Can you clarify what breakage may look like
for sites that may rely on it?

If a site was *entirely* relying on
basic-card to collect credit card details
from their user, it would be impossible for
the user to complete their checkout. So
arguably 'site completely broken' from that
perspective (assuming buying a thing is the
main user journey).

However, such a site would also be broken on
Firefox and Safari today (unless serving
user-agent specific code), and sites also
tend to not rely on just one approach to get
paid. Sites will almost definitely have a
fallback mechanism, and it will likely be
invisible to the user. For example:

1. Site checks `if (window.Payment

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Rouslan Solomakhin]

Yes, we absolutely can fixup the docs that we own and reach out to the
owners of the docs that we don't own ourselves.

On Thu, Sep 9, 2021 at 4:21 PM Yoav Weiss  wrote:

> Would you also be able to fix up the documentation out there that's
> pointing at basic-card?
> A few places I see at a glance are MDN
> ,
> WebFundementals
> ,
> Whatwebcando  , ayden.com
> 
>  and samsung
> .
> It seems like with a few PRs and a bit of outreach, we can make sure that
> the API's canonical documentation points people in the right direction.
>
> On Thu, Sep 9, 2021 at 9:28 PM Rouslan Solomakhin 
> wrote:
>
>> Sure, let's do 4 milestones. We can put the deprecation message in the
>> developer console in M96 and perform the removal in M100.
>>
>> On Thu, Sep 9, 2021 at 3:26 PM Mike West  wrote:
>>
>>> Ok. Does ~4-5 milestones (M100-101 sound good to you?)
>>>
>>> -mike
>>>
>>>
>>> On Thu, Sep 9, 2021 at 9:20 PM Rouslan Solomakhin 
>>> wrote:
>>>
 > a deprecation period before removal isn't an unreasonable path
 forward. WDYT

 That sounds reasonable to us. We are planning a blog post, too, by the
 way.

 (Responding on behalf of Stephen and Max because they happen to be both
 OOO today.)

 On Thu, Sep 9, 2021 at 2:57 PM Mike West  wrote:

> Given the UKM-driven manual analysis, I'm willing to believe that
> sites using this mechanism won't crumble if it's removed. That said, the
> deprecation in the spec that you pointed to above landed ~2 weeks ago.
> Perhaps it's reasonable to extend developers' ability to conduct
> transactions through this mechanism for a release or three before removing
> it, warning in the console about the deprecation, blog posting, etc.
>
> Perhaps I'm being unreasonably cautious here (and I'm totally willing
> to hear reasons that might be the case!), but it seems to me that a
> deprecation period before removal isn't an unreasonable path forward. 
> WDYT?
>
> -mike
>
>
> On Thu, Sep 9, 2021 at 5:46 PM Daniel Bratell 
> wrote:
>
>> When I looked around to see what other methods were available, it
>> seemed to me like all documentation and explainers included basic-card as
>> the standard method, and few of them used anything else. I wonder if that
>> means that it's too early to deprecate before documentation and specs is
>> updated to suggest alternatives.
>>
>> /Daniel
>>
>>
>> On 2021-09-09 14:14, Stephen Mcgruer wrote:
>>
>> > Can you clarify what breakage may look like for sites that may rely
>> on it?
>>
>> If a site was *entirely* relying on basic-card to collect credit
>> card details from their user, it would be impossible for the user to
>> complete their checkout. So arguably 'site completely broken' from that
>> perspective (assuming buying a thing is the main user journey).
>>
>> However, such a site would also be broken on Firefox and Safari today
>> (unless serving user-agent specific code), and sites also tend to not 
>> rely
>> on just one approach to get paid. Sites will almost definitely have a
>> fallback mechanism, and it will likely be invisible to the user. For
>> example:
>>
>> 1. Site checks `if (window.PaymentRequest)` - passes in Chrome and
>> Safari, fails in Firefox.
>> 2. Site calls `new
>> PaymentRequest([basic-card-data]).canMakePayment()` (or `show()` 
>> directly)
>> - passes in Chrome today, fails/throws in Safari.
>> 3. If either of #1 or #2 failed, render a fallback payment
>> information collection flow such as a HTML form.
>>
>> TL;DR - we expect very few to no sites to break due to this removal,
>> unless they're doing user-agent specific branching with no fallback
>> mechanisms for 'what if basic-card fails'.
>>
>> On Thu, 9 Sept 2021 at 08:03, Yoav Weiss 
>> wrote:
>>
>>> Can you clarify what breakage may look like for sites that may rely
>>> on it?
>>>
>>> On Tuesday, September 7, 2021 at 2:34:46 PM UTC+2 Stephen McGruer
>>> wrote:
>>>
 > Any usecounter stats you can share?

 Unfortunately no usecounters for two reasons:

 1) Payment APIs in general have very low usage when compared to
 'page loads', because the most popular sites on the web aren't 
 merchants
 and so don't use them. For example, PaymentRequest.show is at 0.001
 .
 They're s

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Yoav Weiss]

Would you also be able to fix up the documentation out there that's
pointing at basic-card?
A few places I see at a glance are MDN
,
WebFundementals
,
Whatwebcando  , ayden.com

 and samsung
.
It seems like with a few PRs and a bit of outreach, we can make sure that
the API's canonical documentation points people in the right direction.

On Thu, Sep 9, 2021 at 9:28 PM Rouslan Solomakhin 
wrote:

> Sure, let's do 4 milestones. We can put the deprecation message in the
> developer console in M96 and perform the removal in M100.
>
> On Thu, Sep 9, 2021 at 3:26 PM Mike West  wrote:
>
>> Ok. Does ~4-5 milestones (M100-101 sound good to you?)
>>
>> -mike
>>
>>
>> On Thu, Sep 9, 2021 at 9:20 PM Rouslan Solomakhin 
>> wrote:
>>
>>> > a deprecation period before removal isn't an unreasonable path
>>> forward. WDYT
>>>
>>> That sounds reasonable to us. We are planning a blog post, too, by the
>>> way.
>>>
>>> (Responding on behalf of Stephen and Max because they happen to be both
>>> OOO today.)
>>>
>>> On Thu, Sep 9, 2021 at 2:57 PM Mike West  wrote:
>>>
 Given the UKM-driven manual analysis, I'm willing to believe that sites
 using this mechanism won't crumble if it's removed. That said, the
 deprecation in the spec that you pointed to above landed ~2 weeks ago.
 Perhaps it's reasonable to extend developers' ability to conduct
 transactions through this mechanism for a release or three before removing
 it, warning in the console about the deprecation, blog posting, etc.

 Perhaps I'm being unreasonably cautious here (and I'm totally willing
 to hear reasons that might be the case!), but it seems to me that a
 deprecation period before removal isn't an unreasonable path forward. WDYT?

 -mike


 On Thu, Sep 9, 2021 at 5:46 PM Daniel Bratell 
 wrote:

> When I looked around to see what other methods were available, it
> seemed to me like all documentation and explainers included basic-card as
> the standard method, and few of them used anything else. I wonder if that
> means that it's too early to deprecate before documentation and specs is
> updated to suggest alternatives.
>
> /Daniel
>
>
> On 2021-09-09 14:14, Stephen Mcgruer wrote:
>
> > Can you clarify what breakage may look like for sites that may rely
> on it?
>
> If a site was *entirely* relying on basic-card to collect credit card
> details from their user, it would be impossible for the user to complete
> their checkout. So arguably 'site completely broken' from that perspective
> (assuming buying a thing is the main user journey).
>
> However, such a site would also be broken on Firefox and Safari today
> (unless serving user-agent specific code), and sites also tend to not rely
> on just one approach to get paid. Sites will almost definitely have a
> fallback mechanism, and it will likely be invisible to the user. For
> example:
>
> 1. Site checks `if (window.PaymentRequest)` - passes in Chrome and
> Safari, fails in Firefox.
> 2. Site calls `new PaymentRequest([basic-card-data]).canMakePayment()`
> (or `show()` directly) - passes in Chrome today, fails/throws in Safari.
> 3. If either of #1 or #2 failed, render a fallback payment information
> collection flow such as a HTML form.
>
> TL;DR - we expect very few to no sites to break due to this removal,
> unless they're doing user-agent specific branching with no fallback
> mechanisms for 'what if basic-card fails'.
>
> On Thu, 9 Sept 2021 at 08:03, Yoav Weiss 
> wrote:
>
>> Can you clarify what breakage may look like for sites that may rely
>> on it?
>>
>> On Tuesday, September 7, 2021 at 2:34:46 PM UTC+2 Stephen McGruer
>> wrote:
>>
>>> > Any usecounter stats you can share?
>>>
>>> Unfortunately no usecounters for two reasons:
>>>
>>> 1) Payment APIs in general have very low usage when compared to
>>> 'page loads', because the most popular sites on the web aren't merchants
>>> and so don't use them. For example, PaymentRequest.show is at 0.001
>>> .
>>> They're still very important, so we have to measure usage other ways :)
>>>
>>> 2) In particular for basic-card, it's actually just a method-type of
>>> PaymentRequest, so our top-level usecounters don't show it.
>>>
>>> We have internal stats that I can't share publicly due to
>>> sensitivity (Googlers, feel free to pi

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Rouslan Solomakhin]

Sure, let's do 4 milestones. We can put the deprecation message in the
developer console in M96 and perform the removal in M100.

On Thu, Sep 9, 2021 at 3:26 PM Mike West  wrote:

> Ok. Does ~4-5 milestones (M100-101 sound good to you?)
>
> -mike
>
>
> On Thu, Sep 9, 2021 at 9:20 PM Rouslan Solomakhin 
> wrote:
>
>> > a deprecation period before removal isn't an unreasonable path forward.
>> WDYT
>>
>> That sounds reasonable to us. We are planning a blog post, too, by the
>> way.
>>
>> (Responding on behalf of Stephen and Max because they happen to be both
>> OOO today.)
>>
>> On Thu, Sep 9, 2021 at 2:57 PM Mike West  wrote:
>>
>>> Given the UKM-driven manual analysis, I'm willing to believe that sites
>>> using this mechanism won't crumble if it's removed. That said, the
>>> deprecation in the spec that you pointed to above landed ~2 weeks ago.
>>> Perhaps it's reasonable to extend developers' ability to conduct
>>> transactions through this mechanism for a release or three before removing
>>> it, warning in the console about the deprecation, blog posting, etc.
>>>
>>> Perhaps I'm being unreasonably cautious here (and I'm totally willing to
>>> hear reasons that might be the case!), but it seems to me that a
>>> deprecation period before removal isn't an unreasonable path forward. WDYT?
>>>
>>> -mike
>>>
>>>
>>> On Thu, Sep 9, 2021 at 5:46 PM Daniel Bratell 
>>> wrote:
>>>
 When I looked around to see what other methods were available, it
 seemed to me like all documentation and explainers included basic-card as
 the standard method, and few of them used anything else. I wonder if that
 means that it's too early to deprecate before documentation and specs is
 updated to suggest alternatives.

 /Daniel


 On 2021-09-09 14:14, Stephen Mcgruer wrote:

 > Can you clarify what breakage may look like for sites that may rely
 on it?

 If a site was *entirely* relying on basic-card to collect credit card
 details from their user, it would be impossible for the user to complete
 their checkout. So arguably 'site completely broken' from that perspective
 (assuming buying a thing is the main user journey).

 However, such a site would also be broken on Firefox and Safari today
 (unless serving user-agent specific code), and sites also tend to not rely
 on just one approach to get paid. Sites will almost definitely have a
 fallback mechanism, and it will likely be invisible to the user. For
 example:

 1. Site checks `if (window.PaymentRequest)` - passes in Chrome and
 Safari, fails in Firefox.
 2. Site calls `new PaymentRequest([basic-card-data]).canMakePayment()`
 (or `show()` directly) - passes in Chrome today, fails/throws in Safari.
 3. If either of #1 or #2 failed, render a fallback payment information
 collection flow such as a HTML form.

 TL;DR - we expect very few to no sites to break due to this removal,
 unless they're doing user-agent specific branching with no fallback
 mechanisms for 'what if basic-card fails'.

 On Thu, 9 Sept 2021 at 08:03, Yoav Weiss 
 wrote:

> Can you clarify what breakage may look like for sites that may rely on
> it?
>
> On Tuesday, September 7, 2021 at 2:34:46 PM UTC+2 Stephen McGruer
> wrote:
>
>> > Any usecounter stats you can share?
>>
>> Unfortunately no usecounters for two reasons:
>>
>> 1) Payment APIs in general have very low usage when compared to 'page
>> loads', because the most popular sites on the web aren't merchants and so
>> don't use them. For example, PaymentRequest.show is at 0.001
>> .
>> They're still very important, so we have to measure usage other ways :)
>>
>> 2) In particular for basic-card, it's actually just a method-type of
>> PaymentRequest, so our top-level usecounters don't show it.
>>
>> We have internal stats that I can't share publicly due to sensitivity
>> (Googlers, feel free to ping me for a link), but I can share that of
>> transactions using PaymentRequest, basic-card is ~2% of all transactions
>> and <1% of completed transactions. So it's a very niche feature that also
>> performs poorly.
>>
>> Max has also done an analysis of the top 10 sites from UKM data that
>> use basic-card. For 4, he couldn't get to the payments page or couldn't 
>> get
>> it to trigger basic-card at all (possibly geographically gated), but for
>> the remaining 6 he confirmed that all 6 function properly in a version of
>> Chrome that has basic-card disabled (falling back to the same behavior 
>> they
>> use for Firefox + Safari).
>>
>> On Mon, 6 Sept 2021 at 03:26, Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 3, 2021 at 4:25 PM Liquan (Max) Gu 
>>> wrote:
>>>
 Contact 

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Mike West]

Ok. Does ~4-5 milestones (M100-101 sound good to you?)

-mike


On Thu, Sep 9, 2021 at 9:20 PM Rouslan Solomakhin 
wrote:

> > a deprecation period before removal isn't an unreasonable path forward.
> WDYT
>
> That sounds reasonable to us. We are planning a blog post, too, by the way.
>
> (Responding on behalf of Stephen and Max because they happen to be both
> OOO today.)
>
> On Thu, Sep 9, 2021 at 2:57 PM Mike West  wrote:
>
>> Given the UKM-driven manual analysis, I'm willing to believe that sites
>> using this mechanism won't crumble if it's removed. That said, the
>> deprecation in the spec that you pointed to above landed ~2 weeks ago.
>> Perhaps it's reasonable to extend developers' ability to conduct
>> transactions through this mechanism for a release or three before removing
>> it, warning in the console about the deprecation, blog posting, etc.
>>
>> Perhaps I'm being unreasonably cautious here (and I'm totally willing to
>> hear reasons that might be the case!), but it seems to me that a
>> deprecation period before removal isn't an unreasonable path forward. WDYT?
>>
>> -mike
>>
>>
>> On Thu, Sep 9, 2021 at 5:46 PM Daniel Bratell 
>> wrote:
>>
>>> When I looked around to see what other methods were available, it seemed
>>> to me like all documentation and explainers included basic-card as the
>>> standard method, and few of them used anything else. I wonder if that means
>>> that it's too early to deprecate before documentation and specs is updated
>>> to suggest alternatives.
>>>
>>> /Daniel
>>>
>>>
>>> On 2021-09-09 14:14, Stephen Mcgruer wrote:
>>>
>>> > Can you clarify what breakage may look like for sites that may rely on
>>> it?
>>>
>>> If a site was *entirely* relying on basic-card to collect credit card
>>> details from their user, it would be impossible for the user to complete
>>> their checkout. So arguably 'site completely broken' from that perspective
>>> (assuming buying a thing is the main user journey).
>>>
>>> However, such a site would also be broken on Firefox and Safari today
>>> (unless serving user-agent specific code), and sites also tend to not rely
>>> on just one approach to get paid. Sites will almost definitely have a
>>> fallback mechanism, and it will likely be invisible to the user. For
>>> example:
>>>
>>> 1. Site checks `if (window.PaymentRequest)` - passes in Chrome and
>>> Safari, fails in Firefox.
>>> 2. Site calls `new PaymentRequest([basic-card-data]).canMakePayment()`
>>> (or `show()` directly) - passes in Chrome today, fails/throws in Safari.
>>> 3. If either of #1 or #2 failed, render a fallback payment information
>>> collection flow such as a HTML form.
>>>
>>> TL;DR - we expect very few to no sites to break due to this removal,
>>> unless they're doing user-agent specific branching with no fallback
>>> mechanisms for 'what if basic-card fails'.
>>>
>>> On Thu, 9 Sept 2021 at 08:03, Yoav Weiss  wrote:
>>>
 Can you clarify what breakage may look like for sites that may rely on
 it?

 On Tuesday, September 7, 2021 at 2:34:46 PM UTC+2 Stephen McGruer wrote:

> > Any usecounter stats you can share?
>
> Unfortunately no usecounters for two reasons:
>
> 1) Payment APIs in general have very low usage when compared to 'page
> loads', because the most popular sites on the web aren't merchants and so
> don't use them. For example, PaymentRequest.show is at 0.001
> .
> They're still very important, so we have to measure usage other ways :)
>
> 2) In particular for basic-card, it's actually just a method-type of
> PaymentRequest, so our top-level usecounters don't show it.
>
> We have internal stats that I can't share publicly due to sensitivity
> (Googlers, feel free to ping me for a link), but I can share that of
> transactions using PaymentRequest, basic-card is ~2% of all transactions
> and <1% of completed transactions. So it's a very niche feature that also
> performs poorly.
>
> Max has also done an analysis of the top 10 sites from UKM data that
> use basic-card. For 4, he couldn't get to the payments page or couldn't 
> get
> it to trigger basic-card at all (possibly geographically gated), but for
> the remaining 6 he confirmed that all 6 function properly in a version of
> Chrome that has basic-card disabled (falling back to the same behavior 
> they
> use for Firefox + Safari).
>
> On Mon, 6 Sept 2021 at 03:26, Yoav Weiss 
> wrote:
>
>>
>>
>> On Fri, Sep 3, 2021 at 4:25 PM Liquan (Max) Gu 
>> wrote:
>>
>>> Contact emails ma...@chromium.org, payments-...@chromium.org
>>>
>>> Specification https://www.w3.org/TR/payment-method-basic-card/
>>>
>>> Summary
>>>
>>> Deprecate the "basic-card" payment method from PaymentRequest API.
>>>
>>> Blink component Blink>Payments
>>> 

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Rouslan Solomakhin]

> a deprecation period before removal isn't an unreasonable path forward.
WDYT

That sounds reasonable to us. We are planning a blog post, too, by the way.

(Responding on behalf of Stephen and Max because they happen to be both OOO
today.)

On Thu, Sep 9, 2021 at 2:57 PM Mike West  wrote:

> Given the UKM-driven manual analysis, I'm willing to believe that sites
> using this mechanism won't crumble if it's removed. That said, the
> deprecation in the spec that you pointed to above landed ~2 weeks ago.
> Perhaps it's reasonable to extend developers' ability to conduct
> transactions through this mechanism for a release or three before removing
> it, warning in the console about the deprecation, blog posting, etc.
>
> Perhaps I'm being unreasonably cautious here (and I'm totally willing to
> hear reasons that might be the case!), but it seems to me that a
> deprecation period before removal isn't an unreasonable path forward. WDYT?
>
> -mike
>
>
> On Thu, Sep 9, 2021 at 5:46 PM Daniel Bratell  wrote:
>
>> When I looked around to see what other methods were available, it seemed
>> to me like all documentation and explainers included basic-card as the
>> standard method, and few of them used anything else. I wonder if that means
>> that it's too early to deprecate before documentation and specs is updated
>> to suggest alternatives.
>>
>> /Daniel
>>
>>
>> On 2021-09-09 14:14, Stephen Mcgruer wrote:
>>
>> > Can you clarify what breakage may look like for sites that may rely on
>> it?
>>
>> If a site was *entirely* relying on basic-card to collect credit card
>> details from their user, it would be impossible for the user to complete
>> their checkout. So arguably 'site completely broken' from that perspective
>> (assuming buying a thing is the main user journey).
>>
>> However, such a site would also be broken on Firefox and Safari today
>> (unless serving user-agent specific code), and sites also tend to not rely
>> on just one approach to get paid. Sites will almost definitely have a
>> fallback mechanism, and it will likely be invisible to the user. For
>> example:
>>
>> 1. Site checks `if (window.PaymentRequest)` - passes in Chrome and
>> Safari, fails in Firefox.
>> 2. Site calls `new PaymentRequest([basic-card-data]).canMakePayment()`
>> (or `show()` directly) - passes in Chrome today, fails/throws in Safari.
>> 3. If either of #1 or #2 failed, render a fallback payment information
>> collection flow such as a HTML form.
>>
>> TL;DR - we expect very few to no sites to break due to this removal,
>> unless they're doing user-agent specific branching with no fallback
>> mechanisms for 'what if basic-card fails'.
>>
>> On Thu, 9 Sept 2021 at 08:03, Yoav Weiss  wrote:
>>
>>> Can you clarify what breakage may look like for sites that may rely on
>>> it?
>>>
>>> On Tuesday, September 7, 2021 at 2:34:46 PM UTC+2 Stephen McGruer wrote:
>>>
 > Any usecounter stats you can share?

 Unfortunately no usecounters for two reasons:

 1) Payment APIs in general have very low usage when compared to 'page
 loads', because the most popular sites on the web aren't merchants and so
 don't use them. For example, PaymentRequest.show is at 0.001
 .
 They're still very important, so we have to measure usage other ways :)

 2) In particular for basic-card, it's actually just a method-type of
 PaymentRequest, so our top-level usecounters don't show it.

 We have internal stats that I can't share publicly due to sensitivity
 (Googlers, feel free to ping me for a link), but I can share that of
 transactions using PaymentRequest, basic-card is ~2% of all transactions
 and <1% of completed transactions. So it's a very niche feature that also
 performs poorly.

 Max has also done an analysis of the top 10 sites from UKM data that
 use basic-card. For 4, he couldn't get to the payments page or couldn't get
 it to trigger basic-card at all (possibly geographically gated), but for
 the remaining 6 he confirmed that all 6 function properly in a version of
 Chrome that has basic-card disabled (falling back to the same behavior they
 use for Firefox + Safari).

 On Mon, 6 Sept 2021 at 03:26, Yoav Weiss 
 wrote:

>
>
> On Fri, Sep 3, 2021 at 4:25 PM Liquan (Max) Gu 
> wrote:
>
>> Contact emails ma...@chromium.org, payments-...@chromium.org
>>
>> Specification https://www.w3.org/TR/payment-method-basic-card/
>>
>> Summary
>>
>> Deprecate the "basic-card" payment method from PaymentRequest API.
>>
>> Blink component Blink>Payments
>> 
>>
>> Motivation
>>
>> * Its usage is low and declining, underperforms other payment methods
>> in time-to-checkout and completion rate and does not have improvement
>> poten

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Mike West]

Given the UKM-driven manual analysis, I'm willing to believe that sites
using this mechanism won't crumble if it's removed. That said, the
deprecation in the spec that you pointed to above landed ~2 weeks ago.
Perhaps it's reasonable to extend developers' ability to conduct
transactions through this mechanism for a release or three before removing
it, warning in the console about the deprecation, blog posting, etc.

Perhaps I'm being unreasonably cautious here (and I'm totally willing to
hear reasons that might be the case!), but it seems to me that a
deprecation period before removal isn't an unreasonable path forward. WDYT?

-mike


On Thu, Sep 9, 2021 at 5:46 PM Daniel Bratell  wrote:

> When I looked around to see what other methods were available, it seemed
> to me like all documentation and explainers included basic-card as the
> standard method, and few of them used anything else. I wonder if that means
> that it's too early to deprecate before documentation and specs is updated
> to suggest alternatives.
>
> /Daniel
>
>
> On 2021-09-09 14:14, Stephen Mcgruer wrote:
>
> > Can you clarify what breakage may look like for sites that may rely on
> it?
>
> If a site was *entirely* relying on basic-card to collect credit card
> details from their user, it would be impossible for the user to complete
> their checkout. So arguably 'site completely broken' from that perspective
> (assuming buying a thing is the main user journey).
>
> However, such a site would also be broken on Firefox and Safari today
> (unless serving user-agent specific code), and sites also tend to not rely
> on just one approach to get paid. Sites will almost definitely have a
> fallback mechanism, and it will likely be invisible to the user. For
> example:
>
> 1. Site checks `if (window.PaymentRequest)` - passes in Chrome and Safari,
> fails in Firefox.
> 2. Site calls `new PaymentRequest([basic-card-data]).canMakePayment()` (or
> `show()` directly) - passes in Chrome today, fails/throws in Safari.
> 3. If either of #1 or #2 failed, render a fallback payment information
> collection flow such as a HTML form.
>
> TL;DR - we expect very few to no sites to break due to this removal,
> unless they're doing user-agent specific branching with no fallback
> mechanisms for 'what if basic-card fails'.
>
> On Thu, 9 Sept 2021 at 08:03, Yoav Weiss  wrote:
>
>> Can you clarify what breakage may look like for sites that may rely on it?
>>
>> On Tuesday, September 7, 2021 at 2:34:46 PM UTC+2 Stephen McGruer wrote:
>>
>>> > Any usecounter stats you can share?
>>>
>>> Unfortunately no usecounters for two reasons:
>>>
>>> 1) Payment APIs in general have very low usage when compared to 'page
>>> loads', because the most popular sites on the web aren't merchants and so
>>> don't use them. For example, PaymentRequest.show is at 0.001
>>> .
>>> They're still very important, so we have to measure usage other ways :)
>>>
>>> 2) In particular for basic-card, it's actually just a method-type of
>>> PaymentRequest, so our top-level usecounters don't show it.
>>>
>>> We have internal stats that I can't share publicly due to sensitivity
>>> (Googlers, feel free to ping me for a link), but I can share that of
>>> transactions using PaymentRequest, basic-card is ~2% of all transactions
>>> and <1% of completed transactions. So it's a very niche feature that also
>>> performs poorly.
>>>
>>> Max has also done an analysis of the top 10 sites from UKM data that use
>>> basic-card. For 4, he couldn't get to the payments page or couldn't get it
>>> to trigger basic-card at all (possibly geographically gated), but for the
>>> remaining 6 he confirmed that all 6 function properly in a version of
>>> Chrome that has basic-card disabled (falling back to the same behavior they
>>> use for Firefox + Safari).
>>>
>>> On Mon, 6 Sept 2021 at 03:26, Yoav Weiss  wrote:
>>>


 On Fri, Sep 3, 2021 at 4:25 PM Liquan (Max) Gu 
 wrote:

> Contact emails ma...@chromium.org, payments-...@chromium.org
>
> Specification https://www.w3.org/TR/payment-method-basic-card/
>
> Summary
>
> Deprecate the "basic-card" payment method from PaymentRequest API.
>
> Blink component Blink>Payments
> 
>
> Motivation
>
> * Its usage is low and declining, underperforms other payment methods
> in time-to-checkout and completion rate and does not have improvement
> potential.
>

 Any usecounter stats you can share?

> * W3C's interest in it has waned. 6 participants supported the
> deprecation and no objection[1], and W3C has deprecated the spec[2]. [1]
> https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0038.html
> [2] https://github.com/w3c/payment-method-basic-card/pull/90/files
>
> Interoperability and Compatibility
> * 

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Daniel Bratell]

When I looked around to see what other methods were available, it seemed 
to me like all documentation and explainers included basic-card as the 
standard method, and few of them used anything else. I wonder if that 
means that it's too early to deprecate before documentation and specs is 
updated to suggest alternatives.


/Daniel


On 2021-09-09 14:14, Stephen Mcgruer wrote:
> Can you clarify what breakage may look like for sites that may rely 
on it?


If a site was *entirely* relying on basic-card to collect credit card 
details from their user, it would be impossible for the user to 
complete their checkout. So arguably 'site completely broken' from 
that perspective (assuming buying a thing is the main user journey).


However, such a site would also be broken on Firefox and Safari today 
(unless serving user-agent specific code), and sites also tend to not 
rely on just one approach to get paid. Sites will almost definitely 
have a fallback mechanism, and it will likely be invisible to the 
user. For example:


1. Site checks `if (window.PaymentRequest)` - passes in Chrome and 
Safari, fails in Firefox.
2. Site calls `new PaymentRequest([basic-card-data]).canMakePayment()` 
(or `show()` directly) - passes in Chrome today, fails/throws in Safari.
3. If either of #1 or #2 failed, render a fallback payment information 
collection flow such as a HTML form.


TL;DR - we expect very few to no sites to break due to this removal, 
unless they're doing user-agent specific branching with no fallback 
mechanisms for 'what if basic-card fails'.


On Thu, 9 Sept 2021 at 08:03, Yoav Weiss > wrote:


Can you clarify what breakage may look like for sites that may
rely on it?

On Tuesday, September 7, 2021 at 2:34:46 PM UTC+2 Stephen McGruer
wrote:

> Any usecounter stats you can share?

Unfortunately no usecounters for two reasons:

1) Payment APIs in general have very low usage when compared
to 'page loads', because the most popular sites on the web
aren't merchants and so don't use them. For example,
PaymentRequest.show is at 0.001
.
They're still very important, so we have to measure usage
other ways :)

2) In particular for basic-card, it's actually just a
method-type of PaymentRequest, so our top-level usecounters
don't show it.

We have internal stats that I can't share publicly due to
sensitivity (Googlers, feel free to ping me for a link), but I
can share that of transactions using PaymentRequest,
basic-card is ~2% of all transactions and <1% of completed
transactions. So it's a very niche feature that also performs
poorly.

Max has also done an analysis of the top 10 sites from UKM
data that use basic-card. For 4, he couldn't get to the
payments page or couldn't get it to trigger basic-card at all
(possibly geographically gated), but for the remaining 6 he
confirmed that all 6 function properly in a version of Chrome
that has basic-card disabled (falling back to the same
behavior they use for Firefox + Safari).

On Mon, 6 Sept 2021 at 03:26, Yoav Weiss
mailto:yoavwe...@chromium.org>> wrote:



On Fri, Sep 3, 2021 at 4:25 PM Liquan (Max) Gu
mailto:ma...@chromium.org>> wrote:


Contact emails

ma...@chromium.org ,
payments-...@chromium.org



Specification

https://www.w3.org/TR/payment-method-basic-card/



Summary

Deprecate the "basic-card" payment method from
PaymentRequest API.


Blink component

Blink>Payments




Motivation

* Its usage is low and declining, underperforms other
payment methods in time-to-checkout and completion
rate and does not have improvement potential.


Any usecounter stats you can share?

* W3C's interest in it has waned. 6 participants
supported the deprecation and no objection[1], and W3C
has deprecated the spec[2]. [1]

https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0038.html


[2]
https://github.com/w3c/payment-method-basic-card/pull/90/files

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Stephen Mcgruer]

> Can you clarify what breakage may look like for sites that may rely on it?

If a site was *entirely* relying on basic-card to collect credit card
details from their user, it would be impossible for the user to complete
their checkout. So arguably 'site completely broken' from that perspective
(assuming buying a thing is the main user journey).

However, such a site would also be broken on Firefox and Safari today
(unless serving user-agent specific code), and sites also tend to not rely
on just one approach to get paid. Sites will almost definitely have a
fallback mechanism, and it will likely be invisible to the user. For
example:

1. Site checks `if (window.PaymentRequest)` - passes in Chrome and Safari,
fails in Firefox.
2. Site calls `new PaymentRequest([basic-card-data]).canMakePayment()` (or
`show()` directly) - passes in Chrome today, fails/throws in Safari.
3. If either of #1 or #2 failed, render a fallback payment information
collection flow such as a HTML form.

TL;DR - we expect very few to no sites to break due to this removal, unless
they're doing user-agent specific branching with no fallback mechanisms for
'what if basic-card fails'.

On Thu, 9 Sept 2021 at 08:03, Yoav Weiss  wrote:

> Can you clarify what breakage may look like for sites that may rely on it?
>
> On Tuesday, September 7, 2021 at 2:34:46 PM UTC+2 Stephen McGruer wrote:
>
>> > Any usecounter stats you can share?
>>
>> Unfortunately no usecounters for two reasons:
>>
>> 1) Payment APIs in general have very low usage when compared to 'page
>> loads', because the most popular sites on the web aren't merchants and so
>> don't use them. For example, PaymentRequest.show is at 0.001
>> .
>> They're still very important, so we have to measure usage other ways :)
>>
>> 2) In particular for basic-card, it's actually just a method-type of
>> PaymentRequest, so our top-level usecounters don't show it.
>>
>> We have internal stats that I can't share publicly due to sensitivity
>> (Googlers, feel free to ping me for a link), but I can share that of
>> transactions using PaymentRequest, basic-card is ~2% of all transactions
>> and <1% of completed transactions. So it's a very niche feature that also
>> performs poorly.
>>
>> Max has also done an analysis of the top 10 sites from UKM data that use
>> basic-card. For 4, he couldn't get to the payments page or couldn't get it
>> to trigger basic-card at all (possibly geographically gated), but for the
>> remaining 6 he confirmed that all 6 function properly in a version of
>> Chrome that has basic-card disabled (falling back to the same behavior they
>> use for Firefox + Safari).
>>
>> On Mon, 6 Sept 2021 at 03:26, Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Fri, Sep 3, 2021 at 4:25 PM Liquan (Max) Gu 
>>> wrote:
>>>
 Contact emailsma...@chromium.org, payments-...@chromium.org

 Specificationhttps://www.w3.org/TR/payment-method-basic-card/

 Summary

 Deprecate the "basic-card" payment method from PaymentRequest API.

 Blink componentBlink>Payments
 

 Motivation

 * Its usage is low and declining, underperforms other payment methods
 in time-to-checkout and completion rate and does not have improvement
 potential.

>>>
>>> Any usecounter stats you can share?
>>>
 * W3C's interest in it has waned. 6 participants supported the
 deprecation and no objection[1], and W3C has deprecated the spec[2]. [1]
 https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0038.html
 [2] https://github.com/w3c/payment-method-basic-card/pull/90/files


 Interoperability and Compatibility
 * Chrome is the only implementer of basic-card, so the basic-card
 removal from Chrome will increase interoperability.
 * Since no other browser implements basic-card, web developers already
 need workarounds to support other browsers.
 * Whether basic-card is supported can be detected via canMakePayment
 . Web
 developers normally use this to decide whether to fallback to other 
 methods.
 * We have checked the few top sites via UKM - they all appear to work
 with basic-card disabled because they fallback to other methods to get
 payment info.

 Tracking bughttps://crbug.com/1209835

 Estimated milestonesM96

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

 This intent message was generated by Chrome Platform Status
 .

 --
 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+unsubscr...@chromium.org.
 To

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Yoav Weiss]

Can you clarify what breakage may look like for sites that may rely on it?

On Tuesday, September 7, 2021 at 2:34:46 PM UTC+2 Stephen McGruer wrote:

> > Any usecounter stats you can share?
>
> Unfortunately no usecounters for two reasons:
>
> 1) Payment APIs in general have very low usage when compared to 'page 
> loads', because the most popular sites on the web aren't merchants and so 
> don't use them. For example, PaymentRequest.show is at 0.001 
> . 
> They're still very important, so we have to measure usage other ways :)
>
> 2) In particular for basic-card, it's actually just a method-type of 
> PaymentRequest, so our top-level usecounters don't show it.
>
> We have internal stats that I can't share publicly due to sensitivity 
> (Googlers, feel free to ping me for a link), but I can share that of 
> transactions using PaymentRequest, basic-card is ~2% of all transactions 
> and <1% of completed transactions. So it's a very niche feature that also 
> performs poorly.
>
> Max has also done an analysis of the top 10 sites from UKM data that use 
> basic-card. For 4, he couldn't get to the payments page or couldn't get it 
> to trigger basic-card at all (possibly geographically gated), but for the 
> remaining 6 he confirmed that all 6 function properly in a version of 
> Chrome that has basic-card disabled (falling back to the same behavior they 
> use for Firefox + Safari). 
>
> On Mon, 6 Sept 2021 at 03:26, Yoav Weiss  wrote:
>
>>
>>
>> On Fri, Sep 3, 2021 at 4:25 PM Liquan (Max) Gu  
>> wrote:
>>
>>> Contact emailsma...@chromium.org, payments-...@chromium.org
>>>
>>> Specificationhttps://www.w3.org/TR/payment-method-basic-card/
>>>
>>> Summary
>>>
>>> Deprecate the "basic-card" payment method from PaymentRequest API.
>>>
>>> Blink componentBlink>Payments 
>>> 
>>>
>>> Motivation
>>>
>>> * Its usage is low and declining, underperforms other payment methods in 
>>> time-to-checkout and completion rate and does not have improvement 
>>> potential.
>>>
>>
>> Any usecounter stats you can share? 
>>
>>> * W3C's interest in it has waned. 6 participants supported the 
>>> deprecation and no objection[1], and W3C has deprecated the spec[2]. [1] 
>>> https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0038.html 
>>> [2] https://github.com/w3c/payment-method-basic-card/pull/90/files
>>>
>>>
>>> Interoperability and Compatibility
>>> * Chrome is the only implementer of basic-card, so the basic-card 
>>> removal from Chrome will increase interoperability.
>>> * Since no other browser implements basic-card, web developers already 
>>> need workarounds to support other browsers.
>>> * Whether basic-card is supported can be detected via canMakePayment 
>>> . Web 
>>> developers normally use this to decide whether to fallback to other methods.
>>> * We have checked the few top sites via UKM - they all appear to work 
>>> with basic-card disabled because they fallback to other methods to get 
>>> payment info.
>>>
>>> Tracking bughttps://crbug.com/1209835
>>>
>>> Estimated milestonesM96
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/573005107056
>>>
>>> This intent message was generated by Chrome Platform Status 
>>> .
>>>
>>> -- 
>>> 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+unsubscr...@chromium.org.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEWPi2sswphwqEnCGgwwNOr_F5j8V%3Dc5ZQ7Kz6h2gK%2Bki2A6aw%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>> -- 
>>
> You received this message because you are subscribed to the Google Groups 
>> "payments-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to payments-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/payments-dev/CAL5BFfUaHsXJEEwN3JO2MSGw9WHsVt5nszPPscKh9mBrRt5U1g%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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Stephen Mcgruer]

> Any usecounter stats you can share?

Unfortunately no usecounters for two reasons:

1) Payment APIs in general have very low usage when compared to 'page
loads', because the most popular sites on the web aren't merchants and so
don't use them. For example, PaymentRequest.show is at 0.001
.
They're still very important, so we have to measure usage other ways :)

2) In particular for basic-card, it's actually just a method-type of
PaymentRequest, so our top-level usecounters don't show it.

We have internal stats that I can't share publicly due to sensitivity
(Googlers, feel free to ping me for a link), but I can share that of
transactions using PaymentRequest, basic-card is ~2% of all transactions
and <1% of completed transactions. So it's a very niche feature that also
performs poorly.

Max has also done an analysis of the top 10 sites from UKM data that use
basic-card. For 4, he couldn't get to the payments page or couldn't get it
to trigger basic-card at all (possibly geographically gated), but for the
remaining 6 he confirmed that all 6 function properly in a version of
Chrome that has basic-card disabled (falling back to the same behavior they
use for Firefox + Safari).

On Mon, 6 Sept 2021 at 03:26, Yoav Weiss  wrote:

>
>
> On Fri, Sep 3, 2021 at 4:25 PM Liquan (Max) Gu  wrote:
>
>> Contact emailsma...@chromium.org, payments-...@chromium.org
>>
>> Specificationhttps://www.w3.org/TR/payment-method-basic-card/
>>
>> Summary
>>
>> Deprecate the "basic-card" payment method from PaymentRequest API.
>>
>> Blink componentBlink>Payments
>> 
>>
>> Motivation
>>
>> * Its usage is low and declining, underperforms other payment methods in
>> time-to-checkout and completion rate and does not have improvement
>> potential.
>>
>
> Any usecounter stats you can share?
>
>> * W3C's interest in it has waned. 6 participants supported the
>> deprecation and no objection[1], and W3C has deprecated the spec[2]. [1]
>> https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0038.html
>> [2] https://github.com/w3c/payment-method-basic-card/pull/90/files
>>
>>
>> Interoperability and Compatibility
>> * Chrome is the only implementer of basic-card, so the basic-card removal
>> from Chrome will increase interoperability.
>> * Since no other browser implements basic-card, web developers already
>> need workarounds to support other browsers.
>> * Whether basic-card is supported can be detected via canMakePayment
>> . Web
>> developers normally use this to decide whether to fallback to other methods.
>> * We have checked the few top sites via UKM - they all appear to work
>> with basic-card disabled because they fallback to other methods to get
>> payment info.
>>
>> Tracking bughttps://crbug.com/1209835
>>
>> Estimated milestonesM96
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/573005107056
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> 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+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEWPi2sswphwqEnCGgwwNOr_F5j8V%3Dc5ZQ7Kz6h2gK%2Bki2A6aw%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "payments-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to payments-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/payments-dev/CAL5BFfUaHsXJEEwN3JO2MSGw9WHsVt5nszPPscKh9mBrRt5U1g%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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Mac986%2BtzwvcQfnmxBe%2BU8bgiJ%3DmW-NjptpgLZTdLYqH0A%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Yoav Weiss]

On Fri, Sep 3, 2021 at 4:25 PM Liquan (Max) Gu  wrote:

> Contact emailsma...@chromium.org, payments-...@chromium.org
>
> Specificationhttps://www.w3.org/TR/payment-method-basic-card/
>
> Summary
>
> Deprecate the "basic-card" payment method from PaymentRequest API.
>
> Blink componentBlink>Payments
> 
>
> Motivation
>
> * Its usage is low and declining, underperforms other payment methods in
> time-to-checkout and completion rate and does not have improvement
> potential.
>

Any usecounter stats you can share?

> * W3C's interest in it has waned. 6 participants supported the deprecation
> and no objection[1], and W3C has deprecated the spec[2]. [1]
> https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0038.html
> [2] https://github.com/w3c/payment-method-basic-card/pull/90/files
>
>
> Interoperability and Compatibility
> * Chrome is the only implementer of basic-card, so the basic-card removal
> from Chrome will increase interoperability.
> * Since no other browser implements basic-card, web developers already
> need workarounds to support other browsers.
> * Whether basic-card is supported can be detected via canMakePayment
> . Web
> developers normally use this to decide whether to fallback to other methods.
> * We have checked the few top sites via UKM - they all appear to work
> with basic-card disabled because they fallback to other methods to get
> payment info.
>
> Tracking bughttps://crbug.com/1209835
>
> Estimated milestonesM96
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/573005107056
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> 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+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEWPi2sswphwqEnCGgwwNOr_F5j8V%3Dc5ZQ7Kz6h2gK%2Bki2A6aw%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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUaHsXJEEwN3JO2MSGw9WHsVt5nszPPscKh9mBrRt5U1g%40mail.gmail.com.

[blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Liquan (Max) Gu]

Contact emailsma...@chromium.org, payments-...@chromium.org

Specificationhttps://www.w3.org/TR/payment-method-basic-card/

Summary

Deprecate the "basic-card" payment method from PaymentRequest API.

Blink componentBlink>Payments


Motivation

* Its usage is low and declining, underperforms other payment methods in
time-to-checkout and completion rate and does not have improvement
potential. * W3C's interest in it has waned. 6 participants supported the
deprecation and no objection[1], and W3C has deprecated the spec[2]. [1]
https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0038.html
[2] https://github.com/w3c/payment-method-basic-card/pull/90/files


Interoperability and Compatibility
* Chrome is the only implementer of basic-card, so the basic-card removal
from Chrome will increase interoperability.
* Since no other browser implements basic-card, web developers already need
workarounds to support other browsers.
* Whether basic-card is supported can be detected via canMakePayment
. Web
developers normally use this to decide whether to fallback to other methods.
* We have checked the few top sites via UKM - they all appear to work with
basic-card disabled because they fallback to other methods to get payment
info.

Tracking bughttps://crbug.com/1209835

Estimated milestonesM96

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

This intent message was generated by Chrome Platform Status
.

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEWPi2sswphwqEnCGgwwNOr_F5j8V%3Dc5ZQ7Kz6h2gK%2Bki2A6aw%40mail.gmail.com.