Web Payments Working Group Teleconference

<scribe> scribe: Ian

<AdrianHB> https://github.com/w3c/webpayments/wiki/Agenda-20160602

<zkoch> thanks! :D

Face-to-face meeting

adrianhb: Please register

https://www.w3.org/2002/09/wbs/83744/wpwgftf-201607/

adrianhb: Suggest candidate topics

<zkoch> I’m behind on email and everything is a mess, can you link to the current registration spec?

there is no current spec

stay tuned

<manu> Ian: My expectation is that, given availability and holidays, we won't be in a position to get to FPWD by the face-to-face meeting. Step 1 is to get a document so the group has something to look at. That's the first order of business.

GitHub organization update

<manu> +1 to AdrianHB and triag'ing! :)

adrianhb: Did some issue triage and maintenance...moved specs into their own repos

<manu> I like the re-org :)

adrianhb: PMI and Card specs now in their own repos

<adrianba> not clear to me why this is better - why do we need to scatter issues all over GitHub?

<zkoch> Yeah, I think what I was looking for is current editor draft

IJ: That spec is not up to date with what we have been discussing

https://github.com/w3c/webpayments/wiki/PaymentApp_Notes

<manu> Ian: A couple of notes - that spec is not up to date w/ what we've been discussing, once place to look in particular is that wiki (above)

<zkoch> Got it, thanks

<manu> Ian: We'd move some of that material into the spec, that hasn't been done yet.

Task force has: Roy, Dongwoo, AHB, Jason, Adam, Ian

<zkoch> Yeah, I’ll follow up

<AdrianHB> adrianba: pros and cons to both approaches, the group resolved to follow most other W3C groups and have a repo per sepc

<manu> Ian: We've also tried to see if we can get a Google person into that group.

<manu> Ian: I've also gotten interest from other companies on 3rd party payment app spec.

<ShaneM> yay

adrianhb: Yes, I recognize the github migration means more issue lists to follow
... I would like to make this easier through a dashboard
... I will take an action to look into getting a view of those issues

