- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 7 Nov 2018 11:54:54 -0600
- To: Payments WG <public-payments-wg@w3.org>
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
Received on Wednesday, 7 November 2018 17:55:00 UTC