W3C

- DRAFT -

Proposal for eCommerce Task Force

21 Dec 2015

See also: IRC log

Attendees

Present
Linda_Toth_(Conexxus), Matthew_Collier_(Digital_Bazaar), Brian_Russell_(Verifone), Richard_Halter_(ARTS), Jenny_Bullard_(Flash_Foods), David_Longley_(Digital_Bazaar), Shane_McCarron_(Digital_Bazaar), Adrian_Hope-Bailie_(Ripple), Ed_Collupy_(W._Capra_Consulting), Manu_Sporney_(Digital_Bazaar), Kristy_Cook_(Target), Joerg_Heuer_(Deutche_Telekom), David_Lehn_(Digital_Bazaar), Gray_Taylor_(Conexxus), David_Ezell_(NACS), Erik_Anderson_(Bloomberg)
Regrets
Chair
dezell
Scribe
collier-matthew

Contents


<dezell> H

<scribe> scribenick: collier-matthew

dezell: Any questions before introductions?

<dezell> https://www.w3.org/Payments/IG/wiki/Main_Page/ProposalsQ42015/Ecommerce

dezell: I represent NACS, and am co-chair of the WPIG

LindaToth: I am with Conexxus

brian: I've been in payments for 15 years.

mattH: Walmart: manage global acceptance. Representing MAG

Jenny: CIO for Flash... 20 years in the industry. We have a mobile app and we would like to enhance that.

ShaneM: with DigitalBazaar, trying to keep coordinated with other W3C groups.

AdrianHB: Standards officer at Ripple, background in card payments. I am the co-chair of web payments working group.

Steven: In charge of R&D for Enmar Digital promotions.

Richard: Architect for ...

dlongley: Work with DigitalBazaar, I've worked on a number of standards in the past.

edCollupy: member of Conexxus

Kristy from Target in payment acceptance.

jheuer: DTelecom R&D Unit, working with business unit for payments from operator perspective.

GTaylor, With Conexxus

dlehn: Work with DigitalBazaar

manu: Work with DigitalBazaar, we've been working with payments and credentials space for a while. Trying to get the ball rolling on improving the payment experience on the internet.

dezell: Thank you all for being here.
... I would like to talk about the problem we need to solve, then background and use cases
... also talk about way to get the right people to the table.
... two years ago in Paris, we had a workshop on payments.
... there was a lot of excitement. There was one presentation from merchants.

<manu> which was a fantastic presentation from merchants at the Web Payments Workshop!

dezell: standards are the focus. There are many proprietary ways of doing things.

<dezell> https://www.w3.org/Payments/IG/wiki/Main_Page/ProposalsQ42015/Ecommerce

dezell: looking under item 3, ecommerce proposal
... this is about creating a task force on how to get merchants more involved in the standards process.
... One next step would be to approve this document.
... We might do a straw poll at the beginning of next year.
... In the course of implement web payments, merchants want to stay in the loop and make sure their interests are represented.
... I have broken the situation into two halves.
... first half, we can provide to the web payments working group use cases.
... also gather necessary players for requirements and recommendations.

<Zakim> manu, you wanted to note problem statement and "digital offers", "receipts", "coupons", and multiple payment instruments per transaction.

manu: I have read through the proposal and noticed that there a couple things missing.
... I did not see anything about digital offers.
... for example make it easier for consumers to make digital offers easier to find and use.
... No uses cases yet for digital offers. The other thing is that there's nothing about digital receipts.
... Digital Bazaar has some ideas about this, but it it's important that the this group indicates that it's important if that's the case.
... I'm concerned about multiple payment instruments per purchase.
... We want to make sure that Phase I allows us to do that.
... over the past 4+ years, we have proposals about digital offers, receipts and coupons.
... we have not had the opportunity to present those to the WPIG

dezell: Manu is talking about phase I, which is what the wpay workgroup is doing now.
... this is a straight forward payments scenario. It might be *too* simple.
... which is why we should review the use cases.

Erik Anderson from Bloomberg, co-chair with dezell, interested in the future of payments.

<Zakim> jheuer, you wanted to talk about whether convergent scenarios are also in scope?

Kristy: in the goals... we should make payment instruments more broad, including EBT and SNAP

ed_c: I agree, I was thinking about fleet cards and college payment cards

dezell: Let's not forget NACS payroll cards.

jheuer: I want to ask if we want to keep focus on online payments only.
... Or should we also be talking about proximity systems as well.

