Non-Platform Digital Goods Services

[adrianhopebailie]

Based on the example code:

const itemService = await getDigitalGoodsService();
if (itemService === null ||
    itemService.paymentMethod !== "https://example.com/billing") {
    // Not using our preferred item service.
    // Use a normal web-based payment flow.
    return;
}

It appears that only a single Digital Goods Service would be available under a particular context. E.g. If I am browsing the same website on my Samsung phone and then on my Android phone the call to getDigitalGoodsService() will return a handle to the Samsung Galaxy Store in the first instance and a handle to the Google Play Store in the second instance.

How could a Digital Goods Service that is not integrated into the underlying platform be accessed via these APIs?

As an example, I may have an application that sells subscriptions. When users purchase subscriptions through my native app they do it via the app store on that platform but when they buy subscriptions via the Web app they do it via a subscription management service that is accessed via the Web. (E.g. https://www.chargebee.com/).

How do I access my existing subscription management service via this API?

[danyao]

This is an interesting point. What if Digital Goods Service can be identified by a URL similar to Payment Method Identifier [1]? This would allow an extensible architecture of multiple Digital Goods Service backends.

const itemService = await getDigitalGoodsService('https://example.com/billing');

[1] https://www.w3.org/TR/payment-method-id/

[mgiuca]

I think that's a reasonable modification, and makes it more consistent with the Payment Request API. (We can remove paymentMethod and just assume that if getDigitalGoodsService returns null, then the browser does not support the given payment method.)

I am very open, in principle, to extending this to third parties. However, I'm curious how Digital Goods API would interact with a third party service that isn't affiliated with the browser. Presumably such a service would have a REST API which is expected to be embedded into the app's page. The whole reason for this API's existence is to talk to stores that don't have a REST API, instead having a native API that the browser can talk to but the website isn't able to (e.g., the Google Play Billing API). What value would the DG API provide to a third party service that can't be exposed via a REST API?

In any case, I think what @danyao suggests here is probably a better design (it allows the browser to potentially expose multiple different stores within the same session) and I'm open to changing to it.

[mgiuca]

Put up a PR #9 to do Danyao's suggestion.