[USE CASES] Payer advertised instruments, escrow etc

[moving to uses cases per the chairman's request]

Apologies for being out of the loop a few days, rather than comment on each
mail thus far I want to make a few general comments.

A lot of the discussion is revolving around a) the initiator of the payment
instrument selection and use cases where it is believed the current
proposal will fall short and b) consideration of external standards such as
ISO20022.

Regarding a) I put it to the group that a simple flow beginning with a
payment initiation request from the payee to the payer, followed by a
payment initiation response, followed further by a payment completion
request from the payee to the payer and finally a payment completion
response from the payer to the payee is sufficient to handle almost any use
case and can be leveraged by all of the payment schemes I am aware of today
to achieve their ends.

In this flow I anticipate that the browser will act as a proxy for these
requests and responses and that some "wallet" service will act on behalf of
the payer. In this context a "wallet" is a digital representation of a
physical wallet, holding payment instruments, value (cash-like) and any
other data or configuration required to perform the functions it must
perform (detailed a little more below).


Anything outside of this flow (*or that occurs out of band*) is out of
scope of the standard.

Example Credit Push:


   1. Buyer is on eCommerce website and selects "Pay".
   2. eCommerce site sends payment initiation request to browser via
   browser API.
   3. Req contains payment details and lists available payment methods.
   4. Browser passes req to "wallet" which performs discovery of payment
   instruments available to make payment and either a) select the best one OR
   b) suggests a set to the payer who select their preferred one. (NOTE: The
   discovery algorithm and wallet behaviour is not standardised only the
   format of the request)
   5. A push payment method (e.g. Bitcoin) is selected and the wallet (with
   user authentication if required - scheme dependent) performs any
   pre-payment checks the scheme specifies (e.g. funds availability)
   6. The wallet, via the browser, returns the payment initiation response
   to the payee. The payee verifies it and ensures all is in order.
   7. The payee (eCommerce site) sends payment completion request to
   browser via browser API requesting the payer to execute the payment.
   8. Payer "wallet" gets completion request, executes payment (likely with
   user mediation of some form, could be biometric auth, could be anything)
   and returns payment completion response to eCommerce site.
   9. eCommerce site finds scheme-specific payment proof in response or has
   out of band mechanism to verify payment and redirects user to "Thank You"
   page.


Example Debit Pull:


   1. Buyer is on eCommerce website and selects "Pay".
   2. eCommerce site sends payment initiation request to browser via
   browser API.
   3. Req contains payment details and lists available payment methods.
   4. Browser passes req to "wallet" which performs discovery of payment
   instruments available to make payment and either a) select the best one OR
   b) suggests a set to the payer who select their preferred one. (NOTE: The
   discovery algorithm and wallet behaviour is not standardised only the
   format of the request)
   5. A pull payment method (e.g. VISA credit card) is selected and the
   wallet (with user authentication if required - scheme dependent) performs
   any pre-payment checks the scheme specifies (e.g. get one-time use card
   token) and packages the credentials required by the payee to execute the
   payment in a form defined by the payment scheme.
   6. The wallet, via the browser, returns the payment initiation response
   to the payee (including the specially packaged payment credentials).
   7. The payee uses the credentials to execute the payment (and since the
   payee is now in control of the flow can pop-up a 3DS page for the user to
   perform 3DS if required by their issuer - likely not required if
   tokenisation is being used)
   8. The payee (eCommerce site) sends payment completion request to
   browser via browser API informing the payer that the payment has been
   executed.
   9. Payer "wallet" gets completion request, records the outcome and
   returns a completion response.
   10. eCommerce site redirects user to "Thank You" page.

Example Debit Pull:


   1. Buyer is on eCommerce website and selects "Pay".
   2. eCommerce site sends payment initiation request to browser via
   browser API.
   3. Req contains payment details and lists available payment methods.
   4. Browser passes req to "wallet" which performs discovery of payment
   instruments available to make payment and either a) select the best one OR
   b) suggests a set to the payer who select their preferred one. (NOTE: The
   discovery algorithm and wallet behaviour is not standardised only the
   format of the request)
   5. An escrow based payment method via mutually accepted escrow service
   is selected and the wallet (with user authentication if required - scheme
   dependent) performs any pre-payment checks the scheme specifies.
   6. The wallet, via the browser, returns the payment initiation response
   to the payee. The payee verifies it and ensures all is in order.
   7. The payee (eCommerce site) sends payment completion request to
   browser via browser API requesting the payer to execute the payment.
   8. Payer "wallet" gets completion request, executes payment into escrow
   service account (likely with user mediation of some form, could be
   biometric auth, could be anything) and returns payment completion response
   to eCommerce site.
   9. eCommerce site finds scheme-specific payment proof in response or has
   out of band mechanism to verify payment to escrow service and redirects
   user to "Thank You" page.

