Intent to Prototype: SKU APIs for Web Apps in the Play Store

434 views
Skip to first unread message

Jay Harris

unread,
Jan 30, 2020, 7:11:03 PM1/30/20
to blink-dev, Rouslan Solomakhin, Matt Giuca, Dominick Ng, Ben Wells

Contact emails

harr...@chromium.org, mgi...@chromium.org, domi...@chromium.org 


Not on standards track

This is an unusual case. This API is not going to be exposed to the general web, and we do not currently intend to take it through a standards track. However, as it is being implemented in Blink, we thought it was prudent to go through the Blink feature process.


The API will be exposed only to Web Apps that have been listed in the Play Store, and have been installed from the Play Store by the user on Chrome OS and Android devices. As such, it is more akin to an Android app exposing access to a native Android API to pages hosted inside a web view, rather than a browser exposing an API to the open web. See Motivation for details.


Explainer

This will not be a web exposed feature, it will only be available to Web Apps running in a Play Store Context. As such, it does not have an explainer, but instead, an Overview Document, which is available here: https://docs.google.com/document/d/1Jbt2Mzt-xg1cWVlFScBQsoX_pE8Kg1gYpulxUSV8FM0/edit?usp=sharing


The API will be based on the Play Billing SDK which is covered here: https://developer.android.com/google/play/billing/billing_library_overview


Design doc/Spec

We do not intend to go through a TAG review process, because this is not being exposed to the open web and we are not expecting other browsers to implement the API (see “Not on standards track”).


Summary

This change will expose APIs for querying information about SKUs (available in app purchases) to web apps listed in the Play Store, on Chrome OS and Android. This includes pricing, currency, name and description. It will also provide methods for consuming and acknowledging purchases with Play. Note that the SKUs available to the app are tied to the app’s listing in the Play Store.