<Zakim> manu, you wanted to say "we are payment instrument agnostic", and would like to ask for a "would like to have" list and a priority list.

dezell: We want to figure out if we have enough interested and people power to keep this going.

manu: for the retailers that have not been involved in week-to-week meetings. We are payment method agnostic in our approach.
... I want to make sure everyone understands that we are not preferring one payment method over another. But we do have an issue where we are not allowing for multiple payment methods in Phase One.
... what about offer, digital receipts, and coupons. I would be good to know if merchants/retailers are interested in these things.

<Erik> Manu, split payments between 2 different instruments should be required.

manu: the working group needs to know what they should be focusing on in the various phases of their work, (I, II ,III)

Gray: To manu's point. There's a large cognitive load for consumers to use mobile payments. We should be agnostic of payment type.
... there may be a need to handle different data. Multiple payments within one transaction along for digital promotions is *very* important.
... incorporating coupons into the transaction needs to be in Phase I

richard: Are you talking about interface between gateway/aquirer? Which interface are we talking about?

dezell: Our charter calls out the consumer and merchant as stakeholders.
... it is the way the consumer talks to the merchant that we are working on.
... we are trying to align with ISO20022.
... in our case, it's not merchants/aquirers, but we are interested in riding existing rails when possible.

richard: you're referring to retailers?

dezell: yes

<Zakim> AdrianHB, you wanted to find out how merchants would like to see this materialise (coupons, loyalty etc)

Kristy, I agree with Gray. We should have multiple payment instruments within a single transaction. Often we have gift cards.

<AdrianHB> My line is poor

AdrianHB: the work we're doing in the WG is to connect the retailer and the user (payer/payee)
... today payments are high friction and relatively insecure.
... we are trying to standardize communication between those two that allows for more complex messages.
... the exchange of data could be complex encrypted data. We need to deal with payment methods of today as well as payment methods of the future.
... wrt multi-tender...

<Zakim> manu, you wanted to note that we may have a different set of deliverables - the first one being shaking the Web Payments WG and let them know that they may be blind to the pay w/

<AdrianHB> TL;DR: It will help us a great deal if this group get's up to speed on the direction the WG is currently going so that it's easier to relate the group's requirements to what is currently being proposed

manu: The higher priority thing might be to make sure that the WG pays attention to retailers needs in Phase One.
... There is no multi-tender proposal in place.
... there's a disconnect between what WG is working on and what retailer want.

<AdrianHB> e.g. Multi-tender, sharing customer data etc are possible but maybe in a way that merchnats won't be happy with

manu: also we need to get other use cases into the mix as well, like couplons/offers.

dezell: I think we got some good points out of that discusssion.
... I would like to spend the balance of the call talking about how we might make progress on getting a marker down for the working group.
... One avenue may be use cases.

<AdrianHB> my concern is that if I tell this group: "You can handle multi-tender by developing a custom payment method" it will be helpful if this group understands what "develop a custom payment method" means

dezell: are people here willing to help on creating a workshop on creating a browser interface for payments on the web.
... we would like all of this to be easy and standardized.

<ShaneM> It should be easy to do WITHIN a useragent and WITHIN an application that just wants to accept payments (e.g., a mobile app)

<dezell> https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html

<AdrianHB> another concern is that some merchant requirements (know the customer) conflict with user requirements (privacy)

dezell: What is in the use cases... which can be found in the table of contents.

<manu> +1 to what everything AdrianHB is saying - very important stuff.

<manu> https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#an-overview-of-the-payment-phases

Section 7 has actual scenarios.

dezell: as we create these payments cases, and think about them in phases, we can determine what is necessary to support that.

Section 6 defines each of the necessary steps.

<AdrianHB> final concern is that if we are too explicit with standards we make it very difficult for anyone to innovate. We need to find a balance in all these things and where that balance is found is influenced by the perspective of the participants. If we don't have a wide merchant participation then the balance will tend away from the merchant's requirements...

<dlongley> +1 to Adrian's comments as well.

scribe: discovery offer is not about digital offers, but how a consumer might collaborate with a merchant and negotiate payment terms.
... please review over the next few weeks. I will be circulating use cases that follow this model.
... I want to show this model to reduce confusion.
... please point out anything that could be improved.

<Zakim> manu, you wanted to point out the points Adrian is making in IRC.

