Re: SEEKING INPUT: Priority of adding hasEnrolledInstrument method to Payment Request API in version 1

Stripe’s preference is #1.

On Wed, Nov 7, 2018 at 6:55 PM Ian Jacobs <ij@w3.org> wrote:

> Dear participants in the Web Payments Working Group,
>
> During TPAC we discussed the need to harmonize the implementation of
> canMakePayment(); browser makers have begun to align their implementations.
>
> During the discussion, there also seemed to be consensus that a second
> method (tentatively named “hasEnrolledInstrument” should be added to
> Payment Request API. The definitions would be
> something like:
>
>  * canMakePayment: will return true for a given payment identifier when
> support for the payment method is available, either because the user has a
> registered payment handler for that payment method or because the browser
> can do just-in-time registration of a suitable payment handler.
>  * hasEnrolledInstrument: will return true for a given payment identifier
> when support for the payment method is available and “ready for payment”
> (e.g., when showing a “buy now” button).
>
> Adding a feature at this stage would likely delay the competition of the
> Recommendation by several months until we have 2 interoperable
> implementations.
>
> Please let us know (ideally by the 15 November call) your view by
> responding to this email on the mailing list and choosing one of the
> following:
>
> 1. I would like the editors to specify the hasEnrolledInstrument method
> and implement it before Payment Request API v1 advances to Recommendation.
> 2. I would like the editors to specify the hasEnrolledInstrument method
> but prefer that it not be a normative part of Payment Request API v1
> 3. Please do not specify hasEnrolledInstrument at this time
> 4. Other (please specify)
>
> Thank you!
>
> Ian
>
> [1] https://www.w3.org/2018/10/22-wpwg-minutes#item15
>
> --
> Ian Jacobs <ij@w3.org>
> https://www.w3.org/People/Jacobs/
> Tel: +1 718 260 9447
>
>
>
>
>
>