This API does not directly allow for purchases to be made. It is designed to be used alongside the Payment Request API (https://w3c.github.io/payment-request/) to perform the actual purchase.


Motivation

Web apps listed in the Play Store cannot currently comply with Play in-app purchase policy, which mandates that all in-app purchases **MUST** use the Play Billing API. This is not a problem for non-web apps, as Play provides an SDK allowing them to do this, but there is no equivalent on the web.


Risks

Interoperability and Compatibility

We are not expecting other browsers to implement this API, and the feature will only be available to Web Apps that specifically opt into it, via publishing themselves to the Play Store. As such, this is not thought of as a web API for the purposes of interoperability.


It is conceivable that a developer might build a web app using these APIs and publish it to the Play Store. This app might not support in-app purchases on the drive-by web, or even might not work at all. This is mitigated by the Ergonomics section below.


Ergonomics

Generally, this API will be used alongside the Payment Request API, in order to make a purchase. This means the bulk of the payment code (the usage of Payment Request) can be shared between the Play and non-Play contexts.


Activation

This feature will only be available to developers who explicitly opt into the feature, by publishing their app on the Play Store.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No. This API exposes SKU management capabilities from an app store integrated with the browser. It will only be supported on Chrome OS and Android.


Link to entry on the feature dashboard

This feature is not web facing, and as such, does not have a Chrome Status Entry.


Requesting approval to ship?

No


Yoav Weiss

unread,
Jan 31, 2020, 5:47:52 AM1/31/20
to Jay Harris, blink-dev, Rouslan Solomakhin, Matt Giuca, Dominick Ng, Ben Wells
On Fri, Jan 31, 2020 at 1:10 AM Jay Harris <harr...@chromium.org> wrote:

Contact emails

harr...@chromium.org, mgi...@chromium.org, domi...@chromium.org 


Not on standards track

This is an unusual case. This API is not going to be exposed to the general web, and we do not currently intend to take it through a standards track. However, as it is being implemented in Blink, we thought it was prudent to go through the Blink feature process.


The API will be exposed only to Web Apps that have been listed in the Play Store, and have been installed from the Play Store by the user on Chrome OS and Android devices. As such, it is more akin to an Android app exposing access to a native Android API to pages hosted inside a web view, rather than a browser exposing an API to the open web. See Motivation for details.


Explainer

This will not be a web exposed feature, it will only be available to Web Apps running in a Play Store Context. As such, it does not have an explainer, but instead, an Overview Document, which is available here: https://docs.google.com/document/d/1Jbt2Mzt-xg1cWVlFScBQsoX_pE8Kg1gYpulxUSV8FM0/edit?usp=sharing



What would happen in this case for users that have set their default browser to a (non-Chrome) Chromium browser?
What would happen for users that have set Firefox to be their default browser?
 

The API will be based on the Play Billing SDK which is covered here: https://developer.android.com/google/play/billing/billing_library_overview


Design doc/Spec

We do not intend to go through a TAG review process, because this is not being exposed to the open web and we are not expecting other browsers to implement the API (see “Not on standards track”).


Summary

This change will expose APIs for querying information about SKUs (available in app purchases) to web apps listed in the Play Store, on Chrome OS and Android. This includes pricing, currency, name and description. It will also provide methods for consuming and acknowledging purchases with Play. Note that the SKUs available to the app are tied to the app’s listing in the Play Store.


This API does not directly allow for purchases to be made. It is designed to be used alongside the Payment Request API (https://w3c.github.io/payment-request/) to perform the actual purchase.


Motivation

Web apps listed in the Play Store cannot currently comply with Play in-app purchase policy, which mandates that all in-app purchases **MUST** use the Play Billing API. This is not a problem for non-web apps, as Play provides an SDK allowing them to do this, but there is no equivalent on the web.


Risks

Interoperability and Compatibility

We are not expecting other browsers to implement this API, and the feature will only be available to Web Apps that specifically opt into it, via publishing themselves to the Play Store. As such, this is not thought of as a web API for the purposes of interoperability.


It is conceivable that a developer might build a web app using these APIs and publish it to the Play Store. This app might not support in-app purchases on the drive-by web, or even might not work at all. This is mitigated by the Ergonomics section below.


Ergonomics

Generally, this API will be used alongside the Payment Request API, in order to make a purchase. This means the bulk of the payment code (the usage of Payment Request) can be shared between the Play and non-Play contexts.


Activation

This feature will only be available to developers who explicitly opt into the feature, by publishing their app on the Play Store.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No. This API exposes SKU management capabilities from an app store integrated with the browser. It will only be supported on Chrome OS and Android.


Link to entry on the feature dashboard

This feature is not web facing, and as such, does not have a Chrome Status Entry.


Requesting approval to ship?

No


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGrMWk8MXeE5s%3DBPUEFgpym8%2BEV%3DYd5%3DJHTbR6PkQXjOShFMiw%40mail.gmail.com.

Dominick Ng

unread,
Jan 31, 2020, 6:01:57 AM1/31/20
to Yoav Weiss, Ben Wells, Dominick Ng, Jay Harris, Matt Giuca, Rouslan Solomakhin, blink-dev
Hi Yoav,

Can you clarify what "this case" is that you're referring to?

Cheers,

Yoav Weiss

unread,
Jan 31, 2020, 6:05:28 AM1/31/20
to Dominick Ng, Ben Wells, Jay Harris, Matt Giuca, Rouslan Solomakhin, blink-dev
On Fri, Jan 31, 2020 at 12:01 PM Dominick Ng <domi...@chromium.org> wrote:
Hi Yoav,

Can you clarify what "this case" is that you're referring to?

What happens with AppStore installed PWAs for users that have changed their OS' default browser?

Dominick Ng

unread,
Jan 31, 2020, 6:15:02 AM1/31/20
to Yoav Weiss, Ben Wells, Dominick Ng, Jay Harris, Matt Giuca, Rouslan Solomakhin, blink-dev
A web app listed in the Store will be backed by the user's default browser if that browser supports the necessary Android API for wrapping web apps. My understanding is that it will fall back to Chrome if that API isn't supported by the default browser.

Yoav Weiss

unread,
Jan 31, 2020, 6:44:21 AM1/31/20
to Dominick Ng, Ben Wells, Jay Harris, Matt Giuca, Rouslan Solomakhin, blink-dev
On Fri, Jan 31, 2020 at 12:14 PM Dominick Ng <domi...@chromium.org> wrote:
A web app listed in the Store will be backed by the user's default browser if that browser supports the necessary Android API for wrapping web apps. My understanding is that it will fall back to Chrome if that API isn't supported by the default browser.

Does that mean that apps that require this API will always fall back to Chrome?

Dominick Ng

unread,
Jan 31, 2020, 7:19:24 AM1/31/20
to Yoav Weiss, Ben Wells, Dominick Ng, Jay Harris, Matt Giuca, Rouslan Solomakhin, blink-dev
By its nature, we expect apps that are subject to Store purchase policy to feature detect if the API is available, and only offer digital purchases when it is available so they can satisfy the policy. Otherwise they should run as normal, sans digital purchases.

Yoav Weiss

unread,
Jan 31, 2020, 8:06:40 AM1/31/20
to Dominick Ng, Ben Wells, Jay Harris, Matt Giuca, Rouslan Solomakhin, blink-dev
On Fri, Jan 31, 2020 at 1:19 PM Dominick Ng <domi...@chromium.org> wrote:
By its nature, we expect apps that are subject to Store purchase policy to feature detect if the API is available, and only offer digital purchases when it is available so they can satisfy the policy. Otherwise they should run as normal, sans digital purchases.

 
That seems problematic.
Can you expand on why this proposal is not on any standards track? 

fluorescent....@gmail.com

unread,
Feb 2, 2020, 3:40:42 PM2/2/20
to blink-dev
Why not just to implement it as a JS library (that should be installed in web app from CDN) or better as a REST API with key? In this case it could be used by any browser.

Also, as an idea, Google Play app could be registered as Payment Handler (https://w3c.github.io/payment-handler/) and be used as payment method in Payment Request API.

Matt Giuca

unread,
Feb 5, 2020, 12:50:13 AM2/5/20
to Yoav Weiss, Dominick Ng, Ben Wells, Jay Harris, Rouslan Solomakhin, blink-dev
On Sat, 1 Feb 2020 at 00:06, Yoav Weiss <yo...@yoav.ws> wrote:


On Fri, Jan 31, 2020 at 1:19 PM Dominick Ng <domi...@chromium.org> wrote:
By its nature, we expect apps that are subject to Store purchase policy to feature detect if the API is available, and only offer digital purchases when it is available so they can satisfy the policy. Otherwise they should run as normal, sans digital purchases.

 
That seems problematic.
Can you expand on why this proposal is not on any standards track? 

I will expand on the "Not on standards track" section of Jay's original email.

We want to distinguish between a) the availability of the API from the developer perspective, and b) the specific technical details of how the API is implemented in the Chromium codebase.

For (a), we do not consider this API to be part of the web platform. It won't be available to any site on the open web (the API simply won't exist). It will only be visible to an app that is listed in the Play Store, and only when the user has installed the app through the Play Store on a supporting device. That makes it effectively the same as if the developer had made an Android app wrapper around a WebView, and injected a JavaScript API into the WebView which exposes the Play Billing APIs to the website when running in that context. We are just streamlining the developer experience so they do not have to go to all that effort.

