Re: [use cases] Proposal for some additions

+10 to Laurent
I would also suggest to add HCE which is somehow something in the middle 
(the user does ask is provider to give a one-time token, but the 
merchant pull the money)

steph
Le 12/02/2015 12:44, Castillo Laurent a écrit :
> 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

-- 
Stephane Boyera        stephane@w3.org
W3C                +33 (0) 6 73 84 87 27
BP 93
F-06902 Sophia Antipolis Cedex,
France

Received on Friday, 13 February 2015 06:39:44 UTC