RE: [use_cases] Proposed framework for organizing use cases

SLIDE 17:
P2: Authorization of Transfer
1. Proof of Payment
2. Immediate Access to Funds
3. Proof of Funds being Escrowed
4. Proof of Funds Tramission by Payment Network
5. Regulatory checks / reporting


Number 5 on slide 17, is important for several reason. I am wondering if this numbered list is relative to the-order-of-events, or is it just a list?

One scenario from a government perspective that comes to mind (Pat please weigh-in on this), is where the government put a hold/stop on a user's funds, for various reasons (failure to pay child support, money laundering, tax fraud, etc). 

I am not advocating that the specs support this or not, I am just wondering, if number 5 intends to include that? So it is not just about regulations-in-force but also regulatory/legislative court-actions-in-force.

Secondly, if # 5 is an in-order list, is this the correct location?

* katie *
 
Katie Haritos-Shea 
Senior Accessibility SME (WCAG/Section 508/ADA/AODA)
 
Cell: 703-371-5545 | ryladog@gmail.com | Oakton, VA | LinkedIn Profile | Office: 703-371-5545

-----Original Message-----
From: Ian Jacobs [mailto:ij@w3.org] 
Sent: Thursday, February 26, 2015 11:00 AM
To: Castillo Laurent
Cc: Manu Sporny; public-webpayments-ig@w3.org
Subject: Re: [use_cases] Proposed framework for organizing use cases


> On Feb 26, 2015, at 5:37 AM, Castillo Laurent <Laurent.Castillo@gemalto.com> wrote:

> Hi Manu et  all,
> 
> I fully agree that the slide discussion should be number one. You 
> might want to catch Evert since it looks a lot like his "purchase 
> steps" document he wanted to produce. It's a great start to a scoping 
> discussion.
> 
> Because I'm not sure I'll have a good phone connection tonight, here 
> are my comments by mail.

Thanks for the careful review and comments, Laurent.

Here’s a quickie summary of key points to discuss on the call (fleshed out below):

 1. One flow description or multiple?
 2. For Person-to-Business, 3 phases or 4?

> Slide 1-4: good intro, I'd explecitely state in slide 3 that a goal is 
> to define the IG/WG work scope.

Would it be ok if instead I talk about scope in terms of the use cases (rather than the framework for organizing them)? Thus, I would say:

 "This a proposed framework for organizing the material in the Web  Payments Use Cases Draft, which will help establish the scope of work  for the Web Payments Interest Group."
 
> Slide 5:
> 
> - These three phases are describing more "Person to Business" type of
>   flows, they put implicitly out of scope "Business to Person" flows
>   (like recurring transfers and co...), and only apply to "Person to
>   Person" in weird way. I'd suggest having a section "Phases" for each
>   main flow category (or explicitly stating we focus on "Person to
>   Business").

This is an important topic. In my ideal world, we can do everything with one simple flow description. I can imagine several scenarios:

 1. It's really easy to describe all flows the same way.
 2. If you craft the flow carefully and don't try to include tricky edge cases, you
    can use a single description for all the flows we expect to be focusing on.
 3. The flows are sufficiently different, or the mindsets of the readers are sufficiently
    different, that trying to come up with a single flow will result in something contorted
    that speaks to nobody. In this case we should content ourselves with multiple
    flow descriptions (and each one may have different phases, steps, etc.).

My hope was that we could accomplish 2. I am hearing you suggest that 3. may be easier or more effective. Is that what you intend?

> - The phases describe more what we called the Purchase in the F2F than
>   the Payment (which is a small part of it). 

Manu and I had a discussion about what term to use (Payment, Purchase, Transaction, etc.).  So this, too is an important topic where we need to get consensus.

>  I'd suggest four phases rather than three:
> 
>        1. Payer Initiates Purchase => nobody will argue that the
>        Merchant initiates a purchase (except for bad practices :))
>        2. Payer or Payee triggers Payment => We could say Payer
>        triggers Payment only if we explicitly refer to the user action
>        (and not the Processor trigger, which can be on either side)
>        3. Payee Receives Payment
>        4. Payer Receives Purchased Product/Receipt

I was going to ask what steps you would put in the phases, but I see you speak to that below.

> Slide 6: SEPA has the same issue, so saying ACH & SEPA would make us 
> just first-world centric instead of US centric...

Good point; added SEPA.

(Great point generally: I welcome comments on how to make sure our communications speak to as many jurisdictions as we can.)

> Slide 7:
> 
> - I'd stop this phase ("Initiates Purchase" in my proposal) at
>   "Agreement on Terms", and add another phase about applying loyalty /
>   couponing and payment facilities (is that the right word?) to the
>   purchase.
> 
> - I'd then create a new slide for "Triggering Payment" with:
> 
>        * Discovery of Payment Instruments: discovery of Payer's
>          available payment instruments, acceptable by the Payee.
>                => Let's make discovery explicit since it's critical in our work.
>        * Selection of Payment Instrument: Payer selects one or more payment instruments.
>                => Should be noted this selection could be done either
>                in the merchant scope (ie the merchant web page) or the
>                payer's scope (ie the payment agent
>        * Authorization to Access Instruments: Payer is authenticated then consents to pay.
>                => authenticated is probably better than authorized here.

Thanks for the very concrete proposal. I will look for support from others for your suggestions.

> Slide 8:
> 
> - Verification of Available Funds: "Payee may need" rather than
>   "request" since it can receive the proof of funds from its own
>   processor or from the payer's processor.

Done.

> - Authorization of Transfer: "Payee receives proof" rather than
>   "notification", since it's not necessarily a notification (it can be
>   bundled in prrof of fund for instance).

Done.

> - Funds Transferred: we might want to add that it can also be
>   initiated in multiple ways (merchant, payer's processor, acquiring
>   or issuing banks, etc...)

Added. Bullet now reads:
 
 "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 intervals  will vary from nearly immediately to several days."
 
> Slide 11: An alternative approach once we have the flow steps agreed 
> on is to have one use case be a detailed example of a full flow.

> For instance "I want to buy a book on mylibrary.com and I have a 
> mobile wallet with a credit card and a bitcoin wallet..." all the way 
> to "I receive the receipt in my mobile wallet".

Here's a way I could see doing that in the use cases document (this is just a sketch to give the idea):

 * Document starts by introducing this framework.
 * Then use cases are organized according to framework
 * Appendix 1: Different Payment Schemes in the Framework
 * Appendix 2: A very common story illustrated by piecing together
   the applicable use cases with details filled in for that story.
 
> Slides 12-19: Haven't reviewed them all, but just scanning I don't 
> understand if it's a start for describing use cases or a mapping of 
> our current use cases to new classification (looks like a mix of 
> both).

It is probably a mix of both, but the primary intent was mapping.

> Slides 22-23: As mentioned, Person to Person looks more like a full 
> new category. Refunds don't fit in the Purchase flow, it's more an 
> exception / edge case.

+1 to discuss whether to break out multiple flows.

Thanks again,

Ian

--
Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
Tel:                       +1 718 260 9447

Received on Thursday, 26 February 2015 17:14:35 UTC