Web Payments Working Group Teleconference

doh

sorry on the wrong room

arriving

Money 20/20

https://www.money2020.com/sessions/part-2-one-click-buying-new-w3c-standards-for-web-payments

Detecting support for payment methods / apps

<adamR> Is Ian talking?

<adamR> I’ll have to reconnect

<pascal_bazin> Sorry I cannot join. Technical issues with audio.

<zkoch> Oh, interesting. I also hear nothing

<zkoch> hah

<zkoch> Reconnecting..

https://github.com/zkoch/zkoch.github.io/blob/master/pr-detect-avail.md

Zach, let me know when you are back

<adamR> rouslan: Can you hear Ian?

<rouslan> adamR: I can't hear anyone except beeps

<adamR> Okay, it looks like the VoIP stuff is flat out not working

<zkoch> No one can hear anyone

<adamR> I bet pascal_bazin can’t hear either

<pascal_bazin> no I can't

<zkoch> just hear dyou

<zkoch> i hear rouslan

<adamR> well, it looks like we effecitvely have two bridges

<adamR> One for everyone on voiip

<pascal_bazin> I hear rouslan

<adamR> and one for everyone on the phones

weird

<adamR> And they’re not connected to each other

Let me kill the webex and start again

sorry

<pascal_bazin> I hear Ian from time to time

<zkoch> ::hears things::

https://github.com/zkoch/zkoch.github.io/blob/master/pr-detect-avail.md

<scribe> scribe: Ian

zkoch: There are different use cases....
... I only want to call PR API if there is ANY form of payment available
... up to "I want to know all the payment methods that are supported"
... for privacy reasons, we don't want to leak information. We don't have information about merchants which could be a form of trust relationship.

Proposal is for canMakeActivePayment()

scribe: to avoid privacy issues, it is available once per origin in a window of time

adamR: Regarding time-bound --- per origin across all windows/tabs?

zkoch: Yes, generally.

AdamR: Minor suggestion - allow it to be called with exactly the same payment types as quickly as possible
... if people are doing multiple transactions in multiple tabs, allow them to call for exactly the same payment methods
... I think the devil in the detail here will be what the time period is.
... it might have to be on the order of 10s of minutes or hours to be effective as anti-fingerprinting

zkoch: +1

IJ: Please clarify - can you specify individual payment methods?

zkoch: Yes, via the instantiated payment request object

MaheshK: I agree with the background and requirements...we discussed a bit last week
... on this specific proposal I have a question - PR API can be called from an iframe
... so this new proposed API can be called from an iframe
... so a limit of one-per origin might not work...if multiple iframes are created and deleted
... if merchants really want to, say, show two buttons but prioritize them and call the API twice, what would be the biggest issue

zkoch: This proposal is that there is no definitive way to know for sure whether the user has a particular payment method instantiated.
... I don't think it makes sense to throw in the towel too quickly
... I recognize that there are some immediate needs..but I don't see the value for PR API of making it easy to provide multiple "buy with" buttons on sites
... regarding the multiple iframe risk, I think that is complex...and we can also look at limiting the API to the parent origin

<adamR> +1 on associating with the top-level origin

alyver: I think this is a huge step in the right direction. I see one problem from a Shopify perspective - lots of merchants come from the same origin
... so problem if a shopper is shopping on multiple shopify sites

rouslan: In this case, is there an iframe in the site?

alyver: No, the user is redirected

rouslan: I think the answer lies in a cookie regarding availability of PR API
... the time boxing is per user

alyver; but if the user is at multiple Shopify stores....

rouslan: Just check the cookie

zkoch: I will think more about this...cookies is one idea

alyver: We do have merchants that use their own domains, but others still using the same domain

<Zakim> rouslan, you wanted to talk about shopify usecase

zkoch: I am hearing "positive direction"

MaheshK: Let's discuss further offline

