Re: [use_cases] Proposed framework for organizing use cases

> On Mar 4, 2015, at 10:27 AM, Telford-Reed, Nick <Nick.Telford-Reed@worldpay.com> wrote:
> 
> Playing catch up here - I think that establishing the identity of the parties to the payment transaction and establishing the trust between the parties as a function of transaction value and identity assurance are an intrinsic part of the process. The negotiation of the instrument is strongly influenced by this trust level. For example, many people will use a credit card for large value transaction online precisely because of the chargeback protection which results - this is especially true where the counter-party (payee/merchant/supplier) is not well known to the consumer.
> 
> Unless I'm missing something, this isn't currently reflected.
> 
> Tl;dr - it's not just the identity of the payer that is established


Thank you, Nick. That sounds appropriate.

Do you have concrete suggestions for the slides? I can think of a couple of ways to introduce
this:

 * On slide 10 there is a step “Authentication to Access Instruments”. Is that the moment when both parties are
   identified to the payment instrument issuer?  For example, is data sent by the Payee at this stage?

 * On slide 10 there is a step “Initiation of Processing”. Is that when the information is exchanged?

 * Or is there a step missing?

If this exchange can happen at a variety of moments, can we pick “the most common” moment for the simple flow?

Thanks!

Ian


[1] http://www.w3.org/2015/Talks/ij-usecases/?full#10
> 
> Nick
> 
> --
> Nick Telford-Reed
> e: nick.telford-reed@worldpay.com | m: +447799473854 | t: +44 203 664 5069
> 
>> -----Original Message-----
>> From: Ian Jacobs [mailto:ij@w3.org]
>> Sent: 26 February 2015 23:19
>> To: Katie Haritos-Shea GMAIL
>> Cc: Castillo Laurent; Manu Sporny; public-webpayments-ig@w3.org
>> Subject: Re: [use_cases] Proposed framework for organizing use cases
>> 
>> 
>>> On Feb 26, 2015, at 11:14 AM, Katie Haritos-Shea GMAIL
>> <ryladog@gmail.com> wrote:
>>> 
>>> 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?
>> 
>> It’s just a list. I used <ol> to be able to do counting, but this is not meant to
>> propose an order for the use cases document.
>> 
>>> 
>>> 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.
>> 
>> On slide 5 we included a comment:
>> 
>> "The phases may be interrupted at various times (e.g., one party drops out,
>> or exceptions occur like insufficient funds or a regulatory block).”
>> 
>> It sounds like the use cases you describe fall under “regulatory block.” My
>> proposal is that the framework (as an introduction) not itself have to expose
>> these sorts of events.
>> 
>> However, the use cases themselves could very well do so.
>> 
>> So it will be up to the IG to decide whether that use case appears in the
>> FPWD, etc.
>> 
>>> 
>>> Secondly, if # 5 is an in-order list, is this the correct location?
>> 
>> The location was arbitrary. :)
>> 
>> Ian
>> 
>> 
>>> 
>>> * 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> --
>> Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
>> Tel:                       +1 718 260 9447
>> 
>> 
>> 
> 
> This e-mail and any attachments are confidential, intended only for the addressee and may be privileged. If you have received this e-mail in error, please notify the sender immediately and delete it. Any content that does not relate to the business of Worldpay is personal to the sender and not authorised or endorsed by Worldpay. Worldpay does not accept responsibility for viruses or any loss or damage arising from transmission or access.
> 
> Worldpay (UK) Limited (Company No: 07316500/ Financial Conduct Authority No: 530923), Worldpay Limited (Company No:03424752 / Financial Conduct Authority No: 504504), Worldpay AP Limited (Company No: 05593466 / Financial Conduct Authority No: 502597). Registered Office: The Walbrook Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial Conduct Authority under the Payment Service Regulations 2009 for the provision of payment services. Worldpay (UK) Limited is authorised and regulated by the Financial Conduct Authority for consumer credit activities. Worldpay B.V. (WPBV) has its registered office in Amsterdam, the Netherlands (Handelsregister KvK no. 60494344). WPBV holds a licence from and is included in the register kept by De Nederlandsche Bank, which registration can be consulted through www.dnb.nl. Worldpay, the logo and any associated brand names are trade marks of the Worldpay group.

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

Received on Thursday, 5 March 2015 13:26:21 UTC