For (b), we are planning to write the code supporting this API in Blink. That's why we're sending an Intent to Prototype, so that Blink owners are aware of the work we're doing. But we don't consider that relevant to the web compatibility story.

As for "why not put it through standards track?", we see this as being rather specific to the Play Store. The general concept of digital payments is covered by the Payment Request API; the SKU API is just the parts specific to the Play Billing flow (namely, that when you make a purchase, you have to provide a specific product ID, not just an amount of money). It's possible that as we develop this, other developers will convince us that it's useful outside of the Play ecosystem and we would work to generalize and standardize it.

Finally, even if we standardized every other aspect of this API, we would still need a tiny proprietary API to let developers ask the question "Am I currently subject to Play Billing policy?" That is something that only the browser can tell you (since it knows the context in which you were installed), and is a very specific requirement from Play which I don't think generalizes to the open web platform.



On Fri, 31 Jan 2020 at 22:44, Yoav Weiss <yo...@yoav.ws> wrote:


On Fri, Jan 31, 2020 at 12:14 PM Dominick Ng <domi...@chromium.org> wrote:
A web app listed in the Store will be backed by the user's default browser if that browser supports the necessary Android API for wrapping web apps. My understanding is that it will fall back to Chrome if that API isn't supported by the default browser.

Does that mean that apps that require this API will always fall back to Chrome?
 

On Fri, 31 Jan 2020 at 22:05, Yoav Weiss <yo...@yoav.ws> wrote:


On Fri, Jan 31, 2020 at 12:01 PM Dominick Ng <domi...@chromium.org> wrote:
Hi Yoav,

Can you clarify what "this case" is that you're referring to?

What happens with AppStore installed PWAs for users that have changed their OS' default browser?

I share your concerns about this (and it has been raised on internal discussions). On Android, we do need to consider the case where Chrome is not the user's default browser, or even not installed at all. We will continue to think about this problem as we prototype.
On Mon, 3 Feb 2020 at 07:40, <fluorescent....@gmail.com> wrote:
Why not just to implement it as a JS library (that should be installed in web app from CDN) or better as a REST API with key? In this case it could be used by any browser.

