RE: [use_cases] Proposed framework for organizing use cases

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.

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

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").
- The phases describe more what we called the Purchase in the F2F than the Payment (which is a small part of it). 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

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

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.

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.
- 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).
- 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...)

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".

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).

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.

Cheers
Laurent
________________________________
 This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

Received on Thursday, 26 February 2015 11:37:57 UTC