<scribe> ACTION: AdrianHB to look into creating an aggregate view of issues across issues lists [recorded in http://www.w3.org/2016/06/02-wpwg-minutes.html#action01]

<trackbot> Error finding 'AdrianHB'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.

<adrianba> :( it's common in groups where specs are either unrelated or being worked on by different people

Issue 4

Per payment method pricing

MattS: I think we should be able to distinguish debit from credit.
... there's the real world use case: biggest online train ticket in the UK has a surcharge.
... the other use case is @@

adrianhb: You need to know the surcharge up front. if you pick, for example, apple pay...you get a surcharge if you pick your card within apple pay
... this may cause you to cancel your payment and pick another instrument
... this is a smaller use case today than the other 2 I mentioned (in the UK)

MattS: Another use case is "bitcoin".
... how can you construct a payment request when you have a value in Sterling and a value in Bitcon

adrianhb: My assumption is that users want to know about the surcharge up front

MattS: In my case, we are talking about a (native) payment app

<manu> Ian: I've begun to think about this, had a good conversation about Rouslan and Jason about it. Do we want to dive into this?

<manu> Ian: Or I could go off and look at framing.

====

* What data should the merchant provide? For instance, should the merchant and customer somehow reach agreement

on the currency BEFORE the API is invoked, so that only the “final data” is sent to the API? Or should there be all the

data necessary to display different prices and currencies?

Assuming “all the data” is given to the API, how should we do that? Today the API supports a single (global) CurrencyAmount.

But since we have payment method specific data, we could change the API to support an additional CurrencyAmount per

payment method. The per-payment-method data would override the global data.

* Furthermore, there may be more than one CurrencyAmount per payment method (“you can pay me this much in USD and

this much in Euros”). Therefore, we might want to change both the global and “local” CurrencyAmount to “CurrencyAmount list”.

* The next question that arises is: how are the different CurrencyAmounts displayed to the user? Presumably the user would want

to know, for each payment method, the available CurrencyAmounts. This is a UI challenge for browser vendors and we need to

chat with them about it.

* When I choose a particular CurrencyAmount, I want to see an updated “Total”. This means that the API would need to support

updates to the PaymentDetails based on the selected payment instrument’s CurrencyAmount.

<manu> Ian: This is a mix of thinking about it and design ideas. It sounds like we have a need for per-payment methods for pricing methods - today there is one global currency amount. One way to manage this is to keep a global currency amount - maybe we could add a local currency amount that overrides the global one.

<manu> Ian: Adrian Bateman has pointed out that this would make the data different - private data today, could be public.

<manu> Ian: X GBP, Y BTC - if we wanted to do that both globally and locally - if we have a list of pairs both globally and locally - that might go a long way, a number of implications - display gets harder - hearing whether it's tractable to do that - whether User should know about implications on price.

<manu> Ian: Need to display info - with payment instrument available to me - when I choose it, user shouldn't get surprised by price change. Update possibility for shipping address. Adrian Bateman has mentioned it, Matt has mentioned it - key topics - rudimentary proposals, how to deal with display - need to be discussed.

<Zakim> manu, you wanted to ask if we could hear from people opposed to supporting varying amounts depending on payment method?

Manu: Anyone opposed to supporting the use case of per-payment-method pricing?

<adrianba> Might not going to support this in v1 implementation

AdrianHB: There have been some near proposals but not formal enough to make a yes/no decision yet.

<zkoch> yes

AdrianHB: Rouslan had a good way of thinking about this

rouslan: Per method pricing is an important topic. We need to handle it.
... I'm ok if it's only in v2
... I think AdrianBateman had a concern that if we specify pricing in payment method data we need to define it more than currenly. But I believe that we can make the "local data" a sibling

<AdrianHB> +1 for sibling

rouslan: Ian mentioned that we might need a way for the site to update the total. That's something to consider

<adamR> + for making local data a sibling to payment app data

rouslan: what I mentioned on GitHub yesterday was a way to think about payment app registration and how they specify different ways to invoke the app
... that's a separate topic (for the payment app task force)

<MattS> +1 to sibling

rouslan: I have been thinking about how to do this on Android and would like to make it similar for Web
... I will publish info related to Android that should allow (platform-specific) integration

adrianhb: In Rouslan's post, there was something that interested me as a different approach from what we've discussed so far.
... users choose a payment app when there's a payment method match
... Rouslan's idea is interesting and solves another problem that's not yet been articulated.
... namely, there are benefits or side effects of picking a payment INSTRUMENT within a payment app
... suppose I choose an app that has a bitcoin balance and a visa card.
... I might choose one or the other based on price
... but Visa offers me "buyer protection"
... as a User I need to know which payment instruments are available
... rouslan's proposal gives us the benefits of choosing a payment app (merchant doesn't know what you have installed)

<dlongley> +1 for the merchant not having to know, capture it all in the payment request message

adrianhb: but the user experience is closer to Adrian Bateman's demo
... where options look like payment instruments
... how they look and how they are invoked is determined by the payment app
... so the payment app still manages the flow, but the entry point can be instrument specific
... that would resolve the "display issue"

zkoch: I have come around to the use case of per method prices
... it's less of a use case, but I'm convinced it's a real use case that we need to support.
... I still want the majority use case to be easy to support
... I am also in the camp that this might be for v2

adrianhb: I am on the fence re: v1 or v2...but I think that if we see a proposal that is not wildly diverging from what we have right now, I would say it's worth doing

<adrianba> I'm interested in seeing proposals - I also think we should consider outlining how to do it but accept that initial implementations might not actually support it

manu: I think this is a real use case; even if minority.

<adrianba> I'm concerned that adding it later might be difficult to feature detect

(IJ is interested in writing the proposal with Rouslan)

<adrianba> However, we ought to have a defined escape for implementations that don't do it

<AdrianHB> I don't agree that it's a minority use case - maybe in the US

manu: I'd be ok if we put a proposal forward and said "yes, that's the way we WOULD do it" but not do in v1

<Zakim> manu, you wanted to agree w/ zach - note that he thinks it's a real, minority use case - but if we don't do in v1, we might paint ourselves into a corner for v2.

<zkoch> That sounds reasonable to me

<dlongley> interested in seeing a proposal, not sure about *how* we should do it (lots of trade offs to consider), agree it's an important use case

<rouslan> Ian: +1

<scribe> ACTION: Ian to work with Rouslan on a proposal [recorded in http://www.w3.org/2016/06/02-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).

Grouping semantics

adrianhb; I think that grouping semantics may also bear upon pricing

scribe: as in "cards cost this much, but this card costs this much more"

<manu> https://github.com/w3c/webpayments-method-identifiers/issues/1

adrianhb; Let me summarize a chat I had with MattS and Ian on grouping/subclassing

https://github.com/w3c/webpayments/wiki/PMI_Notes#matching

AdrianHB: Overview of the topic
... one idea is to start to look at "payment method identifiers + constraints"
... so for example to say "I support this particular sub-brand of cards only" or "I only support this version of bitcoin"
... so you would identify a payment method BUT ONLY WITH THESE CONSTRAINTS.
... we are still exploring the topic

(e.g., expressing constraints as opt-in/opt-out)

<manu> Ian: The high-level idea is to get the additional nuance that we may want, include some constraints - a few questions arise.

<manu> Ian: What does it mean to match?

<manu> Ian: If you have a merchant-side identifier, and a user-side identifier and constraints - how do you tell what's a match and the resulting constraints are. No proposal yet, just introducing the topic.

<manu> Ian: How do you write those constraints down? Different ways you can do it w/ a URL - with query parameters, accompany PMIs, some other questions...

<manu> Ian: When I want to express a number of constraints for the same payment method - accept all credit cards except this one - what's the easiest/most straightforward way to do that?

<dlongley> sounds like a DSL to me ... which, IMO, would be good as a helper library, but not necessarily baked into the API.

<manu> Ian: In this wiki - no one would want a complex constraint language - this is one of those topics that could end up being v2.

<AdrianHB> A DSL would be useful but the underlying format must still support the features we need

<dlongley> +1 to that

<manu> Ian: We have clear documentation that these are real world use cases - people talking about exactly these sorts of things. We're having this discussion, hope to have a proposal to beat on by F2F meeting or sooner. Simple proposal - can't be complicated.

<dlongley> i'm saying we may be able to push the complexity to a helper library, but have it convert to a simple format that machines can do something useful with

<dlongley> (machines being mediators and apps)

<manu> Ian: Let's not discuss this anymore - not a proposal yet, let's not dive into it.

matts: One reason I support this is that it addresses the issue we have of getting card scheme producers more involved
... the proposal of "cards" + constraints to describe scheme allows us to make progress on identifiers for v1

manu: I agree with MattS that it would be good to get the card vendors more involved

<Zakim> manu, you wanted to be opposed to the concept in v1.

manu: will people not use the API if we don't have this? I don't see it as such
... we have proposed a way around this (via a library)
... and we can experimenet

(IJ: The library does not address the problem)

(...because there is no relationship (e.g., subclassing) among PMIs)

manu: I don't think we have the data we need to come up with a solution for v1.

Issue 157

Browser API Issue #157 Should the payment mediator pass all payment method data to the payment app or just relevant data?

adrianhb: Question raised - what is the information that payment apps need to do their job?
... one answer is "send info as-is to the payment app"
... some believe that's the right thing to do; others do not (e.g., privacy issues)
... so another way to do this is for the mediator to send the data that the payment app can do something with
... one motivation for that choice is for the payment app should not farm information from merchants

rouslan: I think payment apps should be able to distinguish themselves based on privacy support
... they should be able to say what information they require
... I think the user agent should be able to invoke the payment app with the information that the payment app requires
... I think this should be discussed more in the payment app task force

-1 to passing all the data to the payment app

<Zakim> manu, you wanted to say "all payment method data is passed" - I'd rather not have to define complex logic in the browser/http API that says what should and shouldn't be forwarded

scribe: among other reasons, it makes it easier to write payment apps, saves bandwidth, improves privacy

manu: If we are going to say "we are not going to pass data, we are going to pass subset" we need to define that in the spec.
... I am hearing complex decision algorithms.

<AdrianHB> wouldn't the algo to pick the set of data be the same as the one used for matching?

manu: one easy way of doing this is to say "here's data that goes to the payment app" and that's object 1 and "here's data that does not go to the app" and that's object 2

<alyver> -1 to passing all the shopping cart data to the payment app. Merchants and platform providers usually don't want this information shared.

<manu> oh, I didn't understand the question as that.

<alyver> +1 to Manu's discussion

dlongley: I don't know how much I buy the privacy argument; it's the method that's chosen by the merchant...
... I don't think the mediator knows all the info the app might use
... e.g., user might not have balance to pay...the apps should be able to free to innovate and do what they want.
... apps could provide the best experience

<Zakim> dlongley, you wanted to offer another argument

<zkoch> Bad audio

<adamR> Can’t make out any words

IJ: Rationale - save bandwidth...also save payment apps from having to do more work

<dlongley> to be clear +1 for sending all the core payment request data -- that doesn't mean sending the shopping cart data to the app.

zkoch: I think I favor not sending all data to the payment app
... first it seems unnecessary
... we should limit info to the set the app needs to return a payment credential
... I don't think this would be complex; should be simply choosing set of data we think is important

<manu> zkoch: I haven't thought about this too deeply - we don't need to pass all data to the payment app - it seems unnecessary, user has chosen something specific. I acknowledge the notion of complexity - this is simple - just pick set of data that's important.

zkoch: there's a user experience argument as well
... the payment app might want to say "We also support X, Y, Z" and prompt users to install new methods; but that's not a good user experience

<manu> zkoch: There is a User Experience argument - this is a strength that a payment app has - more control - still working this out in my head. I'd like to give payment app limited data to process the transaction. This isn't so much about giving payment apps the ability to upsell you.

zkoch: this is about processing transactions and NOT giving payment apps the upsale role

adamr: I agree broadly with Zach's point. First I don't think it will be complicated to implement by the mediator
... I think we need to do privacy improving things in v1

<manu> To be clear - I misunderstood what AdrianHB was asking.

<manu> I agree w/ what Zach and Adam said...

dlongley: By effectively putting our fingers more into the data, we need to standardize more about the data
... all of those things put constraints on extensibility

<manu> I thought we were talking about picking and choosing data out of the payment method data itself.

<manu> so, for visa - pick and choose data out of the visa payment method data... that's what I was opposed to.

<rouslan> manu: +1. I think we're thinking about the same idea.

adrianhb: I am hearing stronger support for "just send data for supported methods" but not ready yet to resolve
... I would like to close that issue soon; please put comments in the wiki

Next meeting

9 June