That's a good question. We have added a section to the doc called Alternatives Considered. This was the first alternative in that list.

There are a number of answers to this, which added up to our decision not to pursue this approach, and instead add code directly into the browser:
  1. A major engineering hurdle for us: we would need the Google Play Store website to host a REST API that's equivalent to the BillingClient API in the Android SDK, which they weren't willing to do. The only public facing way to use this API is through the Android SDK.
  2. Authentication is potentially problematic. We are required to auth as the user who installed the Android app. That's probably the same user as the current Google cookie (due to recent efforts to sync Chrome logged-in user with the device), but there are sure to be edge cases where that isn't true, especially if we're talking about exposing the service to non-Chrome browsers.
  3. Since the actual payment request goes through the Payment Request API, and that goes through the Google Play app, a discrepancy with the Google cookie user and the Android device user would mean the SKU API returns mismatching information (such as the wrong price) versus what actually gets purchased, which would be very bad. We want the SKU querying and the actual purchasing to go through the same channel, and the simplest way to do that is to funnel both through the Android SDK.

Also, as an idea, Google Play app could be registered as Payment Handler (https://w3c.github.io/payment-handler/) and be used as payment method in Payment Request API.

Yes, that is essentially what we plan to do. The only reason we are building the SKU API is to expose the parts of the Play Billing API that are not accessible through the Payment Request API (i.e., the parts relating to querying SKUs, not making the actual payments itself). That's all the more reason to have the SKU API go through the browser which can then talk natively to the Play Store.

Yoav Weiss

unread,
Feb 8, 2020, 2:59:14 AM2/8/20
to Matt Giuca, Dominick Ng, Ben Wells, Jay Harris, Rouslan Solomakhin, blink-dev
On Tue, Feb 4, 2020 at 9:50 PM Matt Giuca <mgi...@chromium.org> wrote:


On Sat, 1 Feb 2020 at 00:06, Yoav Weiss <yo...@yoav.ws> wrote:


On Fri, Jan 31, 2020 at 1:19 PM Dominick Ng <domi...@chromium.org> wrote:
By its nature, we expect apps that are subject to Store purchase policy to feature detect if the API is available, and only offer digital purchases when it is available so they can satisfy the policy. Otherwise they should run as normal, sans digital purchases.

 
That seems problematic.
Can you expand on why this proposal is not on any standards track? 

I will expand on the "Not on standards track" section of Jay's original email.

We want to distinguish between a) the availability of the API from the developer perspective, and b) the specific technical details of how the API is implemented in the Chromium codebase.

For (a), we do not consider this API to be part of the web platform. It won't be available to any site on the open web (the API simply won't exist).

So, just to clarify, the API would be exposed when the app was installed as a TWA from the Play Store, but e.g. not when the same site is accessed through the browser?
 
It will only be visible to an app that is listed in the Play Store, and only when the user has installed the app through the Play Store on a supporting device. That makes it effectively the same as if the developer had made an Android app wrapper around a WebView, and injected a JavaScript API into the WebView which exposes the Play Billing APIs to the website when running in that context. We are just streamlining the developer experience so they do not have to go to all that effort.

For (b), we are planning to write the code supporting this API in Blink. That's why we're sending an Intent to Prototype, so that Blink owners are aware of the work we're doing. But we don't consider that relevant to the web compatibility story.

What happens with non-Chrome Chromiums? The API is not exposed?

Matt Giuca

unread,
Feb 9, 2020, 11:46:08 PM2/9/20
to Yoav Weiss, Dominick Ng, Ben Wells, Jay Harris, Rouslan Solomakhin, blink-dev
On Sat, 8 Feb 2020 at 18:59, Yoav Weiss <yo...@yoav.ws> wrote:


On Tue, Feb 4, 2020 at 9:50 PM Matt Giuca <mgi...@chromium.org> wrote:


On Sat, 1 Feb 2020 at 00:06, Yoav Weiss <yo...@yoav.ws> wrote:


On Fri, Jan 31, 2020 at 1:19 PM Dominick Ng <domi...@chromium.org> wrote:
By its nature, we expect apps that are subject to Store purchase policy to feature detect if the API is available, and only offer digital purchases when it is available so they can satisfy the policy. Otherwise they should run as normal, sans digital purchases.

 
That seems problematic.
Can you expand on why this proposal is not on any standards track? 

I will expand on the "Not on standards track" section of Jay's original email.

