None yet. Have a spec mentor and aiming to do this by M96 stable.
An API for querying and managing digital products to facilitate in-app purchases from web applications, in conjunction with the Payment Request API (which is used to make the actual purchases). The API would be linked to a digital distribution service connected to via the user agent. In Chrome, this is specifically a web API wrapper around the Android Play Billing API.
TAG recommends making a Chrome-specific API. Other issues addressed.
Similar to Payment Request: this API is used to talk to specific store backends, and so its usage is tailored to the specific store. The reason it's a proposed web standard is so that the same code (which is specific to one store) is portable across browsers.
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/349)
WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-October/032001.html)
Microsoft: Initial discussions, no public signal yet (has been requested).
Samsung: Initial discussions, no public signal yet (has been requested).
Web developers: Positive (https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350)
44/61 responses of "extremely likely" to continue to use the feature from v1.0 OT
36/61 responses of slightly-to-extremely easy to use the feature (and 12 neutral) from v1.0 OT
Used in tandem with the Payment Request API.
- General API design. Determine whether developers need to access more data that would be exposed through the Play Billing API but is not exposed through our web API.
- Specifically, we have significantly reduced the API surface for v2.0, and would like to know if it is still acceptable for developers.
- We would also like to know whether the API is suitable for abstracting over other non-Play stores. While running an experiment with the current implementation won't tell us this, it will set up real-world clients and we can then try their sites on other implementations.
An origin trial ran from M88 to M95 and found some areas of developer friction and new features needed (see bugs labeled https://bugs.chromium.org/p/chromium/issues/list?q=label%3ADGAPI). We also found potential fraud issues in the v1.0 API.
The v2.0 API fixes several of the developer issues raised, and fixes the known fraud issues. However, this is a significant change to the API surface. We would like to know if the updated API is still acceptable for developers.
We have had several requests from developers to make the API easier to debug, but it is difficult due to the interaction with a backing service based in an app/store context. We are looking for suggestions on how we might improve the debuggability of the API.
No, Android and Chrome OS only (the two platforms where we have Play Store integration).
No. The JS<->mojo interface (Blink code) is tested but the backing app/store context is unavailable in WPT.
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/vkS3k30lWNs
Intent to Experiment (DGAPI v1.0): https://groups.google.com/a/chromium.org/g/blink-dev/c/syI9_M9dANY/m/3lt-QGMHAgAJ
Intent to Continue Experimenting (DGAPI v1.0):
This intent message was generated by Chrome Platform Status.
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/CAEK7mvpq1krCWQfTc_hi1mRSW9rwznRScDWa4dyUQPGPYt2jtQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV%2BSg_%3D%3DywYCB%2B6ZsaXAndHpX9c_c_mBtU47KBEmX6Qm1J6vA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUmYkZGF%2BYcnArrcvgTAkpYmWD2ztRcDtp9HvUW__jvWg%40mail.gmail.com.