- From: Frank Hoffmann <frank.hoffmann@klarna.com>
- Date: Thu, 15 Nov 2018 15:43:58 +0100
- To: Payments WG <public-payments-wg@w3.org>
- Cc: Ian Jacobs <ij@w3.org>
- Message-ID: <CAHeu915gUW0tORTWTtWOoiPxifO6r8zDq8MU+=hD42-qn76h_Q@mail.gmail.com>
Option #2 /frank On Fri, Nov 9, 2018 at 12:19 AM Zouhir Chahoud <Zouhir.Chahoud@microsoft.com> wrote: > Option #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. > > -----Original Message----- > From: Ian Jacobs <ij@w3.org> > Sent: Wednesday, November 7, 2018 9:55 AM > To: Payments WG <public-payments-wg@w3.org> > Subject: SEEKING INPUT: Priority of adding hasEnrolledInstrument method to > Payment Request API in version 1 > > 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2018%2F10%2F22-wpwg-minutes%23item15&data=02%7C01%7Czouhir.chahoud%40microsoft.com%7Cca8980b164d74fc0a05808d644da3abf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772101415409205&sdata=dO5Q42TowXkhTM2g0%2BQF9g%2FS2cR7RPQPHF5v9yVrkk8%3D&reserved=0 > > -- > Ian Jacobs <ij@w3.org> > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FPeople%2FJacobs%2F&data=02%7C01%7Czouhir.chahoud%40microsoft.com%7Cca8980b164d74fc0a05808d644da3abf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772101415409205&sdata=rNpQzfyqXINSR13T1IN8zDycBQD984WUovouIMbsdiE%3D&reserved=0 > Tel: +1 718 260 9447 <(718)%20260-9447> > > > > > >
Received on Thursday, 15 November 2018 14:44:37 UTC