[Proposal] Web Payments Digital Product Management API


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.


Matt Giuca on behalf of the Google Chrome OS and Web Platform teams


This sounds great - for us the two main reasons we still have to publish web apps as WebViews inside native apps with frameworks like Cordova is for IAP and ads. Adding support for IAP directly as a web API would be a major step towards being able to publish web apps to stores using the browser only, and not needing to bring in a big and complex third-party framework to handle native/web communication.

For inspiration for API surface and usage in practice, Cordova plugins that already aim to solve this like cordova-plugin-purchase may provide some inspiration (although at first glance the API could probably be modernised for things like async/await).

1 Like

Is it possible to piggy-back this on payment request? then this could just be some kind of payment handler and you could standardize the tokenized payment model… or do we need to change the Payment Request API in some way (e.g., we drop requiring the amount)?

Hi Marcos,

We’ve looked at Payment Request (we’ve been working with the Payment folks at Google to design this), and determined that yes this can work with PR API, but we need additional APIs on the side to do out-of-band digital product management.

It’s possible that what we’re proposing ends up making its way into the PR standard, but my feeling is that it’s fairly separable.

do we need to change the Payment Request API in some way (e.g., we drop requiring the amount)?

I think we will also need to drop requiring the payment amount, since if you supply a product ID in the private data to the PR API, you wouldn’t also want the client to redundantly specify the cost. We’ll look at any required changes to PR as part of this.

(Rest assured, we are not going to duplicate any functionality that’s already in PR, or should be in PR.)

Can you enumerate some of the functions/interactions between the calling website and the store? Anything more than:

  • Request product purchase
  • Exchange “receipt” for digital product

We spun up https://github.com/WICG/digital-goods to explore this further…

1 Like

Thanks Marcos!

I have now put up the explainer into that WICG repo. Welcoming further comments and suggestions as issues or pull requests.

Thank for your work on IAP for webapps Matt, We from Samsung side would also like to express interest in IAP support for WebApps distributed via Galaxy App store. We will help review and provide feedback by getting right teams involved.

I think that IAP for Web Apps would greatly simplify the selling of small digital goods / services.

In particular it would be useful to have a Browser Store that collects all the payments from customers, and the PWA developer only gets a monthly payout (minus a percentage that goes to the Browser Store).

That would greatly simplify payments and accounting for developers and would be a large source of income for browsers.

I imagine that the website creates a request (similar to what already happens for the Payment Request API) and then the browser, instead of returning a payment method, completes the payment and simply returns a cryptographically signed receipt to the website (or a token that can be verified). I also imagine that the users interacts directly with a Browser Store (which is not invisible to the user) and thus all the receipts and other legal duties must be completed by that Browser Store.