[use cases] Proposal for some additions

Hi All,


Here are some proposed changes on the current document (to prepare for introducing pull model use cases), to be discussed tonight if possible.

I also have some detailed review of the use cases in progress, which starts to look like a wall of text, so I was wondering what's the best way to submit it: in one big block by email or one per use cases??


1.       Push vs Pull payments flows (or Payer vs Payee-initiated payments)

This distinction is fundamental, maybe we can put it in a separate section at the beginning, since it's going to be referenced everywhere.

High level view of the flows
Push flow (a.k.a. payer-initiated):
Merchant->Payment Agent: payment request with merchant id
Payment Agent->Payment Processor: pay order
Payment Agent->Merchant: proof of payment (including proof guaranteeing funds have been / will be transferred, with user consent)

Pull flow: (a.k.a. payee-initiated):
Merchant->Payment Agent: payment request
Payment Agent->Merchant: proof of consent/instrument (including financial instrument id, payment instrument is valid and user has given consent)
Merchant->Processor: pay order

Main difference for me is the type of proof received from Payment Agent to Merchant: in one case (push model), the merchant needs a full payment proof (that includes guarantee that funds will be or have been transferred); in the other (pull), it "only" needs proof of consent and proof of validity of the payment instrument (the merchant will get the proof of payment directly from its processor in that model).


2.       Addition of a definition for payment schemes (or any other names we agree on).

Here's an example taken from SEPA that could easily be adapted: http://www.europeanpaymentscouncil.eu/index.cfm/sepa-customers/what-is-a-payment-scheme/
Sic: "The Single Euro Payments Area (SEPA) payment schemes as defined in the SEPA Credit Transfer (SCT) and SEPA Direct Debit (SDD) Rulebooks contain sets of rules and technical standards for the execution of SEPA payment transactions that have to be followed by adhering payment service providers."

I suggest the following definition: Sets of rules and technical standards for the execution of payment transactions that have to be followed by adhering entities (processors, payer and payees).

As a background discussion point, here are the elements in the scope of W3C Web Payments that are IMO highly dependent on the payment scheme:

-          Payment flow supported (push or pull)

-          Cryptographic content of a proof of payment / proof of consent

-          Supported Payer's payment instruments (and corresponding authentication means, credentials used and financial identity formats)

-          Regulations...

Rgds
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.
________________________________
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