Mozilla is working towards a WebPayment API to enable web content to collect payment (or issue refunds) for a virtual good. The goal is to make payments easy and secure on web devices yet still as flexible as the checkout button for merchants.
Writing on the Mozilla Blog, Kumar McMillan points out the limitations of web payments as they stand today:
Users cannot choose how to pay; they have to select from one of the pre-defined options.
In most cases, the user has to type in an actual credit card number on each site. This is like giving someone the keys to your expensive car, letting them drive it around the block in a potentially dangerous neighborhood (the web) and saying please don’t get carjacked!
Merchants typically have to manage all this on their own: payment processor setup, costly processing fees, and possibly even PCI compliance.
The upshot is that while consumers may be willing to pay for goods and services from big companies like Amazon or Google that can afford to put a payments system in place, there is no suitable solution for small website.
McMillan proceeds to provide details of a new API that will enable Firefox OS app developers to process purchases and is intended to provide a revenue stream for developers, researchers, or whoever wants to sell digital goods, take donations, etc. The goal is to let developers exchange content for money online easier. He explains:
navigator.mozPay(), which will initially ship in Firefox OS and after that be added to Firefox for Android and desktop Firefox, is the first step towards Mozilla's WebPayment API whose payment flow is detailed in the draft of the WebPayments Architecture as follows:
The app initiates a payment by signing a JSON Web Token (JWT) request and calling navigator.mozPay().
This starts the buyflow in a content iframe inside a trusted dialog ("chrome dialog").
A purchasing flow is served from the Payment Provider's server as an HTML5 document inside the trusted dialog.
The buyer is authenticated by the Payment Provider (via Mozilla Persona assertion or whatever authentication mechanisms the Payment Provider chooses).
The buyer completes or cancels the purchase.
The app server receives a signed POST request with a Payment Provider transaction identifier indicating that the purchase was completed successfully (or it failed).
Libraries for Node.JS and Python to make the server side logic for navigator.mozPay() as easy as possible have already been made available with libraries for more languages are on the way.
Mozilla is also experimenting with removing the server prerequisite entirely. Although payments are not yet fully live in the Firefox Marketplace it is possible to simulate a payment to test out code. Log into the Firefox Marketplace Developer Hub to generate an Application Key and Application Secret for simulations.
Meanwhile other parties involved with the W3C are making progress towards an open, Universal Payment Standard for the Web that will make payment a core part of the Web's infrastructure.
This video explains the problem of why making money on the web is so difficult and from around 7 minutes in has details of a potential solution called PaySwarm,created by Digital Bazaar, whose founder and CEO Manu Sporny is also the founder of the Web Payments Community Group of the W3C. that attempts to overcome some of the trust issues associated with web purchases by the use of decentralized assets, public keys, etc.
The first commercial product to use PaySwarm, Meritora was launched on April 2 and currently lets people sell digital content through their WordPress-powered websites.
In his blog post, McMillan states that "Mozilla will be watching PaySwarm as well as other models and hopefully navigator.mozPay() can incorporate some of these concepts eventually.
He also tells us that Mozilla will be working with the W3C towards a common API that supports web payments in the best possible way.
However the real question is whether or not "micropayments" or payments of any kind are unpopular on the web because of the difficulties of the transaction mechanisms or because of something much deeper. It is true that traditional payment mechanisms don't work well for payments of a few cents to view a page or turn on a feature but any payment request throws in a big psychological barrier to any transaction.
Web users are accustom to the idea that everything is free because most of the offerings that they encounter are next to worthless. And of course it's a vicious circle - the less the money the fewer the resources available to create worthwhile content.
To any reasonable observer it appears that Silverlight is dead and has been dead for quite some time. However, Microsoft has never made a statement to this effect - we are supposed to guess. Now DevEx [ ... ]