See also: IRC log
<dezell> +1 to change
<dlongley-db> +1
<scribe> scribe: manu
<jean-yves> +1
manu: Any objections to change
agenda to talk about Ian's slides?
... ok, no objections - any other changes/additions to
agenda?
http://www.w3.org/2015/Talks/ij-usecases/
<Ian> http://www.w3.org/2015/Talks/ij-usecases/?full#1
<Ian> https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html
Ian: Thanks for accommodating, I
had started to look at the use cases document, 3.1
... I thought I'd try to do something w/ it - I struggled, I
needed a backgrounder up front - a mental model.
... I started to play with that - chatted with Manu to try and
get a baseline sanity check on it - but we wanted to have it in
time for the meeting.
http://www.w3.org/2015/Talks/ij-usecases/?full#2
Ian: This is just a proposal -
Laurent's review of it was very helpful. Two main questions
that come out of that review - those have been added to end of
deck.
... Wanted to distinguish the goals for this slide deck w/ use
cases - different goals for this slide deck. This proposal is
meant to give a simplified view of one or more payment
flows.
... Several reasons for this deck - it's challenging to
understand all the detailed scenarios that all of you already
know.
... second reason - it helps to have a simple model in mind so
that when you get to use cases, you know how they relate to one
another.
... Once we see how they relate, it's easy to see where the
gaps are.
... Another thing I felt at the face-to-face meeting, some of
the use cases overlap - why?
... For example, use case where someone picks one payment
instrument out of a digital wallet, or two - are they similar
enough that we should get them into the same use case?
... Or maybe they're not different - we need to understand that
we're not duplicating use cases.
... recognize at the same time that many other efforts in
industry have done something like this - Manu pointed me to
previous work a month and a half ago wrt. phases of
transaction. We want to align w/ what others have done, we want
to make sure that by being simple, we're not giving the false
impression that we're not aware of the other stuff out
there.
... This is a starting point, we need to bind to ISO20022,
ISO12812, etc.
<Zakim> dezell, you wanted to ask about "do not overlap" on slide 3
dezell: You examples were fine, I
get that.
... Obviously overlap is going to be almost impossible to
avoid, we do want to reduce it as much as possible.
... I want to make sure that people in W3C understand this
document, but people outside should really understand it as
well. I know X9 has done this sort of exercise before - we
should be aware of that.
... Channelling Erik - we have ISO20022 - european way of
looking at everything payment - there is a natural business
lens that you can look at this stuff through.
... That's an aside - we could gain credibility by making sure
we link to ISO20022.
<Ian> manu: Yes, we need to show how all the bits map to iso20022 and other docs
http://www.w3.org/2015/Talks/ij-usecases/?full#4
Ian: One of the thoughts is that
we have one simple framework - all primary financial
transactions we have in mind can be put into that
framework.
... Overall, it should just work.
... Laurent said he's not sure that it does, but we do want to
try.
... We do want to discuss this later.
<jean-yves> +1 to David's suggestion to link to industry's standards
Ian: In this presentation, we
could have a single flow description.
... So keep that in mind as we're going through this slide
deck.
http://www.w3.org/2015/Talks/ij-usecases/?full#5
Ian: So this is broken into 3 phases...
1. Payer Initiates Payment
2. Payee Receives Payment
3. Payer Receives Product/Receipt
Ian: One of the goals of the
description is to not take exceptions into account - that'll
complicate the simple model.
... Again, Laurent said that maybe 4 phases is a better
approach - would love to hear from him on the call - at the end
of the call.
http://www.w3.org/2015/Talks/ij-usecases/?full#6
Ian: Each phase has multiple
steps
... I give money to someone, the get the money, I get my stuff,
basically.
... I gave some examples of how some steps are
skipped/ignored.
Laurent: I can wait on my comment until the end.
dezell: I like these, I also like
the 4 phases, I can think where these things happen in some
other order... maybe we should talk about "flow" or
"steps"
... In order to come up with something universal - the moment
we force an order, we may have to add other steps.
... I think for our primary actors in our charter - payer/payee
- these are the three things in payment that count.
... we may lose the narrative elsewhere.
Ian: So when we talk about
steps/phases/flows - we need examples that don't fit.
... Concrete examples where it's a bad fit would be
helpful.
http://www.w3.org/2015/Talks/ij-usecases/?full#7
Ian: Going faster through these
in order to get to the discussion.
... Discovery of Offer, Agreement on Terms - lots can happen in
here, we can touch on specifics like authentication deeper in
the use cases.
... Selection of Instruments and Authorization to Access
Instruments.
http://www.w3.org/2015/Talks/ij-usecases/?full#8
Ian: Steps for Payee Receives
Payment
... Verification of Available Funds. In some cases, Payee may
need proof of funds or proof of hold before finalizing payment
and delivery of the product.
... Authorization of Transfer. Payee receives proof that the
transfer of funds has been authorized.
... Based on Laurent's comments, I tweaked the text.
... unfortunately, slide content disappears at bottom at slide
8 - I'll fix that...
... Funds Transferred. The actual transfer of funds will be
initiated (e.g., by a merchant, customer's payment processor,
acquiring or issuing banks, etc.) and carried out in a variety
of (scheme-dependent) ways. Time can be immediate transfer, or
delay of 2-7 days, etc.
http://www.w3.org/2015/Talks/ij-usecases/?full#9
Ian: Delivery of Product. Payer
receives goods or services immediately, at a later date,
automatically on a recurring basis, etc. depending on the terms
of the purchase.
... Delivery of Receipt. Depending on the payment scheme(s)
chosen, there are various ways and times that a receipt may be
delivered (e.g., credit card receipt, digital proof of
purchase, etc.).
http://www.w3.org/2015/Talks/ij-usecases/?full#10
Ian: So, maybe the steps aren't
perfect... point taken, but maybe general arrangement is
good.
... Coming at this as a reader trying to understand what we are
doing - maybe this is better than priority-order.
... As Laurent mentioned, we're hinting about how these might
be expressed.
http://www.w3.org/2015/Talks/ij-usecases/?full#12
Ian: So, there are alternative ways of achieving each sub-step... for example, payment initiated via browser, or via mobile app.
http://www.w3.org/2015/Talks/ij-usecases/?full#13
Ian: This is about revealing
personal information - the use cases felt similar to me - could
be described under similar use case - in one case you have to
have an account and login, in another one you need to tell the
payee who you are, but you may not need an account, and third
one is no need to identify, no need for account.
... I'd like that these don't overlap - I want to make sure
we're not describing things that are essentially the same, but
saying they're different.
... If they are different, we need to be very clear about
it.
... That's all up for discussion.
http://www.w3.org/2015/Talks/ij-usecases/?full#14
Ian: Some use cases that are not
prioritized - put them in there anyway - term negotiation.
Sometimes merchant might want to tell customer about
instrument. Agreement of terms will affect selection of payment
instrument. Or machine-readable negotiation is an
optimization.
... Assisted term negotation is the key point here.
http://www.w3.org/2015/Talks/ij-usecases/?full#15
Ian: Manual selection of payment
instruments vs. assisted selection of instruments.
... I'm trying very hard to make them not overlap... assisted
selection vs. manual selection.
... Again, these are things that seem to suggest that things
might affect users' selection of payment instrument.
http://www.w3.org/2015/Talks/ij-usecases/?full#16
Ian: Manu said proof of funds and proof of hold may be appropriate here.
http://www.w3.org/2015/Talks/ij-usecases/?full#17
Ian: These are manu's additions as well - these might be good items for authorization of transfer...
http://www.w3.org/2015/Talks/ij-usecases/?full#18
Ian: I just wanted to point out here that some delays may happen in here.
<Zakim> dezell, you wanted to ask about "flow"
http://www.w3.org/2015/Talks/ij-usecases/?full#20
ack
<Zakim> manu, you wanted to mention 3-corner / 4-corner
<dezell> manu: not sure where 3 corner or 4 corner fit into this.
<dezell> manu: I think slide 17 is a good place for that.
<dezell> manu: just because it doesn't say "push/pull" or "3 corner/4 corner" doesn't mean that's out.
Ian: There's an interesting question about whether the simple model needs to spell out deep technical details about how payment schemes work.
<dezell> ian: it's not clear whether we should mention these things parenthetically, or have the use cases carry the load of the terminology.
Ian: Maybe parenthetically these things are mentioned, but we don't want to overburden the framework w/ talking about those things. We need to make sure that the people that are looking for that know what's going on.
jean-yves: This is interesting -
so far, I feel puzzled about it. I don't identify the payment
service providers in here - where are they?
... I can't imagine any scheme without defining who are the
payment service providers.
... for one, in the 3 corner or 4 corner schemes, so far not
having the PSPs in here is problematic.
Ian: My goal would be that at
that level of abstraction, you don't need to know who a PSP is
- use cases can talk about payment service provider.
... If I want to go to a store and get my things - I don't know
anything about payment service provider. If we can introduce
people to the topic w/o that level of detail.
... That would be good.
... We also need to show how real payment schemes fit into this
model. That's mentioned a little further down.
jean-yves: I don't agree - you may not know who is the payment service provider - the PSP is the one that enforces the rules. If you don't know the rules, you don't pay.
Ian: Let's add that to the agenda - Exposing the rules of a payment scheme.
<dezell> david: Katie has provided an email (ref slide 17) about how order might change. https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Feb/0079.html
<Ian> (Dave, see goals: "Introduce a simple payment processing framework to so that all readers understand how use cases relate to one another and how, together, they represent a logical sequence of payment activities.")
Laurent: I just want to clarify -
your presentation focuses on customer and merchant - I like
that, most of the work of the group should be focused
there.
... I'm wondering why 3-corner / 4-corner isn't mentioned or
push vs. pull.
Laurent_: By focusing on interaction between merchant/customer, we definitely put the PSPs and acquirers and issuers on the sideline. That might be a good thing to scope the discussion.
Ian: It's true that it's not
clear to me where the details will come in. For example, it
could be that some use cases are one level of detail down in a
piece of the overall flow.
... You still don't need to know what's going on in the
background to know the use case.
... We may have to surface two different use cases to talk
about detailed flows.
... This is the framework, not the use cases.
... We will see the exact exchange of data of all parties at
the level of detail of who the PSPs, acquirers, etc. are. It's
complementary work to high-level discussion.
<Zakim> dsr, you wanted to suggest we consider the target audiences for our use case work
dsr: I like the analysis - who is
the target audience. Are the use cases for the end user? We
don't need any technical detail in that case.
... Or, do we have analysis from a technical expert
perspective? Then we have people that are interested in this
stuff from a "what does this mean for the Web?"
perspective.
Ian: Todays answer to that
question - this framework which lives at beginning of use cases
document is for both the web community and the payments
industry.
... This high-level is for everybody, then the use cases will
dive into the details for payment industry folks.
... I don't have info yet on how to talk to Web community...
good point, and part of that may emerge when we start to hear
from browser vendors.
<Zakim> manu, you wanted to mention that we still keep the use cases we have.
<Ian> manu: Ian is not proposing we get rid of use cases; this is a framework for organizing the ones we have
<Ian> ...this is a high-level explanation of flow, then you get to the use cases for more detail
<Ian> ...so when the document is done, there will be material for people who are new to the topic, and also for veterans who can dig into the details in the use cases.
<Ian> ...and they will understand that we are talking about 3/4-corner, regulatory issues, etc.
<Zakim> dezell, you wanted to ask about 1) clarification of Laurant's view, and 2) iteration of this model
dezell: First of all, thanks Ian
for all the hard work. It's a thankless job to try and simplify
this - this is the right thing to try.
... Three points...
... 1) The role of iteration in this taxonomy that you're
proposing.
... 2) Can we adopt this as a move forward strategy?
... 3) I'm not quite clear on Laurent's view
... So far everything I see here looks good, we need to make
this into a living taxonomy and I think we need to use it to
move forward.
Ian: Let me finish and I'll pick
up the next agenda item.
... if this is done well - at the front of the document, that
would be good. People should be able to navigate easily once
they've understood the high-level.
... We know that people will need to understand how the flow
works. My favorite payment scheme, how does it work in this
framework.
... If there are other flow models that are in usage in other
parts of industry - especially ones that are widely accepted
(liek ISO20022), don't know about those - please suggest ones
we can re-use.
manu: Erik should chime in wrt. ISO20022
Ian: Dave made a good point,
we'll have to make sure browser vendors see what this makes for
them.
... here's an example of a person-to-person payment scheme:
http://www.w3.org/2015/Talks/ij-usecases/?full#22
... Very rough analysis to illustrate what I mean.
... Refunds - http://www.w3.org/2015/Talks/ij-usecases/?full#23
... I still didn't do my actual action item to work on 3.1 -
but if we start to adopt something like this, that'll affect
the templates for the use cases.
<Zakim> manu, you wanted to mention the time.
Laurent: In description of phases, first phase - payer initiates payment - what you put as steps in this phase - it's the steps diagram - select the item, agree on terms, pick payment facilities - purchase part of payment flow.
<Ian> Laurent comments
Laurent: interesting to separate
purchase part from payment part.
... What sort of instrument does payer have - what do you
select/trigger - 4 phases
... payer initiates the purchase.
... That's good - contains offer discovery, add optional step -
coupons/loyalty overall selection of payment - payment trigger
phase.
... Related to right implement to do the payment, trigger the
payment processing - either on merchant side or payer
side.
... After the payment figure case - payer receives payment...
slide 8 and 9 - don't have much comments.
... You integrated most of my comments already
<Zakim> manu, you wanted to ask Laurent if he things this is a good way forward?
<Ian> Manu: Not quite ready to speak to 3 phases or 4
<Ian> Manu question to group: Can we turn slides 1-10 into the intro of the use cases docs
<Ian> Laurent: +1 to a model for organizing and scoping use cases
Laurent: I like the approach of describing various steps in payment transaction - classify / scope that - so not opposed to that. I like this direction and would like it to be the main approach of the group.
<Ian> ...really like the direction and want it to be the main approach for the group
<dezell> david: I think Laurent's suggestion is a +1 for flexibility going forward, and we're good.
jean-yves: About the approach -
it's a big step forward.
... You have two things to think about - 1) is about the how ,
then 2) is about what is described.
... I wonder about managing rules in this process.
... about the way we're describing - I think it's an
improvement over the current document.
... I'm convinced by the approach, not sure about the result of
this approach. One of my concerns is about rules.
... When you pick up paypal or google wallet, you're supposed
to know how it works - you know the rules.
... When we are making a transaction between one payer and one
payee - the rules for the same instrument could be quite
different if you are a customer w/ paypal vs. SEPA - rules can
change based on location of payer payee too. Managing rules is
really difficult - scheme - rule embedded in location of payer
and payee.
... You can call it regulation/jurisdiction - managing rules is
one of the most difficult and relevant things we have to pay
attention to.
... so far, I can't imagine how we'll be able to integrate that
problem of managing rules - it will be something we have to
do.
Ian: What I propose to do is,
talking with Laurent and Manu, offline - maybe we can tease out
second topic - one flow or multiple flows.
... Jean-Yves - if we end up having multiple flows - some of
them are more readily conducive to talking about regulatory
topics than others.
... I don't think about regulations / terms when I use my
credit card - doesn't surface as much in consumer->merchant
direction. However, if we do more to address different types of
flows - regulatory topics appear.
... Second thing to think about - learn about regulatory topics
you care about should be integrated into second draft.
<Laurent_> no objections
<Ian> Manu: Proposed to transform the heart of this presentation (after it is updated) to make this the intro the FPWD of the use cases doc
<dlongley-db> no objection
<Ian> +1
<jean-yves> =&
manu: +1
<dezell> +1
<jean-yves> +1
<dlongley-db> +1
<Ian> ACTION: Ian to revise the presentation based on discussion today and email comments. [recorded in http://www.w3.org/2015/02/26-wpay-minutes.html#action01]
<jean-yves> s/I feel a bit puzzled/I feel puzzled/
<chaals> [apologies - had a once/month conflict :( ]
<scribe> ACTION: Manu to integrate Ian's revised presentation into Web Payments IG Use Cases introductory section. [recorded in http://www.w3.org/2015/02/26-wpay-minutes.html#action02]
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/I feel a bit ???/I feel puzzled/ Succeeded: s/docs/doc/ FAILED: s/I feel a bit ???/I feel puzzled/ Succeeded: s/???/puzzled/ Succeeded: s/Number of flows and phases// Found Scribe: manu Inferring ScribeNick: manu Default Present: +1.540.961.aaaa, manu, dlongley, dlehn, +1.703.628.aabb, omalik, Ian, halmas, dezell, jean-yves, Dsr, Laurent_ Present: Manu Omar Jean-Yves Laurent Dave_Longley Hassan David_Lehn David_Ezell Ian Dave_Raggett Regrets: wseltzer Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Feb/0050.html Got date from IRC log name: 26 Feb 2015 Guessing minutes URL: http://www.w3.org/2015/02/26-wpay-minutes.html People with action items: ian manu WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]