- From: Shane McCarron <notifications@github.com>
- Date: Sun, 07 Feb 2016 09:04:27 -0800
- To: w3c/webpayments <webpayments@noreply.github.com>
- Message-ID: <w3c/webpayments/issues/78/181051307@github.com>
As I mentioned in issue #76, I thought we should try to tie this discussion back to our use cases at https://www.w3.org/TR/web-payments-use-cases/ I think that the following use cases are related to this feature: Use case 6.1.2 (Registration-less payments) supports this in that portions of the payload relate to the identity of the payer, and they don't want the site getting that information. Use case 6.2.2 (payer privacy) the payer might want to require obfuscation of the source of the funds, of their address, of their name. As long as the payee gets the funds, that is enough for some things. Use case 6.3.1 (payer intiated payments) can be seen to support this, as presumably there is information the payee sends to the payer that then needs to be sent back to the payee to confirm the payment - but that information should be concealed from the payer's payment instrument. E.g., paypal doesn't need to know what I am buying - they need to send 9.95 to the payee. Use case 6.4.2 (electronic receipts) is also relevant. An encoded receipt should be delivered as part of the payload; it may even move through all the corners of the transaction. However, only the payee and the payer should be able to decode that receipt. I could see smart wallet and payment apps might want to help their users by collecting and storing receipts for later reference (Android Pay, for example, does this now). --- Reply to this email directly or view it on GitHub: https://github.com/w3c/webpayments/issues/78#issuecomment-181051307
Received on Sunday, 7 February 2016 17:04:55 UTC