We want to distinguish between a) the availability of the API from the developer perspective, and b) the specific technical details of how the API is implemented in the Chromium codebase.

For (a), we do not consider this API to be part of the web platform. It won't be available to any site on the open web (the API simply won't exist).

So, just to clarify, the API would be exposed when the app was installed as a TWA from the Play Store, but e.g. not when the same site is accessed through the browser?

I believe that's correct. Certainly true when the site is accessed through the browser when not installed. I believe it would not be exposed when the site is accessed through a browser even after installed (it would depend on the Play Store policy, whether the policy is enforced when accessing the site through a browser after installing the PWA; I believe it would not be).
 
 
It will only be visible to an app that is listed in the Play Store, and only when the user has installed the app through the Play Store on a supporting device. That makes it effectively the same as if the developer had made an Android app wrapper around a WebView, and injected a JavaScript API into the WebView which exposes the Play Billing APIs to the website when running in that context. We are just streamlining the developer experience so they do not have to go to all that effort.

For (b), we are planning to write the code supporting this API in Blink. That's why we're sending an Intent to Prototype, so that Blink owners are aware of the work we're doing. But we don't consider that relevant to the web compatibility story.

What happens with non-Chrome Chromiums? The API is not exposed?

The API should not be exposed.

We've since had a discussion (based on the code review) with haraken@, jam@, creis@ and dcheng@ about whether this should be in Blink at all, given that it is not intended to be standardized or exposed outside of Chrome. The conclusion of that was that we should not be putting it in Blink, and instead exposing it through a JS API injection from /chrome. So we are now looking into doing that instead.

Alex Russell

unread,
Feb 13, 2020, 12:47:42 PM2/13/20
to blink-dev, Matt Giuca, Dominick Ng, Ben Wells, Jay Harris, Rouslan Solomakhin, blink-dev, Yoav Weiss
Sorry for the late feedback.

Has there been any outreach to other store providers to determine if they'd like to specify an API that can work for them as well? We know, for instance, that MSFT and Samsung both run stores that allow listing of PWAs and provide in-app purchase infrastructure.

Framing this in a proprietary way seems, until we do that research, at minimum premature.

Regards

Matt Giuca

unread,
Feb 14, 2020, 1:34:28 AM2/14/20
to Alex Russell, blink-dev, Dominick Ng, Ben Wells, Jay Harris, Rouslan Solomakhin, Yoav Weiss
On Fri, 14 Feb 2020 at 04:47, Alex Russell <sligh...@google.com> wrote:
Sorry for the late feedback.

Has there been any outreach to other store providers to determine if they'd like to specify an API that can work for them as well? We know, for instance, that MSFT and Samsung both run stores that allow listing of PWAs and provide in-app purchase infrastructure.

Framing this in a proprietary way seems, until we do that research, at minimum premature.

In truth, this could potentially extend to other stores as well.

I would want us to have considered that before this ships. But I have always believed that we can make better informed decisions about API design if we prototype early, and think about improving or generalizing the design of an API as a consequence of that (as opposed to design-first-implement-later). I believe that's why this process changed from "intent to implement" to "intent to prototype", to place greater emphasis on the fact that this is a mutable prototype and not a final design.

I think the best starting point here is what we know: the Play Billing API. That is what we intend to land as a first step, and evolve from there.

(I discussed this in more detail with Alex offline, but the above is my summary for posterity.)

samri...@google.com

unread,
Feb 19, 2020, 8:16:32 PM2/19/20
to blink-dev, yo...@yoav.ws, domi...@chromium.org, benw...@chromium.org, harr...@chromium.org, rou...@chromium.org
For (a), we do not consider this API to be part of the web platform. It won't be available to any site on the open web (the API simply won't exist). It will only be visible to an app that is listed in the Play Store, and only when the user has installed the app through the Play Store on a supporting device. That makes it effectively the same as if the developer had made an Android app wrapper around a WebView, and injected a JavaScript API into the WebView which exposes the Play Billing APIs to the website when running in that context. We are just streamlining the developer experience so they do not have to go to all that effort.

Is it possible/have you considered building a library to shim TWAs to expose this generically instead of writing the shim into Chrome? I would think that'd make this less controversial and allow for support of non-Chrome default browsers for those TWAs.

Giovanni Ortuño

