Hi WICG,
I’d like to propose an API for querying and managing digital products to facilitate in-app purchases from web applications, in conjunction with the Payment Request API (which would be used to make the actual purchases). The API would be linked to a digital distribution service connected to via the user agent.
The problem
The problem we are trying to solve is that Payment Request by itself is inadequate for making in-app purchases in existing digital stores, because that API simply asks the user to make a payment of a certain amount (e.g., “Please authorize a transaction of US$3.00”), which is sufficient for websites selling their own products, but established digital distribution services require apps to make purchases by product IDs, not monetary amounts (e.g., “Please authorize the purchase of SHINY_SWORD”); the price being configured per-region on the backend.
The proposed solution (in very basic terms)
So we would like to build a new API, which allows the user agent to expose product-ID-related services from a digital store. This API would allow the web application to make a query, given a product ID, and retrieve the product title, price in local currency, and other information, in a store-specific but browser-agnostic manner. The application would use the Payment Request API with the store as a payment provider, supplying the product ID as metadata. A completed purchase would return a “purchase token”, which the application would be able to transmit to the new Digital Product Management API to “consume” or “acknowledge” the purchase, marking the transaction as complete.
Such an API is necessary to allow web apps to be listed in various application stores, where apps are typically subject to requirements that digital purchases go through the store’s purchasing flow (and therefore, it would be against policy for apps listed in such stores to implement their own billing flow). Sites using the proposed API would still need to be individually configured to work with each store they are listed in, but having a standard API means they can integrate with a given store, and potentially have that integration work across multiple browsers. This is similar to how the existing Payment Request API works (sites still need to integrate with each payment provider, e.g., Google Pay, Apple Pay, but their implementation is browser agnostic).
Some history
Note: We originally proposed this API in the form of a proprietary API for Chrome web apps hosted in the Google Play Store (see the proposal on the blink-dev thread: “SKU APIs for Web Apps in the Play Store”). 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. Our basic motivation remains the same as outlined in that post from January, but we would be changing the design of the API to avoid being overly specific to one store (for example, we avoid the Play-Store-specific term “SKU” and instead the generic name “product ID”).
We’d like to take expressions of interest for both developers who would be interested in a web API for integrating with the on-device store, and browser manufacturers who would like to integrate with a store. In particular, we are looking for ways to design the API to avoid Play-specific idioms. I am planning to put together a more comprehensive explainer document in the WICG.
Thanks
Matt Giuca on behalf of the Google Chrome OS and Web Platform teams
