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

On 02/17/2015 10:32 AM, Castillo Laurent wrote:
> 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.

Done:

https://github.com/w3c/webpayments-ig/commit/580220c2d026eb06c47343234351767f30d3c744#diff-69ba5032c87a9348b1e27b6faf8217abL197

> *The payment agent returns either a
> proof of payment (when payer initiated) or a proof of hold (when payer
> initiated)*./

-1 - The use case is about initiating a payment, not what happens when a
payment has been completed. We have a separate use case for proof of
payment/hold/funds.

> It’s actually the payment agent that acts on behalf of the user.

+1

> It’s also a good place to start introducing difference between proof of
> payment and proof of hold.

-1, we should do that in the proof-of-* use case.

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

Changed the language to "Penny uses the HobbyCo..."

https://github.com/w3c/webpayments-ig/commit/580220c2d026eb06c47343234351767f30d3c744#diff-69ba5032c87a9348b1e27b6faf8217abL204

> Why link authentication to a merchant with payment agent authentication?

Because knowing who is buying a product is important sometimes. There is
also a fairly large "Where Are You From" problem that we have to tackle
here. There are two basic ways to solve it:

1. Implement it so that the browser /is/ or knows who your payment agent is.
2. Provide a credential to a website so it knows where to send the
payment request.

The first one requires changes to browsers, which is a non-trivial task.
The second one requires merchant software to change, which is going to
have to happen anyway for this Web Payments thing to take off.

That said, I've removed the whole "transmission of credentials" part of
the use case as we should make the point I'm making above elsewhere in
the use cases doc.

> Especially when we have use cases around pseudonimity and purchases
> without registration.

Pseudo-anonymity and registration-less is different from the WAYF
problem described above.

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

Done:

https://github.com/w3c/webpayments-ig/commit/580220c2d026eb06c47343234351767f30d3c744#diff-69ba5032c87a9348b1e27b6faf8217abL204

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

Done:

https://github.com/w3c/webpayments-ig/commit/580220c2d026eb06c47343234351767f30d3c744#diff-69ba5032c87a9348b1e27b6faf8217abL210

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

Done:

https://github.com/w3c/webpayments-ig/commit/580220c2d026eb06c47343234351767f30d3c744#diff-69ba5032c87a9348b1e27b6faf8217abL216

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

I feel slightly uneasy about the wording in this use case. I tried to
make a few modifications to make it fit in with the other examples. It
may need more tweaking to get it right:

https://github.com/w3c/webpayments-ig/commit/580220c2d026eb06c47343234351767f30d3c744#diff-69ba5032c87a9348b1e27b6faf8217abR223

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

In the name of world peace, I have removed the weight of the chocolate
purchased in the use cases.

The reviewer's aversion to chocolate from Liberia, Myanmar, and the USA
is duly noted. :P

https://github.com/w3c/webpayments-ig/commit/580220c2d026eb06c47343234351767f30d3c744#diff-69ba5032c87a9348b1e27b6faf8217abL324

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

Done:

https://github.com/w3c/webpayments-ig/commit/580220c2d026eb06c47343234351767f30d3c744#diff-69ba5032c87a9348b1e27b6faf8217abL249

> *Section 3.1.3 Requirements*
> 
> 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).*/

Fixed, and the section has been commented out (in preparation for a
migration over to "preconditions" and "postconditions":

https://github.com/w3c/webpayments-ig/commit/580220c2d026eb06c47343234351767f30d3c744#diff-69ba5032c87a9348b1e27b6faf8217abL273

-- 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 Wednesday, 18 February 2015 05:22:21 UTC