RE: 答复: need reason description for exclusion of UseCase v1

In summary – the standard would not “hard code” a selection process. The use case below specific to China is just that – specific to a regulatory and country preference framework. The standard should be focused on the interactions and the process flow – with the ability for specifics like this to adjust how the standard is implemented. Quite common for standards to be adjusted. This topic also arises in the unique flow and requirements of the Boleto in Brazil. Or G3 payments in Singapore, or … a myriad of other direct implementations based on standards. So maybe we should assume that specific geo-based, regulatory, or other needs will adjust the implementation – but not really adjust the standard. Does this help?

 

-- 
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: Joseph Potvin [mailto:jpotvin@opman.ca] 
Sent: Wednesday, June 24, 2015 8:27 AM
To: Web Payments IG
Cc: 茱滴
Subject: Re: 答复: need reason description for exclusion of UseCase v1

 

Consider these two scenarios:

1. Digital Bazaar buys a device from Alibaba's, via Alibaba's retail sales website. 

2. Digital Bazaar sells system design services to Alibaba, via Alibaba's corporate procurement website.

In both cases, will it not be the company with greater market power which first determines which payment instruments are presented for selection?  

While B2P is going to almost always involve the B (payee) selecting the set of available instruments, this is not a reliable assumption in B2B, G2B, B2G or G2G scenaros.

Nor is it clear why it would be necessary or advantageous to "hard code" into a generic specification such an assumption about which party, the payee or payer, would initiate the selection of acceptable payment instruments.




Joseph Potvin
On behalf of DataKinetics 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 Wed, Jun 24, 2015 at 4:25 AM, 段超(泰麒) <HYPERLINK "mailto:zephyr.dc@alibaba-inc.com"zephyr.dc@alibaba-inc.com> wrote:

Hi,

The ubiquitous web payment scenario in China is:

1.       payee(supplying products or services, and collecting money at last) which we called merchant gets the payer’s payment request(maybe includes products’ or services’ name, id, price, count, etc.), and then transmit the request to escrow. In this process, payee only pass the information of the products or services which payer wants to buy to escrow.

2.       Then payee’s web or app will jump to escrow’s page or app. Escrow gets these information , and show payer which schemes and instruments are available.

3.       Payer chooses scheme and instrument which escrow offered, and then pay the money to escrow.

4.       Payee and escrow will consult with a settlement time at first(maybe every day’s 24:00). At that time, escrow will transfer the money to payee which payer has paid.

During the process, payee don’t know any privacy information of the payer. What payee has to care about is only stuffs about products or services which they supplied.

Moreover, escrow was the one dealt with payer’s privacy information and transfer money between payee and payer. So we have to make escrow compliance. Because of this, The People’s Bank of China has worked out several standards to normalize numerous escrows.

 

About the issue of “wallets”, we usually call it virtual account. Because there are some app products named with “… wallet”, to avoid of  confusion we don’t use “wallet” as a terminology. However, we use “e-wallet”  as a payment scheme which is using in near field payment with IC card.

 

Above is the current situation in China, I hope these will be a little help  to you.  : )

 

 

段超 (泰麒) 

Zephyr Tuan

集团安全部_标准化与安全新技术

Corporation security_standardization and new security research

 

发件人: Mountie Lee [mailto:HYPERLINK "mailto:mountie@paygate.net"mountie@paygate.net] 
发送时间: 2015年6月24日 7:50
收件人: Adrian Hope-Bailie
抄送: Manu Sporny; HYPERLINK "mailto:public-webpayments-ig@w3.org"public-webpayments-ig@w3.org
主题: Re: need reason description for exclusion of UseCase v1

 

Hi.

 

the first image for "Discovery" was

wallet (or payment agent) will discover the available schemes and instruments.

but in the definition of Discovery of User Cases (http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#selection-of-payment-instruments)

describing discovery across the multiple digital wallets (on mobile phone, in the cloud and on smart watch).

 

with this understanding,

the wallet will discover available schemes and instruments across the multiple digital wallets.

 

but it is not possible with current web technologies.

 

that is the reason I asked "who discover".

 

regards

mountie.

 

 

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

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

 





 

-- 

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