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.
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
John Fontana: We can find a date for WebAuthn session
<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,.