unread,
Feb 19, 2020, 8:42:40 PM2/19/20
to samri...@google.com, blink-dev, yo...@yoav.ws, domi...@chromium.org, Ben Wells, harr...@chromium.org, rou...@chromium.org
On Thu, Feb 20, 2020 at 12:16 PM samrichard via blink-dev <blin...@chromium.org> wrote:
For (a), we do not consider this API to be part of the web platform. It won't be available to any site on the open web (the API simply won't exist). It will only be visible to an app that is listed in the Play Store, and only when the user has installed the app through the Play Store on a supporting device. That makes it effectively the same as if the developer had made an Android app wrapper around a WebView, and injected a JavaScript API into the WebView which exposes the Play Billing APIs to the website when running in that context. We are just streamlining the developer experience so they do not have to go to all that effort.

Is it possible/have you considered building a library to shim TWAs to expose this generically instead of writing the shim into Chrome? I would think that'd make this less controversial and allow for support of non-Chrome default browsers for those TWAs.


I believe this was asked earlier in the thread, so copying the response here:
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Matt Giuca

unread,
Feb 19, 2020, 9:07:13 PM2/19/20
to Giovanni Ortuño, samri...@google.com, blink-dev, Yoav Weiss, Dominick Ng, Ben Wells, Jay Harris, Rouslan Solomakhin
On Thu, 20 Feb 2020 at 12:42, Giovanni Ortuño <ort...@chromium.org> wrote:


On Thu, Feb 20, 2020 at 12:16 PM samrichard via blink-dev <blin...@chromium.org> wrote:
For (a), we do not consider this API to be part of the web platform. It won't be available to any site on the open web (the API simply won't exist). It will only be visible to an app that is listed in the Play Store, and only when the user has installed the app through the Play Store on a supporting device. That makes it effectively the same as if the developer had made an Android app wrapper around a WebView, and injected a JavaScript API into the WebView which exposes the Play Billing APIs to the website when running in that context. We are just streamlining the developer experience so they do not have to go to all that effort.

Is it possible/have you considered building a library to shim TWAs to expose this generically instead of writing the shim into Chrome? I would think that'd make this less controversial and allow for support of non-Chrome default browsers for those TWAs.


I believe this was asked earlier in the thread, so copying the response here:

I think that was a slightly different question ("why not build a REST API that can be accessed from JavaScript?" as opposed to "why not build a user-space library that is exposed via the TWA?"). The former would not go through the Android SDK; the latter would.

I am not too sure about how this would work on Android — maybe it is a good option there. But I am primarily interested in getting this working on Chrome OS, where we can't do that because the TWA doesn't actually run.

Rouslan Solomakhin

unread,
Apr 2, 2020, 6:04:45 AM4/2/20
to blink-dev, Matt Giuca, samri...@google.com, blink-dev, yo...@yoav.ws, Dominick Ng, benw...@chromium.org, harr...@chromium.org, Rouslan Solomakhin, ort...@chromium.org
Thank you, Matt, for getting the standardization conversation started at https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350!

Matt Giuca

unread,
Apr 2, 2020, 8:10:20 PM4/2/20
to Rouslan Solomakhin, blink-dev, samri...@google.com, yo...@yoav.ws, Dominick Ng, benw...@chromium.org, harr...@chromium.org, Rouslan Solomakhin, ort...@chromium.org
As a bit of background (since we have changed our position on this a lot since I last emailed this thread), we are now intending to take this API down the standardization route, which is why the Discourse post I am calling it a "digital product management API" (as opposed to "SKU management") and removing Google Chrome and Google Play specific mentions.

Thanks to everyone who contributed to get us to this point.

Yoav Weiss

unread,
Apr 3, 2020, 3:33:01 AM4/3/20
to Matt Giuca, Rouslan Solomakhin, blink-dev, samri...@google.com, Dominick Ng, benw...@chromium.org, harr...@chromium.org, Rouslan Solomakhin, ort...@chromium.org
Thank you!! :)

Matt Giuca

unread,
May 24, 2020, 10:56:56 PM5/24/20
to blink-dev, Rouslan Solomakhin, samri...@google.com, Dominick Ng, benw...@chromium.org, harr...@chromium.org, Yoav Weiss, Rouslan Solomakhin, ort...@chromium.org, gle...@chromium.org
Hi, another update on this API. The proposal is now in WICG and proposed as an open web standard, which is a long way from where we started as a proprietary Play Billing API exposed through Chrome.

We're now calling it "Digital Goods" API, and the implementation in Blink is being taken over by Glen Robertson (glenrob@).


We intend to take it to a TAG review shortly.
Reply all
Reply to author
Forward
0 new messages