- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 26 Feb 2015 15:31:15 -0500
- To: Web Payments IG <public-webpayments-ig@w3.org>
The minutes for today's Web Payments IG Use Cases Task Force telecon can
be found here:
http://www.w3.org/2015/02/26-wpay-minutes.html
Full text of the meeting follows:
--------------------------------------------------------------------
Present: Manu, Omar, Jean-Yves, Laurent, Dave_Longley, Hassan,
David_Lehn, David_Ezell, Ian, Dave_Raggett
Regrets: wseltzer
Scribe: manu
Topics
1. Organizing Web Payments Use Cases
2. Number of Phases/Flow
3. Exposing the rules of a payment scheme
Summary of Action Items
[NEW] ACTION: Ian to revise the presentation based on discussion today
and email comments.
[NEW] ACTION: Manu to integrate Ian's revised presentation into Web
Payments IG Use Cases introductory section.
<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?
Organizing Web Payments Use Cases
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
<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.
Number of flows and phases
Number of Phases/Flow
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
Exposing the rules of a payment scheme
<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]
Received on Thursday, 26 February 2015 20:31:42 UTC