See also: IRC log
<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.
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.
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]