- From: Kumar McMillan <kmcmillan@mozilla.com>
- Date: Wed, 23 Apr 2014 11:23:13 -0500
- To: Dave Raggett <dsr@w3.org>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, public-webpayments@w3.org
On Apr 23, 2014, at 11:17 AM, Dave Raggett <dsr@w3.org> wrote: > On 23/04/14 16:43, Kumar McMillan wrote: >> On Apr 22, 2014, at 8:17 PM, Manu Sporny <msporny@digitalbazaar.com> wrote: >>> 4. Standardize payment initiation: >>> https://web-payments.org/specs/source/web-commerce-api/ >>> 5. Standardize digital receipts: >>> https://web-payments.org/specs/source/web-commerce/ >> To specifically solve the nascar problem I think you only need these two things ^ >> >> A web API (or JavaScript shim) just needs to know how to invoke a compliant payment provider and how to verify the purchase. Each payment provider could still handle identity / credentials themselves. >> >> -Kumar >> > > How does the user can choose between payment solutions? This is why it may be better for the same interface to bind to the user's choice of wallet (there could be more than one), and leave it to the wallet to provide the UX for for the user to pick her preferred payment solution for the current transaction. This means we also need to discuss how to allow the user to register and unregister wallets and payment solutions, and to allow for both locally installed and remotely hosted implementations. Yeah, there’d probably need to be a chooser UI somewhere but I’m still not sure you need to impose identity on payment providers for that. A chooser UI might bring us back to the nasar problem though. However, by pushing the nascar problem into a unified API you’d still be solving an important part of the problem. I.E. Having the *merchant* deal with the nascar problem is more of a burden. > > -- Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
Received on Wednesday, 23 April 2014 16:23:39 UTC