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
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
--
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.
Hi Yoav,Can you clarify what "this case" is that you're referring to?
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.
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.
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?
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?
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.
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.
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?
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.
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 (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.
--
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/eaf756b6-3e9f-452e-950f-16871d5ac6f5%40chromium.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:
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMDKGBWPu_p-Owu4RML%2B0omJt7EsAaevxijE9w3%2ByVB1utao5w%40mail.gmail.com.