In the case of escrow or any scheme that does not require immediate payment
the flow would be the same but the seller would not release the goods yet.
This flow would serve as a confirmation of terms and establishment of a
reference for the transaction. All other interactions would be out of band
of this flow and out of scope.

Some notes:

   - Wallets: Following the mass confusion that has been caused by trying
   to avoid the word wallet I am now +1 for using the word and defining it
   properly. That is another thread on it's own.
   - Authentication of user's to their payment scheme is out of scope of
   this standard, it is up to the scheme, wallet and user to define these.
   Some wallets will be capable of sophisticated auth such as biometrics
   others will not. Where payment schemes have rigorous security requirements
   it will be challenging for wallets to support those schemes therefor the
   standard should make efforts to avoid schemes being able to lock out
   wallets although this may be outside the scope of work of the W3C). One
   possible work-around is enforcement of aggregation capabilities so that
   wallets that are closed can simply be wrapped into more open wallets if
   users wish to have both.
   - The execution of a payment (in the case of push payments) or packaging
   of payment credentials (in the case of pull payments) is also scheme
   specific and will need to be implemented by wallets as required by each of
   the schemes they wish to support.
   - In the case that the payer wishes to advertise their available schemes
   this can be achieved in this same flow by presenting these in the payment
   initiation response although I don't see a use case for this in the v1 use
   cases OR in the case that the website is actually operated by the buyer not
   the seller the same flow is appropriate only the schemes that will be used
   will support a flow of funds in the opposite direction. (payment init req =
   "I can pay you these ways", payment init resp = "please pay me this way",
   payment completion req = "payment done, here is proof OR here are the
   credentials you need to get paid", payment completion res = "thanks, all
   done here")










On 25 June 2015 at 17:40, Joseph Potvin <jpotvin@opman.ca> wrote:

> RE: "C: the specification incorporates the flexibility that the 3rd party
> platform would present the set of acceptable payment instrument choices to
> either party."
>
> This issue was central to my written submission to the April 2014 W3C
> meeting on web payments. This paper was entitled: "Restricted vs Free
> Market Pricing in Web Payments"
> http://www.w3.org/2013/10/payments/papers/webpayments2014_submission_24.pdf
>
> In my presentation deck at the meeting, I illustrated that how a "3rd
> party platform would present the set of acceptable payment instrument
> choices", using screenshots from my own PayPal purchase of the buffet
> ticket for that W3C meeting.
> http://www.w3.org/2013/10/payments/slides/session4_potvin.pdf
>
> My paper opened up the issue as follows:
>
>
>
> *"From its inception a W3C specification on web payments may adopt one the
> following positions with regard to the roles of buyers, sellers and payment
> intermediaries (systems or roles): (a) The specification may explicitly or
> implicitly leave out-of-scope the issue of whether or not payment
> intermediaries may constrain access to knowledge and choice amongst buyers
> and sellers...; (b) The specification may explicitly identify the criteria,
> methods and processes by which payment intermediaries may legitimately
> constrain access to knowledge and choice amongst buyers and sellers...; or,
> (c) The specification may explicitly identify the general and inalienable
> right of buyers and sellers to unencumbered knowledge and choice..."*
>
> At this point, I suggest to table this set of options again, with the
> clarification that every legal juridiction may of couse set its own rules
> for what sellers, buyers and financial intermediaries each may and may not
> have the authority to determine in the course of transactions that come
> within that jurisdiction's scope of governance.
>
> It seems to me that a W3C specification is not the place to presuppose the
> rules of any particular jurisdiction about what the relative prerogatives
> of sellers, buyers and financial intermediaries to determine payment
> attributes.
>
> In general, seeking to ensure that the W3C spec on web payment is premised
> upon a global legal context for web payments, I've been recommending that
> sources such as UNCITRAL Model Laws, BIS Principles and UNIDROIT Principles
> be used as the core sources for guidance. Such sources function like
> Rosetta Stones for these matters across all jurisdictions (and I should
> add, can accommodate the new generation of 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 11:47 PM, 茱滴 <hongru.zhr@alibaba-inc.com> wrote:
>
>> 1.       As for “
>>
>> 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.
>>
>>
>>
>> Actually it should add another \
>>
>>
>>
>> * C: the specification incorporates the flexibility that the 3rd party
>> platform would present the set of acceptable payment instrument choices to
>> either party. “ *
>>
>>
>>
>> Since like my colleague said, Alibaba model, this kind of user case
>> actually is the platform deciding the payment scheme, not payee( the
>> merchant) nor the payee.
>>
>>
>>
>> 2.     And also then whater A, B, C, then it should be firstly decided
>> by great market, of course, the payee or the platform 3 rd party will
>> comply with the market to choose the popular tools on payment, or else,
>> nobody to buy. So +1 to the guys which think great market power
>>
>> 3.  Also +1,  we don’t think payer should present the choices, since for
>> the privacy problem.  As for the “It’s more about automatic discovery
>> and disclosure of payment methods. The payer’s available payment
>> instruments should never be automatically disclosed to the payee without
>> the explicit consent of the payer. To do so would be a substantial privacy
>> issue. “
>>
>> 4.     + 1 also for “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”
>>
>> We should standardize the process and flow
>>
>> 5.     But as for what payement schemes should be used is risky to be
>> standardized, since it has many regularly and user cases, and sales models
>> factors to impact.  But in the flow, we need to give space for the fields
>> for the payee to choose.
>>
>> 6.     In summary, we also think A and C are needed to go. For B is not
>> considered.
>>
>> 7.     And also standard should define the general and common stuff, not
>> too much details of the specific payment scheme, like which bank etc.
>>
>>
>>
>> Judy
>>
>>
>>
>>
>>
>> *发件人:* Nick Shearer [mailto:nshearer@apple.com]
>> *发送时间:* 2015年6月25日 11:07
>> *收件人:* 段超(泰麒)
>> *抄送:* Joseph Potvin; Web Payments IG; 茱滴
>> *主题:* Re: need reason description for exclusion of UseCase v1
>>
>>
>>
>>
>>
>> On Jun 24, 2015, at 8:01 PM, 段超(泰麒) <zephyr.dc@alibaba-inc.com> wrote:
>>
>>
>>
>> Hi, Joseph:
>>
>>
>>
>> In these two scenarios, maybe the decider for which payment instruments
>> could be selected will be the company with greater market. Because it
>> involves different countries’ payment mode. In China, there has been a lot
>> of escrows to implement payment process. As an escrow, it has to think
>> about many stuffs about usability, security, risk management, etc. These
>> stuffs will take many human cost and time cost. But payee usually just
>> focus on the products or services it could supply. So payee will settle
>> payment process with a platform which is provided by escrow.
>>
>>
>>
>> In China, if a company A wants to buy a device from company B, via B’s
>> retail sales website, the website will only present the device. When A need
>> to pay for the device, website will jump to a escrow’s website to handle
>> the payment. It’s similar to the other scenario.
>>
>>
>>
>> However, in different countries there may be different payment mode. So
>> we may have to make the use cases be an universal set which includes the
>> payment mode with escrow and without escrow, and some other modes.
>>
>>
>>
>>
>>
>> 段超 *(**泰麒**)*
>>
>> *Zephyr Tuan*
>>
>> *集团安全部*_标准化与安全新技术
>>
>> *Corporation security*_standardization and new security research
>>
>>
>>
>> *发件人:* Joseph Potvin [mailto:jpotvin@opman.ca <jpotvin@opman.ca>]
>> *发送时间:* 2015年6月24日 20:27
>> *收件人:* Web Payments IG
>> *抄送:* 茱滴
>> *主题:* 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.
>>
>>
>>
>> It’s more about automatic discovery and disclosure of payment methods.
>> The payer’s available payment instruments should never be automatically
>> disclosed to the payee without the explicit consent of the payer. To do so
>> would be a substantial privacy issue.
>>
>>
>>
>>
>> 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
>>
>>
>>
>
>