I'll be working on it.

On Wed, Sep 29, 2021 at 2:48 PM Yoav Weiss <[email protected]> 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 <[email protected]> wrote:
>
>> Yoav, MDN (PR
>> <https://github.com/mdn/content/issues/9211#event-5375278399>) and
>> web.dev (PR <https://github.com/GoogleChrome/web.dev/pull/6203>) 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 <[email protected]>
>> 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 <https://github.com/mdn/content/issues/8828> with @Joe
>>>> Medley on updating the MDN documentation.
>>>>
>>>> On Tue, Sep 21, 2021 at 2:32 AM Yoav Weiss <[email protected]>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 20, 2021 at 9:16 PM Liquan (Max) Gu <[email protected]>
>>>>> 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
>>>>>>       <https://github.com/GoogleChrome/web.dev/pull/6203> (preview
>>>>>>       
>>>>>> <https://deploy-preview-6203--web-dev-staging.netlify.app/payments/>
>>>>>>       ).
>>>>>>    - whatwebcando <https://whatwebcando.today/payments.html>
>>>>>>       - Rouslan has requested Adam to remove it. No response yet.
>>>>>>    - MDN
>>>>>>    <https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API>
>>>>>>    :
>>>>>>       - 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
>>>>>>    
>>>>>> <https://www.adyen.com/blog/online-payments-using-the-new-web-payment-apis>
>>>>>>    :
>>>>>>       - They are reaching out to the owner to update the article, or
>>>>>>       will connect Rouslan Solomakhin with the article author. (meeting
>>>>>>       note
>>>>>>       
>>>>>> <https://docs.google.com/document/d/1dzyDl13yd56LVhfB-0UxbKloozrbU4GfO4iFtJojRwc/edit#bookmark=id.j7w36xuou4qe>
>>>>>>       ).
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Sep 20, 2021 at 3:06 PM Yoav Weiss <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks! Any word on PRs to MDN and other existing documentation?
>>>>>>>
>>>>>>> On Mon, Sep 20, 2021 at 8:48 PM Liquan (Max) Gu <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi folks,
>>>>>>>>
>>>>>>>> Thanks for your patience. We ended up adding the timeline and
>>>>>>>> alternatives to
>>>>>>>> https://www.chromestatus.com/feature/5730051011117056. 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
>>>>>>>> <https://developers.google.com/web/updates/2018/09/reportingapi>,
>>>>>>>> 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 <[email protected]>
>>>>>>>> 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 <
>>>>>>>>> [email protected]> 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 <[email protected]>
>>>>>>>>>> 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 <
>>>>>>>>>>> [email protected]> 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 <[email protected]>
>>>>>>>>>>>> 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
>>>>>>>>>>>>> <https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API>,
>>>>>>>>>>>>> WebFundementals
>>>>>>>>>>>>> <https://developers.google.com/web/fundamentals/payments/merchant-guide/deep-dive-into-payment-request>,
>>>>>>>>>>>>> Whatwebcando <https://whatwebcando.today/payments.html> ,
>>>>>>>>>>>>> ayden.com
>>>>>>>>>>>>> <https://www.adyen.com/blog/online-payments-using-the-new-web-payment-apis>
>>>>>>>>>>>>>  and samsung
>>>>>>>>>>>>> <https://developer.samsung.com/internet/android/web-payments-integration-guide.html>.
>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>> [email protected]> 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 <[email protected]>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ok. Does ~4-5 milestones (M100-101 sound good to you?)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -mike
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Sep 9, 2021 at 9:20 PM Rouslan Solomakhin <
>>>>>>>>>>>>>>> [email protected]> 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 <
>>>>>>>>>>>>>>>> [email protected]> 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 <
>>>>>>>>>>>>>>>>> [email protected]> 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 <
>>>>>>>>>>>>>>>>>> [email protected]> 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
>>>>>>>>>>>>>>>>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/2895>.
>>>>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Fri, Sep 3, 2021 at 4:25 PM Liquan (Max) Gu <
>>>>>>>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Contact emails [email protected],
>>>>>>>>>>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Specification
>>>>>>>>>>>>>>>>>>>>>> https://www.w3.org/TR/payment-method-basic-card/
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Summary
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Deprecate the "basic-card" payment method from
>>>>>>>>>>>>>>>>>>>>>> PaymentRequest API.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Blink component Blink>Payments
>>>>>>>>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>> <https://w3c.github.io/payment-request/#canmakepayment-method>.
>>>>>>>>>>>>>>>>>>>>>> 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 bug https://crbug.com/1209835
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Estimated milestones M96
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>>>>>>>>>>>>>>>> https://chromestatus.com/feature/5730051011117056
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> This intent message was generated by Chrome Platform
>>>>>>>>>>>>>>>>>>>>>> Status <https://www.chromestatus.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
>>>>>>>>>>>>>>>>>>>>>> [email protected].
>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEWPi2sswphwqEnCGgwwNOr_F5j8V%3Dc5ZQ7Kz6h2gK%2Bki2A6aw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>> [email protected].
>>>>>>>>>>>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/payments-dev/CAL5BFfUaHsXJEEwN3JO2MSGw9WHsVt5nszPPscKh9mBrRt5U1g%40mail.gmail.com
>>>>>>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/payments-dev/CAL5BFfUaHsXJEEwN3JO2MSGw9WHsVt5nszPPscKh9mBrRt5U1g%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> 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 [email protected].
>>>>>>>>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MafMcTV1GOHS62bHd%2BK%2BH1ftH0pBZL_1k77GWJqK8o9Uvg%40mail.gmail.com
>>>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MafMcTV1GOHS62bHd%2BK%2BH1ftH0pBZL_1k77GWJqK8o9Uvg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> 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 [email protected].
>>>>>>>>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25df3c17-3cf3-695a-451f-ef1007581d53%40gmail.com
>>>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25df3c17-3cf3-695a-451f-ef1007581d53%40gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> 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 [email protected].
>>>>>>>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/payments-dev/CAKXHy%3De-AdXxo8CtZrSk-iPN05KmJ0_FWHOw5duyBXFGR58oGA%40mail.gmail.com
>>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/payments-dev/CAKXHy%3De-AdXxo8CtZrSk-iPN05KmJ0_FWHOw5duyBXFGR58oGA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>

-- 
Eiji Kitamura : [email protected]
Google - Developer Advocate

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOW%3Dx-AV9cWYQtQy_bfDZkLXgq6aWnO31H1mm5EAC%2Ba3skZE_g%40mail.gmail.com.

Reply via email to