Google changes course, proposes proprietary in-app purchase API as web standard

Developers rejoice, there may be (eventually) a store-agnostic way to sell in-application items

7 Reg comments Got Tips?

Google has decided to try to openly standardize one of its own APIs for handling in-app purchases in web apps rather than pursuing a previously proposed proprietary plan.

In January, Google Chrome developer Jay Harris announced the internet giant's intent to prototype a proprietary API in the Chromium project's Blink browser engine to allow web apps running in Chrome to query the product identifiers (SKUs) assigned to digital goods sold via an in-app purchase (IAP) in the Google Play store.

Developers of progressive web apps – PWAs are web apps that support specific capabilities like offline support and home screen installation – would like their applications to be listed in the Google Play Store, to increase visibility and distribution. But Google's store policies require that all IAP-enabled apps in the store use the Play Billing API.

Google provides an SDK that allows Android apps to do this but there's no equivalent for web apps. So you can see the rub.

Pretty much everyone who develops web-oriented code – with the possible exception of Apple, which Google developers, among others, have accused of stacking the deck against mobile web apps – would like to see the capability gap between native and web apps closed as much as possible.

PWAs can use the relatively recent Payment Request API, but that was designed to authorize specific transaction amounts (e.g. $5) rather than specific SKUs (e.g. "s123456789_us") used to track the sale of a specific digital product (e.g. a "tiny sword of power" sold in a mobile game).

The proposed API would let a PWA include code that queries Google Play, and the store would respond to that query with the product title, price in local currency, and other relevant metadata. It could then sell in-app items and could be distributed through Google Play, a commercially desirable possibility.

Harris noted that it was unusual to run the proposal for a Chrome-specific API through the Blink feature review process, which normally deals with open source code implementations relevant to makers of other Chromium-based browsers and competing browser makers.

Pinterest stats from Chrome Dev Summit

How to make your HTML apps suck less, actually make some money

READ MORE

"In general, we are opposed to adding proprietary APIs via the browser," Harris said in an explanatory document. "However, we consider the Play Billing APIs to be part of a separate ecosystem, similar to that of Android Apps in the Play Store, or iPhone Apps in the App Store."

But since the Google Play-specific API was being implemented in Blink, a public resource, it seemed prudent to let people know about it.

Harris's explainer touched on the benefits of seeking standardization for the API, but some disadvantages were mentioned too, specifically that the W3C standards process could take years, and Google Play will be unable to change its APIs once a standard gets put in place.

Nonetheless, over the past two months, other developers, from Google and elsewhere, urged those working on the would-be spec to consider an open API for any web app in any store. And on Wednesday, they prevailed.

In a post to the Web Incubator Community Group (WICG), Matt Guica, a Chrome software engineer, put the nascent API on the path toward standardization.

"We originally proposed this API in the form of a proprietary API for Chrome web apps hosted in the Google Play Store," he wrote. "However, in the pursuant discussion, we were convinced to pivot to a standards-track API, so that potentially any browser can integrate with the store on the user’s device."

Let the debate begin, but don't hold your breath. It might take a while. ®

SUBSCRIBE TO OUR WEEKLY TECH NEWSLETTER


Biting the hand that feeds IT © 1998–2020