Re: Dealing with the NASCAR Syndrome for Web Payments

On Tue, Apr 22, 2014 at 8:17 PM, Manu Sporny <msporny@digitalbazaar.com>
 wrote:

> On 04/15/2014 11:40 AM, Jorge Zaccaro wrote:
> > I'd love to learn more about the group's opinions and vision on
> > wallets for the Web.
>
> Formulating a Wallet API may not be the best way to approach the
> problem. Solving the problem in a more modular way would probably be
> more beneficial. For example:
>
...

> ... and so on. When you put all of these base technologies together, you
> get a wallet, but the benefit of approaching the problem in this way is
> that even if the end goal (creating a wallet API) fails, you're still
> left with a bunch of technology that is still useful in other areas.



I like the idea of taking a modular approach, and it would make perfect
sense since physical wallets are modular too, by offering pockets for
different purposes such as identification documents, banknotes/bills in any
currency, (credit/debit/gift) cards and even receipts. Then I think I'll
split the wallet API specification into modules, starting with the module
for prepaid recharges that would resemble putting cash in a physical wallet.



On Wed, Apr 23, 2014 at 8:53 PM, Manu Sporny <msporny@digitalbazaar.com>
 wrote:

> On 04/23/2014 11:43 AM, 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.
>
> That's truthy. :)
>
> How does the website discover which payment provider to invoke?



Exactly. Agreeing on an API could be a way to solve the NASCAR problem
because, instead of embedding multiple payment buttons, it would be
possible to use a provider-agnostic form as simple as an email field, which
by itself would give information about whose payment provider API to invoke
for any *buyer@example.com <buyer@example.com>*, whether that email would
have to be mapped to a payment provider using Telehash or could be used
immediately to start making API calls to *example.com <http://example.com> *on
behalf of the *buyer*.



On Wed, Apr 23, 2014 at 11:38 AM, Dave Raggett <dsr@w3.org> wrote:

> On 23/04/14 17:23, Kumar McMillan wrote:
>
>> On Apr 23, 2014, at 11:17 AM, Dave Raggett <dsr@w3.org> wrote:
>>
>> 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.
>>
>
> The idea is to remove the need for the merchant to deal with the nascar
> problem.  Competition amongst wallet providers should improve the UX for
> users, e.g. limiting the choices to the user's installed payment solutions,
> and preferences (perhaps based upon past behavior).  The browser would
> still need to ask the user which wallet to use if more than one is
> registered. However, if wallet providers do a good job, many users would
> only have one.  I don't see a need for a unified API, apart from the
> payment request by the app, and the interface needed to support
> registration.



Now, if we manage to agree on a web API (e.g. just for the payment request)
and a provider-agnostic form as simple as an email field, there would be no
need to offer a way to choose between payment solutions, just like there is
no need to choose between email providers when filling any email-based
registration form. By simply filling a field with *buyer@example.com
<buyer@example.com>* (raw) or *api.example.com/walletID
<http://api.example.com/walletID> *(mapped), even the chances of going back
to the NASCAR problem with a chooser UI could be reduced. Nonetheless,
after discovering and starting to invoke the payment provider's API, of
course it would be possible to continue the payment flow by calling the Web
Commerce API's *navigator.transact.pay(request)* method to open a dialog,
where the payment provider could offer custom functionality such as letting
the user pick her preferred mean of payment (e.g. cash vs debit vs credit
vs gift cards in a wallet).



On Thu, Apr 24, 2014 at 11:27 AM, Kumar McMillan <kmcmillan@mozilla.com>wrote:
>
> I think the merchant should still be the one to dictate which payment
> providers can be used. The user can choose from those supported providers.
> The merchant is the one who needs to get paid and they are the one who
> needs to have a pre-established business relationship with each payment
> provider. (The user needs to establish a business relationship but they can
> do that on first purchase.) The only other alternative to payment provider
> discovery that I can think of is some kind of magic blockchain-like payment
> cloud :)



Right. Business relationships would have to be established with a set of
payment providers for a buyer to be able to use them, just like only a
limited set of email providers can by used in some mobile email apps.
However, this would not affect the simplicity of a provider-agnostic form
nor the discoverability or payment flow of a web API or Web Commerce
dialog, since API calls that are not signed with an authorized access token
(e.g. Facebook Graph API) obtained during the establishment of a business
relationship with a payment provider could simply return a JSON string
indicating an 'unauthorized error', but the app probably would check its
access tokens before making an unsigned call.

One simple way of helping users to choose from a set of supported providers
without incurring in the NASCAR problem again could be the use of an email
field with autocomplete functionality to indicate the available options
after the @ symbol (unmapped case), but I'd rather stay with the simpler
raw text field and maybe use an AJAX call to verify if *example.com
<http://example.com>* is supported when the field loses focus. In any case,
I agree that if we manage to encourage competition amongst payment/wallet
providers and they do a good job, the choices of the user's installed
payment solutions should converge to a small number or even just one, just
like most people resort to a small set of established email providers in
spite of having a huge amount of options.