Web Payments WG

04 February 2021


Anne Pouillard (Worldline), Chris Dee (FIS), Chris Wood, Clinton Allen (American Express), David Benoit, Fawad Nisar (Discover), Gavin Shenker (Visa), Gerhard Oosthuizen (Entersekt), Ian Jacobs (W3C), John Bradley (Yubico), John Fontana (Yubico), Vaishali Bulusu (American Express), Lawrence Cheng (Barclays), Nick Telford-Reed, Rolf Lindemann (NokNok Labs)
Adrian Hope-Bailie
Ian, nicktr

Meeting minutes

Payment Request API Update

ian: we concluded our CFC for moving Payment Request
… there was support from the group but there were two objections from non-members
… so the next step is to prepare the transition request
… but we also got feedback on some privacy issues and we have added some text which will be included in subsequent CFCs
… and we got further feedback on the incremental address request mechanism
… usage data suggests that it isn't really used (this is centred around shipping address)

ian: so that's a question from the group - how important are the address features of PR?

Gerhard: From an issuer perspective, we've heard very little interest from banks to manage shipping addresses.

<nicktr> ian: I18n group reached out and have offered a new review

david: For shipping address, I found it valuable to be able to get a verified address from a payment app (e.g., PayPal)
… that helped in fraud analysis
… I do understand the privacy considerations
… I don't think that incremental requesting for address will be useful
… as a merchant you know in advance whether you need the full address
… you will know from the cart contents whether you need to ship something
… the user will need to provide payment and a shipping address. As a merchant you know that a shipping address will be required.
… the complexity has everything to do with the shipping address and the total (taxes, duties, shipping costs, etc.)
… as much as it would be valuable for the merchant to receive verified address, I see the appeal of not complicating the API with that back and forth.

ChrisDee: I would agree with that as well. If browsers want to provide shipping address functionality, that could be handled as a separate API.

Ian: I expect to get more information from browser vendors on options here.

Multiday Meeting

Draft agenda of multiday meeting.

NickTR: We've heard from EMVCo and FIDO that they have no conflicts on those dates
… does anyone else here know of conflicts? The merchant bg may also incubate some use cases; maybe vouchers for discussion
… and I'd also like to talk about Payment Request API v2 features

<Zakim> Ian, you wanted to explain levels :)

<nicktr> Ian: some specifications are only additive (e.g. CSS)

<nicktr> ...in this case, "level" is additional capability

PROPOSED: Dates of multiday meeting 29 March - 1 April
… likely as we did last time: 8am PT each day for 2 hours

<Chris_Wood> 2nd April is a public holiday in the UK

<clinton> +1

<Fawad> +1

<nicktr> +1

<Anne> +1

John Fontana: We can find a date for WebAuthn session

<Gavin> +1

JohnFontana: +1

<Vaishali> +1

<Chris_Wood> +1

<nicktr> Chris_Dee +1

Add PayPak to card network identifier list

card network identifier list

<nicktr> ian: we have a lightweight process to add additional identifier

<nicktr> ...I heard back from 3 different card networks that PayPak is a valid scheme

<nicktr> ...note that our approval is not a guarantee

PROPOSED: Add PayPak to the card identifier list

[Hearing no objections]

Resolution: Add PayPak to the card network identifier list

Action: Ian to add PayPak to the list and notify the requestor,.

Next meeting

18 Feb

Summary of action items

  1. Ian to add PayPak to the list and notify the requestor,.

Summary of resolutions

  1. Add PayPak to the card network identifier list
Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).