Web Payments IG: Use Cases Task Force -- 26 Feb 2015

<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

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.

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]

- DRAFT -

Web Payments IG: Use Cases Task Force
26 Feb 2015

Attendees

Contents

Organizing Web Payments Use Cases

Number of flows and phases

Number of Phases/Flow

Exposing the rules of a payment scheme

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

Web Payments IG: Use Cases Task Force 26 Feb 2015

Attendees

Contents

Organizing Web Payments Use Cases

Number of flows and phases

Number of Phases/Flow

Exposing the rules of a payment scheme

Summary of Action Items

Scribe.perl diagnostic output

Web Payments IG: Use Cases Task Force
26 Feb 2015