Re: proposed navigator.mozPay() changes

I'm collecting my thoughts wrt. Web Commerce API for the discussion
tomorrow, so just mostly thinking out loud and offering potential
answers to your questions.

On 09/05/2013 06:07 PM, Kumar McMillan wrote:
> I think it is possible to evolve a real trusted UI but the one in
> Firefox OS is not it. Work on this is happening separately so I
> merely suggested window.open({mozTrusted: true}) as a way to extract
> that part from mozPay until a better solution is ready.

Where is the work happening separately? Is it in a form that is ready
for public consumption yet? Got a link?

> Eventually when we have a working trusted UI I think it would be
> essential to open it up for others to use.

+1

> My proposal to deprecate mozPay means that no one would need to be
> whitelisted to do get mobile payment features.

Ok, that would be great. I don't understand the high-level of how that
would work. We should go over that on the call.

> What incentive is there for large companies to adopt mozPay as a buy
> flow? 

Maybe not mozPay itself, but mozPay + PaySwarm could be compelling if
certain things fall into place. If (big IF) PaySwarm were to gain
adoption as a major Web payments standard online, and it could be
triggered by navigator.pay(), then large companies might want want to
use it because it makes integrating their payment system with a website
much easier.

A merchant currently has to pick a merchant processor and shopping cart
software. The software tends to be very difficult to setup and use, even
in the case of Stripe. It would be nice if you just had a Stripe-like
API that worked the same for any payment processor. So, switching
payment processors was quite literally a one line code change, and not
the gigantic multi-week hassle that it is today.

This shift will be driven by the developers rather than the large
companies. That said, this can happen w/o mozPay.

>> 3. This may be perceived as Mozilla backing away from doing
>> something deeper with payments and app stores on the Web. Is that
>> perception correct?
> 
> I'd hope that this proposal is perceived as Mozilla making core
> payment features available to *more* of the web. What I'd like to do
> is unlock the special API privileges that Mozilla is currently
> getting from mozPay. If PayPal wants to improve their carrier billing
> they should be able to do so without implementing all of mozPay.

Agreed. I still don't understand which special API privileges we're
talking about, though. I'm sure you'll explain on the call.

> It's less clear why we need a new web API to enable the
> purchase of any good anywhere on the web. Don't we just need HTTP?
> How would mozPay help solve this?

With respect to the PaySwarm work, we've always been interested in the
browser having the ability to complete a transaction initiated by an API
call in the background. This is useful for pay-as-you-go scenarios or
in-app payments where you don't want a UI popping up every time you need
to do a $0.05 purchase. It's true that you can do this with some
server-side trickery today, but one of the goals of PaySwarm was to make
payments easier to process. Ideally, a developer would just:

1. Create a product and put it on the page for sale.
2. Call navigator.pay(productUrl).
3. The browser would lift the product info from the page, submit the
signed purchase request to the payment processor, the payment processor
would complete the purchase, the digital receipt would be handed
back to the browser, and it would appear in the client-side code, which
the website could then do with as it pleased.

All of this is implementable w/o the navigator.pay() API, but it
requires more code outlay on the server side.

Generally speaking, we wanted the purchase processing to be between the
browser and the payment processor, not the browser->merchant->payment
processor. We wanted this so that the browser could be smarter about
things when doing a purchase... if the item has already been purchased,
the browser could just return the digital receipt w/o needing to contact
the payment processor. In a restricted intranet (military facility - yes
we have a use case for this), the browser could still provide
proof-of-purchase w/o contact w/ the outside world.

I do admit that this is a heavier set of requirements than mozPay, but
we always viewed navigator.pay() as the start of a storage mechanism for
digital receipts.

> However, it's equally
> unclear to me why PaySwarm would need a new web API. Doesn't the
> PaySwarm protocol already work on today's web? I think the PaySwarm
> protocol can excel forward without the need for something like
> mozPay. Or am I missing something here?

It can continue w/o deeper browser integration, yes. It was designed to
not depend on browser implementations to work (same design principles as
Mozilla Persona). That said, there are some really compelling use cases
that can be accomplished with minimal browser additions. I should really
document all of those somewhere. Here is the high-level:

1. The ability for the browser to provide a proof-of-purchase.
2. The ability for a browser to be offline and provide a proof-
   of-purchase.
3. Greater anonymity when using a proof-of-purchase to access other
   website content.
4. The ability to perform purchases where the target device is not
   connected to the Internet (vending machines).

>> Would nav.pay() disappear entirely?
> 
> My proposal was to stop using nav.pay() for payments, yes. My
> argument is that we don't need it to do payments on Firefox OS, we
> just need some lower level primitives to do carrier billing better.

I certainly agree with the goals. I don't understand the details, but
those are easy enough to cover on the phone call.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Wednesday, 11 September 2013 03:30:59 UTC