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

Resending to public list

From: Castillo Laurent
Sent: mardi 17 février 2015 11:35
To: Members Only - Web Payments IG (member-webpayments-ig@w3.org)
Subject: [use cases] Review of use case 3.3 "Choosing a Payment Instrument"

First, I definitely see use cases for multiple payment agents. A typical situation on a user's phone would look like:

-          My bank mobile banking app, acting as a payment agent containing my VISA card and my country's local scheme card.

-          My PayPal app, acting as payment agent for my paypal account and my registered VISA card.

-          My local bitcoin wallet acting as payment agent for bitcoin.

Relationships would work a bit like that:
User                                      1-n         Payment Agents
Payment Agent               1-n         Payment Schemes
Payment Scheme           1-n         Payment Instruments
Payment Agent               1-n         Payment Instruments

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.

On to the changes:

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)."
+ Add a line before "Optionally,...": "The payee then sends the payment request to the selected user payment agent."

Section 3.3.1 Examples

s/ payment means/ payment instruments/

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

s/ personal wallet detected/ personal cryptocurrency wallet detected/

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).

- 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.

+ 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."

Section 3.3.2 Motivations

s/ ... filter, sort, and display them/ ... filter, sort, and display them, including the payment scheme that directs its use/

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. /

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

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

Section 3.3.3 Requirements

Useless if removed.

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.../

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?

Cheers
Laurent
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus