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

Let me suggest a general framing of the issue as involving the following
two approaches:

A: The specification incorporates an assumption that the Payee role would
present a set of acceptable payment instrument choices to the Payer;

B: The specification incorporates the flexibilty that either the Payee or
the Payer role would present a set of acceptable payment instrument choices
to the other party.



RE: "The use case below specific to China is just that – specific to a
regulatory and country preference framework."

The illustration was intended to portray dealings between any "large" firm
and any "small" firm. Instead of "Alibaba" I could have said "Target" or
"Carrefour" and the relationship would be consistent: the larger firm in
both Payee and Payer roles typically establishes the set of acceptable
payment instrument choices.


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

On Wed, Jun 24, 2015 at 9:19 AM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> For privacy reasons we have assumed that the payee will always initiate by
> presenting the set of options they are prepared to accept. This is
> identical to almost all use cases today where a payer arrives on a
> "checkout" or "payment" screen and must select the way they wish to pay.
>
> There is no way of getting around this while preserving the privacy of the
> payer other than to assume an existing relationship between payer and payee
> in which this set of options was already negotiated and is now presented in
> the context of a specific payment request.
>
> I believe your second use case above would likely fit into this scenario.
>
> Bare in mind that the payee exercises their market power in determining
> which options to present the payer. If the payee has significant power they
> will present a limited set that suits their needs on the assumption that
> the payer will have to accept one of these. If the payer has the market
> power the payee will likely present a large set of options hoping that the
> payer will be prepared to use one of them.
>
> On 24 June 2015 at 14:26, Joseph Potvin <jpotvin@opman.ca> wrote:
>
>> 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
>> jpotvin@opman.ca
>> Mobile: 819-593-5983
>>
>> On Wed, Jun 24, 2015 at 4:25 AM, 段超(泰麒) <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:mountie@paygate.net]
>>> *发送时间:* 2015年6月24日 7:50
>>> *收件人:* Adrian Hope-Bailie
>>> *抄送:* Manu Sporny; 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 <
>>> 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 <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 <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 : +82 2 2140 2700
>>> E-Mail : mountie@paygate.net
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Mountie Lee
>>>
>>> PayGate
>>>
>>> CTO, CISSP
>>> Tel : +82 2 2140 2700
>>> E-Mail : mountie@paygate.net
>>>
>>
>>
>