manu: I would like to point out some of what AdrianHB has been typing in IRC
... he say... we're looking for the right balance wrt to privacy.
... to-date, we have not had good engagement with retailers. When that happens, retailers groups might not get met.
... we need clear use cases to inform the work.
... It helps those doing the work prioritize the work.

<AdrianHB> A big concern for the WG is developing standards that will be deployed. If we don't have sufficient engagement during the work that is a big risk

manu: Please do give attention to the use cases and make your support known.

<dezell> 1. propose a task force to investigate this topic.

<dezell> 2. adopt deliverables for the task force:

<dezell> a) use cases revision

<dezell> b) possible WG

<dezell> c) workshop creation

<Gray> Agree with Adrian & Manu, we need to block diagram such uses of multi-tender. Also, we cannot forget that the "pull" style of current payments (where merchant pulls payment credentials) is not where market is going. THink how do I, as a consumer, PUSH adequate information that the merchant is comfortable that settlement will occur

<manu> +1 to Gray - very little focus on push payments now in the Web Payments WG (we support it, but PSPs are putting more of a focus on pull these days w/ no counterbalance from retailers for push)

dezell: We might want to create a task-force.

<AdrianHB> Please all have a look at some of the content on the WG wiki already and feel free to reach out to me if you need some info

<AdrianHB> https://github.com/w3c/webpayments/wiki/A-Payments-Initiation-Architecture-for-the-Web

dezell: if we create a task-force, we could revise the use cases and get the retailers requirements in the hands of the working group.
... also we might create a working group focused on retailer issues.
... what we might do is have a workshop

<AdrianHB> Our work documenting the flows in use today (that we want to support) is also important: https://github.com/w3c/webpayments/wiki/Flows

dezell: there's a lot of working going on in various organizations. We have a unique relationship with web developers here at the W3C.

<Gray> +1 to Manu - agree, we keep trying to solve for the ISO/CVV world, when this will be tokenized and pushed.

dezell: accessibility is an important issue at W3C.

<AdrianHB> Also have a look at some of the proposals being considered by the WG:

<AdrianHB> https://github.com/WICG/web-payments-browser-api

<AdrianHB> https://github.com/WICG/paymentrequest

<AdrianHB> https://github.com/web-payments/web-payments-messaging/

<AdrianHB> https://github.com/web-payments/web-payments-http-api

<dlongley> +1 to Gray - "pushing" payment credentials that the merchant doesn't need to see is the future, but certain "pull" operations may continue to exist for other types of "credentials" merchants do need to see

Gray: I see a huge difference between push/pull payments. Push payments should be considered in the retailer space.

<Zakim> manu, you wanted to note that when we try to talk about 'push' the response is: "but that's not how 95% of payments happen today".

Gray: I believe the future is in push payments.

<AdrianHB> +1 to support for push (as Erik said earlier, we need to support the future) but we also need to support the present to get adoption

manu: I think there's a huge desire for push payments. Hearing that push payments is important to retailers is an important message to the working group.

Erik: Tokenization of ALL payment data is important, we need to hear that from retailers as well.

<Gray> Agree Erik - all PII should be vailed of tokenization

dezell: I will be looking for additional retailer when I am at the NRF show.

<AdrianHB> thanks all

There is a MAG meeting in February.

which is another opportunity to collect feedback from people in the industry.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2015/12/21 20:23:14 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/present+ matt//
Succeeded: s/present+ shane//
Succeeded: s/Kristi/Kristy/
Found ScribeNick: collier-matthew
Inferring Scribes: collier-matthew

WARNING: No "Topic:" lines found.

Present: Linda_Toth_(Conexxus) Matthew_Collier_(Digital_Bazaar) Brian_Russell_(Verifone) Richard_Halter_(ARTS) Jenny_Bullard_(Flash_Foods) David_Longley_(Digital_Bazaar) Shane_McCarron_(Digital_Bazaar) Adrian_Hope-Bailie_(Ripple) Ed_Collupy_(W._Capra_Consulting) Manu_Sporney_(Digital_Bazaar) Kristy_Cook_(Target) Joerg_Heuer_(Deutche_Telekom) David_Lehn_(Digital_Bazaar) Gray_Taylor_(Conexxus) David_Ezell_(NACS) Erik_Anderson_(Bloomberg)
Got date from IRC log name: 21 Dec 2015
Guessing minutes URL: http://www.w3.org/2015/12/21-wpay-ecom-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


[End of scribe.perl diagnostic output]