Re: FW: [use cases] Review of use case 3.3 "Choosing a Payment Instrument"

On 02/17/2015 10:32 AM, Castillo Laurent wrote:
> A scheme is a good abstraction to discover payment instruments and 
> agents locally. In essence the user agent asks “Which payment agents
> do you have installed that support bitcoin and country’s local
> scheme cards?”, the answer would be “bitcoin app with bitcoin wallet
> foo, and my bank app with card bar”. The user agent would then know
> how to root the payment request to the correct agent (through an API,
> WebIntents, web2native proposal, …). Choice of the payment instrument
> can be done either at the merchant level OR left to the payment
> agent.

All good points and this overlaps heavily with a point that Stephane has
been raising over the past several months (how do you select among
multiple payment agents on the same device?). Tracking the issue here:

https://www.w3.org/Payments/IG/track/issues/4

> *Main Section*
> 
> + Adding a line on discovery before the first sentence: "The payee
> can discover the locally installed user payment agents and their
> payment instruments (and supported schemes)."

+0.5

It's not the payee that discovers the payment agents (it's the software
that is triggered during the payment initiation process), and the
payment agents don't have to be "locally installed" (rather, they have
to be registered locally, a web wallet may not be considered to be
"locally installed").

I tried to apply the intent of what you're saying above here, let me
know if it doesn't work for you:

https://github.com/w3c/webpayments-ig/commit/851c7b38313032a91add01a2b0ed072ac7e4b4f1#diff-69ba5032c87a9348b1e27b6faf8217abR492

> + Add a line before “Optionally,…”: “The payee then sends the
> payment request to the selected user payment agent.”

+0.6

Same point - the payee doesn't do anything, the software that is
triggered during the payment initiation process (like the user agent) is
the thing that sends the payment request to the payment agent.

I've tried to apply your intent to the opening paragraph:

https://github.com/w3c/webpayments-ig/commit/851c7b38313032a91add01a2b0ed072ac7e4b4f1#diff-69ba5032c87a9348b1e27b6faf8217abL413

> *Section 3.3.1 Examples*
> s/ payment *means*/ payment *instruments*/

Fixed:

https://github.com/w3c/webpayments-ig/commit/851c7b38313032a91add01a2b0ed072ac7e4b4f1#diff-69ba5032c87a9348b1e27b6faf8217abL426

> s/ credit card (Visa, MasterCard, etc.) *channel*/ credit card
> (Visa, MasterCard, etc.) *schemes*/

Fixed:

https://github.com/w3c/webpayments-ig/commit/851c7b38313032a91add01a2b0ed072ac7e4b4f1#diff-69ba5032c87a9348b1e27b6faf8217abL426

> s/ personal wallet detected/ personal *cryptocurrency* wallet
> detected/

Fixed:

https://github.com/w3c/webpayments-ig/commit/851c7b38313032a91add01a2b0ed072ac7e4b4f1#diff-69ba5032c87a9348b1e27b6faf8217abL429

> I think specifying the wallet is interesting as an example and less 
> confusing (my bank app with my standard credit cards loaded is also 
> called a personal wallet).

I attempted to apply this thinking to the example text.

https://github.com/w3c/webpayments-ig/commit/851c7b38313032a91add01a2b0ed072ac7e4b4f1#diff-69ba5032c87a9348b1e27b6faf8217abR428

> - Third example is proximity payment: I don't think we should go
> into that field, and certainly not into that use cases. I suggest
> *removing the third example*.

Marked for removal:

https://github.com/w3c/webpayments-ig/commit/851c7b38313032a91add01a2b0ed072ac7e4b4f1#diff-69ba5032c87a9348b1e27b6faf8217abR449

> + Suggest *adding a discovery example* from the merchant POV:
> "Merchant POV: A CrowdFundCo customer has just approved a donation to
> a third party. To complete the donation, CrowdFundCo lists its
> customer payment agents and corresponding payment instruments. The
> customer has one VISA card, one MasterCard card in a single payment
> agent and a bitcoin payment agent. Because CrowdFundCo only supports
> bitcoin and paypal payment schemes, it forwards the request to the
> bitcoin payment agent."

Done:

https://github.com/w3c/webpayments-ig/commit/851c7b38313032a91add01a2b0ed072ac7e4b4f1#diff-69ba5032c87a9348b1e27b6faf8217abL438

> *Section 3.3.2 Motivations*
> 
> s/ ... filter, sort, and display them/ ... filter, sort, and display 
> them, *including the payment scheme that directs its use*/

Done:

https://github.com/w3c/webpayments-ig/commit/851c7b38313032a91add01a2b0ed072ac7e4b4f1#diff-69ba5032c87a9348b1e27b6faf8217abL453

> s/Each payment processor is registered and 'subscribes' to a the
> payment instrument it is able to provide./ Each payment agent
> registers the payment instruments it is able to provide, with their
> corresponding schemes. /

Done:

https://github.com/w3c/webpayments-ig/commit/851c7b38313032a91add01a2b0ed072ac7e4b4f1#diff-69ba5032c87a9348b1e27b6faf8217abL457

> I'm not sure it's a motivation / requirement, rather a statement of
> fact?

Yeah, this whole section needs to be re-written at some point, I've
added an issue in the spec to point this out as well as writing a
very short motivation blurb:

https://github.com/w3c/webpayments-ig/commit/851c7b38313032a91add01a2b0ed072ac7e4b4f1#diff-69ba5032c87a9348b1e27b6faf8217abL450

> s/ Each merchant provides a list of acceptable payment
> *instruments*./ Each merchant provides a list of acceptable payment
> *schemes*./

+0.5 - remember that payment instruments may be limited inside a
particular payment scheme (such as a merchant only accepting Visa /
Mastercard, and not accepting American Express). I tried to apply the
gist of what you wanted here:

https://github.com/w3c/webpayments-ig/commit/851c7b38313032a91add01a2b0ed072ac7e4b4f1#diff-69ba5032c87a9348b1e27b6faf8217abL461

> *Section 3.3.3 Requirements*
>
> s/The browser and the host are able to negotiate a payment
> instrument with respect to their preferences and support
> capabilities./
> 
> *The payee (through the user agent) and the user payment agent*are
> able to.../

Fixed:

https://github.com/w3c/webpayments-ig/commit/851c7b38313032a91add01a2b0ed072ac7e4b4f1#diff-69ba5032c87a9348b1e27b6faf8217abL492

> s/ A data format that expresses the list of available payment
> schemes that the merchant accepts./ ???/
> 
> Shouldn't it be in the payment request itself?

Yes, it should, that was the intent of the original text. I updated the
text to try and make this more clear:

https://github.com/w3c/webpayments-ig/commit/851c7b38313032a91add01a2b0ed072ac7e4b4f1#diff-69ba5032c87a9348b1e27b6faf8217abL496

The entire requirements section has been commented out in favor of a
pre-conditions / post-conditions section.

Updated draft can be found here:

https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

Received on Thursday, 19 February 2015 07:36:45 UTC