RE: need reason description for exclusion of UseCase v1

Precisely Dave – the wallet – or any other initiating function is not the start of the payments process much like there is no need of a “receipt” or “invoice” to mark it’s end.  Agreed.

 

-- 
HYPERLINK "http://www.oracle.com/"Oracle
David Jackson | Senior Director Financial Services
Mobile: HYPERLINK "tel:+16145601237"+1.614.560.1237 | VOIP: HYPERLINK "tel:+16144656654"+1.614.465.6654 
Oracle Industry Solutions Group
New York City | Columbus 

HYPERLINK "http://www.oracle.com/commitment"Green Oracle

Oracle is committed to developing practices and products that help protect the environment

 

 

From: Dave Raggett [mailto:dsr@w3.org] 
Sent: Tuesday, June 23, 2015 3:11 PM
To: Adrian Hope-Bailie
Cc: Joseph Potvin; public-webpayments-ig@w3.org
Subject: Re: need reason description for exclusion of UseCase v1

 

In my talk [1], I was careful to avoid the term wallet given that people differ in what they think it means, and instead referred to the roles for specific tasks, e.g. selection agent, receipt agent and payment instrument.  For V1, we can ignore the receipt agent, and just talk about the selection agent and payment instrument.   We can leave “wallet” until later, and I expect that when we want to allow one agent to performs multiple roles, then we want indeed want to try to use the term wallet for such agents.

 

[1] HYPERLINK "https://www.w3.org/Payments/IG/wiki/images/e/ea/Implementation-considerations.pdf"Dave Raggett's Slides

 

On 23 Jun 2015, at 19:42, Adrian Hope-Bailie <HYPERLINK "mailto:adrian@hopebailie.com"adrian@hopebailie.com> wrote:

 

No, in this context we are talking of a wallet as a service that aggregates payments schemes and instruments (in the same way that your physical wallet holds all your cards).

I asked the question explicitly in the meeting and my understanding is that we will define a wallet this way (as opposed to simply a synonym for account).

 

On 23 June 2015 at 20:34, Joseph Potvin <HYPERLINK "mailto:jpotvin@opman.ca"jpotvin@opman.ca> wrote:

RE: "what if the payer or payee does not use any “wallet”?"

 

"Wallet" and "account" are functional synonyms.

 




Joseph Potvin
On behalf of DataKinetics HYPERLINK "http://www.dkl.com/"http://www.dkl.com
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
HYPERLINK "mailto:jpotvin@opman.ca"jpotvin@opman.ca
Mobile: HYPERLINK "tel:819-593-5983"819-593-5983

 

On Tue, Jun 23, 2015 at 2:25 PM, Adrian Hope-Bailie <HYPERLINK "mailto:adrian@hopebailie.com"adrian@hopebailie.com> wrote:

My expectation is that the browser vendors will build a default "wallet" into the browser so that if user's want to register payment schemes or instruments they can do so without installing a stand-alone "wallet".

When they do install a "wallet" the browser should then pass all the payment requests to this instead of handling them directly.

 

On 23 June 2015 at 14:19, Leandro Bernal Minniti <HYPERLINK "mailto:Leandro.minniti@cip-bancos.org.br"Leandro.minniti@cip-bancos.org.br> wrote:

Hello Adrian,

 

Are we considering that the merchants/e-commerces will be always using a wallet solution? I mean, what if the payer or payee does not user any “wallet”?

 

Thanks,

Leandro.

 

De: Adrian Hope-Bailie [mailto:HYPERLINK "mailto:adrian@hopebailie.com"adrian@hopebailie.com] 
Enviada em: terça-feira, 23 de junho de 2015 06:29
Para: Mountie Lee
Cc: Manu Sporny; HYPERLINK "mailto:public-webpayments-ig@w3.org"public-webpayments-ig@w3.org
Assunto: Re: need reason description for exclusion of UseCase v1

 

Hi Mountie,

This is the same "confusion" Dave highlighted regarding the word discover.

There are 4 steps that must be completed before we have a final selection of payment scheme and instrument to begin processing a payment.

1. Registration: The user (over time) will register one or more payment schemes and instruments that they have and wish to use to make payments. They will configure how these must be used and set default parameters for their use. My understanding is that the current proposal is for this process to be IN SCOPE but not necessarily REQUIRED by the browsers themselves. i.e. The most likely scenario is that the browser allows the configuration of a "wallet" and the wallet itself is responsible for managing the various schemes and instruments.