<scribe> ACTION: zkoch to flesh out the proposal additionally, with more info about iframes, time window, Shopify use case [recorded in http://www.w3.org/2016/10/27-wpwg-minutes.html#action01]

<trackbot> Created ACTION-39 - Flesh out the proposal additionally, with more info about iframes, time window, shopify use case [on Zach Koch - due 2016-11-03].

IJ: Mahesh, are you happy with the direction?

Maheshk: Yes, if I can talk with Zach and see if we can consolidate the proposals

IJ: Put on agenda for next week's call?

zach: Yes, maybe not PR ready yet

<MaheshK> Forgot to ask one last question, zkoch: this proposal targeting spec 1.0?

<zkoch> Yes

zkoch: Yes, I think this has come up a lot

(No Roy)

Push payments

https://github.com/w3c/browser-payment-api/pull/292/commits/af2d188ee7df21e9a8f35e57a73f828dc96d7923

zkoch: Editors discussed this week
... some of what AdrianB and I expressed (which we will also do via github)
... I recognize the use case.
... I am concerned about who is going to use the URL
... not clear who uses the URL
... seems also more request on the backend...unlike the payment request that comes back through the mediator, we don't have any control over the data that is sent back to the end point designated by the URL
... you don't have the benefit of payment request normalization
... also, AdrianB thought that the mediator should not create the transaction ID...rather pass it in from the merchant

<ShaneM> yes... my original concept was that the merchant would generate an ID that meant something to them

adamR: What is the perceived advantage of merchant-generated?

https://www.w3.org/2016/10/18-wpwg-push-minutes.html

<Zakim> MaheshK, you wanted to point out may be an adv. of merchant-generated

adamR: My argument against merchant-generated was that merchants would have to do more

MaheshK: There is an advantage to merchant-generated...e.g., merchant has integrated PayPal India
... the server understands the ID...when the button is integrated to the web site...merchant calls API from paypal and sends ID...
... so having the browser generate the ID means paypal india has to make changes

alyver: I think Ian is remembering an Andre/Ian conversation
... when is the ID returned by browser to the merchant...if returned "later" then there could be failure that causes merchant to not get it
... my initial preference was for the merchant to generate the ID...I think that many merchants are used to doing that
... e.g., Shopify creates IDs for merchants
... but other merchants almost always have to send a merchant transaction ID

MattS: I agree with what has been said today. Some additional considerations:
... possibility for optionality..how can you guarantee that merchant scope does not interfere with another merchant's scope
... it's often useful to map IDs to a transaction. E.g., SEPA has concluded you may need multiple transaction IDs.
... so that would favor BOTH: optional merchant and mandatory browser-generated

(IJ thinks you could scope ID by origin)

MattS: You could argue that the merchant generated ID (optional) is method specific, which is how it's modeled for SEPA
... I like having a browser generated standard, but not everyone will be able to use it (or need to)

adamR: +1 to MattS

====

Summary:

- There are use cases for merchant-generated IDs

- Merchants often generate IDs already today

- If they generate, then there's a scope issue on the server side (e.g., might be managed through origin information)

IJ: If people do this all the time and scoping is possible, then is there a remaining big value to user agent generated
... Server could append origin information
... Are your concerns assuaged?

MattS: I haven't thought through all the use cases..
... my gut thinks it is still useful to have both
... but I agree an ID is needed

<scribe> ACTION: Ian to point Roy and the editors at the discussion [recorded in http://www.w3.org/2016/10/27-wpwg-minutes.html#action02]

<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad).

ISO 20022 data type alignment for basic card terms

MattS: As part of SEPA / Credit Transfer spec work, we have aligned work with the SEPA standard...we've also done some work to map those terms back to ISO 20022 terms (which are less Web-friendly)
... we have not yet updated the Credit Transfer specification
... we also were wondering whether to do that mapping for Basic Card
... Kris is going to take the lead on this
... this may change nothing as far as implementation, but small changes might be possible to make life easier.
... one example....CVC is called "Card Security Code" in the specification
... my suggestion is that we align the terms...we've not done that yet but it's the plan

<adamR> +1 to consistency :)

Upcoming meetings

3 Nov - TIME CHANGE

Europeans heads-up!

Upcoming FTF

IJ: No progress on my action to write up a proposal

Where are we?

- PR API issues

scribe: query by merchant

<scribe> ...pending updates to PMI

- Push payments

scribe: we have a concrete proposal

- Payment apps

scribe: awaiting reviews from Max and Zach
... spec is evolving

- Test suite

- Basic Car

scribe: alignment on terms

IJ: Any other topics on people's minds I forgot?