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

Thanks for the integration! Some replies to the items were you raised point:

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

[Laurent] Fair point, I agree with removing receipts completely from this use case and leaving them in use case 3.7.

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

[Laurent] I think the key point here is identity is important *sometimes*, I'm strongly against mandating a link between merchant authentication and payment agent in the recommendations (making them possible is of course desirable).
Two more points:
- Defining a single credential universally accepted is going to be a nightmare (it has been tried many times, with the end results being usually adding yet another credential).
- It's better for adoption to try and minimize changes on all parties, and going for a single credential that merchants MUST support is going to severely limit adoption, or unduly favor big internet players.

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

[Laurent] From WAYF yes, not from authentication...

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

[Laurent] Alternatively, these two examples (Payment Processor POVs) could be moved to use case 3.7, since they are mostly about proof of payment / proof of hold.

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

Received on Thursday, 19 February 2015 14:41:26 UTC