FW: [use cases] Review of use case 3.1 "Initiating a Payment"

Resending to public list.

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

Hi All,

Here are some suggested changes to the first use case :

-          Introducing payment schemes when it makes sense

-          Introducing the payee initiated model in the picture

-          Generally trying to be coherent with the glossary

-          Same conventions as IRC :)

Main Section

s/The website generates a payment request that is sent to the customer's payment processor for processing./
The website generates a payment request that is sent to the customer's payment agent for processing. The payment agent returns either a proof of payment (when payer initiated) or a proof of hold (when payer initiated)./

It's actually the payment agent that acts on behalf of the user. It's also a good place to start introducing difference between proof of payment and proof of hold.

Section: 3.1.1 Examples

s/ Penny logs into the HobbyCo website, providing her payment processor credential in the process./Penny logs into the HobbyCo website./

Why link authentication to a merchant with payment agent authentication? Especially when we have use cases around pseudonimity and purchases without registration.

s/ The store generates a payment request which is then forwarded to her preferred payment processor./
The store generates a payment request which is then forwarded to her preferred compatible payment agent (more details in choose payment instrument use case)./

s/ Merchant POV: .+/ Merchant POV: A FarmCo customer selects a 10 kg bag of grass seed for purchase. FarmCo performs a few database lookups to determine the current market price of grass seed and generates a payment request for the final amount of the selected products. The payment request is transmitted to  the customer's payment agent./

This use case was written as a purchase request, not payment request, I suggest rewriting most of it as proposed.

s/ Payment Processor POV:/ Payment Processor POV (payer initiated model):/

+ Add a POV for a payee initiated payment processor:
"Payment Processor POV (payee initiated model): A PayCo merchant RetailCo receives a proof of hold from the user payment agent. It proves the user has a valid payment instrument for a recognized scheme, and has given consent to the payment. RetailCo forwards this request to PayCo system. The transmission of funds are initiated from the customer's financial account to RetailCo's financial account. RetailCo will receive a proof of payment directly from PayCo. "

PS: s/ 3 pounds of chocolates/ 1.5 Kg of chocolates/
Has anybody ever ordered *good* chocolates from a country that weights in pounds?? :)

Section 3.1.2 Motivations

s/ the acceptable payment instruments (see the choice of payment instrument use case), and/ the acceptable payment schemes (see the choice of payment instrument use case), and/

Payment scheme is a good abstraction to avoid having to know every single payment instrument issuer (Payment scheme: a VISA card; Payment Instrument: a Wells Fargo VISA Card, a Bank of America VISA Card, etc...).

Section 3.1.3 Requirements

Useless if we remove this section as planned.

s/The messaging format should enable the payee to specify acceptable payment instruments./ The messaging format should enable the payee to specify acceptable payment schemes./
s/A protocol that is capable of transmitting the payment request from the origination point of the payment request to the payer's payment processor./ A protocol that is capable of transmitting the payment request from the origination point of the payment request to the payer's payment agent./
s/ A protocol that is capable of discovering the payer's payment processor(s)./ A protocol that is capable of discovering the payer's payment agent(s)./
s/ A protocol that is capable of discovering the payer's payment instrument(s)./ A protocol that is capable of discovering the payer's payment instrument(s) and corresponding scheme(s)./

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