2. Request for Payment: The web application (of the payee/merchant) makes a request to a browser API to perform a payment. In this request the payee provides a list of payment schemes and instruments that they will accept for payment (and possibly even different payment terms for each such as a different amount and currency).

3. Discovery: This step is the one causing the confusion because I think it is not clear who does the discovery. My understanding from the F2F is that this will be done by the "wallet". The browser will pass the payment request to the "wallet" and the wallet will use an algorithm to match the supported schemes and instruments from the payee with the registered schemes and instruments from the payer.

4. Selection: After discovery there should be a list of at least one payment scheme and instrument that is both supported by the payee and registered by the payer. If there are more than 1 then the user must be prompted to select the one they wish to use or the user may have configured the wallet to auto-select the one that will cost the least and then order by preference.

Following these 4 steps we can now prompt the user to confirm the transaction and then proceed.

Adrian

 

On 23 June 2015 at 08:18, Mountie Lee <HYPERLINK "mailto:mountie@paygate.net"mountie@paygate.net> wrote:

Hi.

I have a question for usecase v1

 

Discovery at Selection of Payment Instruments (http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#selection-of-payment-instruments)

 

I'm not sure who discover

maybe user will select payment instrument across the multiple wallets.

but who discover the wallets?

by mercahnt(payee)?

 

regards

mountie

 

 

On Mon, Jun 22, 2015 at 11:28 AM, Manu Sporny <HYPERLINK "mailto:msporny@digitalbazaar.com"msporny@digitalbazaar.com> wrote:

On 06/21/2015 12:08 PM, Mountie Lee wrote:
> I found it at
> https://www.w3.org/Payments/IG/wiki/Payment_Architecture_Priorities

That link above was mostly an attempt at organizing the existing use
cases into versions. I wouldn't suggest that anyone take it as anything
more than an educated guess on how each use case we have today could be
organized into versions.

This is the final list of use cases for version 1:

https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_June2015/UseCasesForVersion1

The only use case that was dropped from version 1 was the Credentials
use case, primarily because there wasn't a belief that it was critical
path for version 1.

That said, the breakout session on use cases found that while
Credentials wasn't critical path for version 1, that a Credentials WG
should be created in parallel primarily due to  demand for a better way
of doing KYC/AML across the financial industry. I think the feedback
from the roundtable underscored this desire.

The rest of the feedback will be integrated into the use case
descriptions this week. For each use case, the roadmap will clarify if
only a subset of a use case for version 1 is expected to be implemented
(electronic receipts, for example, is only supposed to have very minimal
support in version 1).

Mountie, are you asking that we document /every/ use case that wasn't
selected for version 1, or just the use cases that were considered and
then removed for version 1?

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Web Payments: The Architect, the Sage, and the Moral Voice
https://manu.sporny.org/2015/payments-collaboration/





 

-- 

Mountie Lee

PayGate

CTO, CISSP
Tel : HYPERLINK "tel:%2B82%202%202140%202700"+82 2 2140 2700
E-Mail : HYPERLINK "mailto:mountie@paygate.net"mountie@paygate.net

 

Aviso de confidencialidade: Esta comunicação deve ser lida apenas pelo seu destinatário e não pode ser retransmitida sem autorização formal. Se esta mensagem tiver sido recebida indevidamente, por favor, deve destruí-la e eliminá-la de seu computador. Qualquer reprodução, disseminação, alteração, distribuição e/ou publicação deste e-mail é estritamente proibido. 
 
Notice of Confidentiality: This document should only be read by those persons to whom it is addressed and is not intended to be retransmitted by any person without subsequent written confirmation of its contents. If you have received this e-mail message in error, please destroy it and delete it from your computer. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message is strictly prohibited.
 
Atención: Esta comunicación debe ser leída solo por su destinatario y no puede reencaminarse sin autorización formal. Si este mensaje ha sido recibido indebidamente, por favor, ignórelo y elimínelo del ordenador. Cualquier reproducción, difusión, alteración, distribución y/o publicación de este e-mail queda terminantemente prohibida.
---------------------------------------------------------------------------------------------------------------------------------------------

 

 

 

 

—

   Dave Raggett <HYPERLINK "mailto:dsr@w3.org"dsr@w3.org>