Tess: we talked about this a week or 2 ago... We went back to them with some questions about using the payment request API... Basically they think we should have known the answer...

Hadley: my question still stands as to whether this gives you a blank check -... will look at it before we discuss again.

Tess: first non-design principles week of the new year...

Thoughts: this could be good for smaller creative artists (musicians, designers, etc), to have app stores that aren't the existing ones.

This could prompt the creation of more app stores, which is good for decentralisation. It could enable aggregation/search/discovery/similar services over the top of diverse digital goods app stores?

Have they thought about this use case, and is there anything in the design that would make this explicitly difficult?

What about other big stores than Play and Samsung? Other expected implementers like Apple, Kindle, Spotify..?

Concerns about the name, because it's so general.

Our comment

Amy: i left some feedback a while ago - i asked a question they haven't answered - about implementer buy-in.

Amy: ... there's a lot of people in their issues in this spec arguing that it's not needed...

Tess: no traction outside of their own ecosystem... we already have payment request API to buy things - typically showing a list of goods you can buy is... ... if amazon (e.g.) were to adopt this - would they want the browser to know about what products are on the page?

Amy: a bit confused - because they say it's not for payments, but they say it's so webapps can be listed in native app stores so that native app stores can use their payment processing.

Ken: we were the ones that asked them to run it through the TAG...

Hadley: if we do care about there being an ecosystem of app stores behind webapps then we should care about this being an API as part of the platform...

Ken: MS might be interested of this...

Amy: I get the impression that this API doesn't enable an ecosystem of app stores (diversification) but ties in to existing APP stores.

Hadley: it feels like this is a work-around because Play store won't do what they want.

Tess: app stores come and go, the web is enduring. We should be reluctant to add work-arounds ... for things. we will need to maintain it for compat even if the feature doesn't make sense any more. If the Play store has some specific limitationm, we shouldn't permenantly change the web to work around that.

Lea: absolutely.

Hadley: I agree although - but don't we have examples of where stuff has become open because we worked around closed things.

Tess: well with EME we reduced the proprietary surface... Yes sometimes - but it's something we resort to. There are lots of web sites on which you can buy digital goods. They use the table element and that seems to work fine. And they can use the payment request API.

Amy: is the difference that they don't want to be listed in the play store?

Tess: if the policy is that you have to use their pauyment processor then Chrome could sovle that by introducing a play store payment method - in the payment request API. That's doable today without any new API.

Dan: I agree...

see also: https://github.com/WICG/digital-goods/issues/5#issuecomment-63571822

[bumped to b]

Amy: sort of seems like this should be a library rather than a browser API.. a bit of a hack because stores like Play store don't want an http api for web apps to use

Yves: I thought it was for doing small payments without requiring too much verification, might be a good thing. Ask up front if you can spend that much and then an authorised prepayment and spend based on that amount...

Hadley: i'd rather spend pennies on a news article than ads and tracking. No API for that. It's not that.

... Amy said this is for smaller stores to compete with mainstream ones, and they're saying they're not interested in that. Maybe we should say they should be interested in that? or to evolve into that? A shame to end up in 6 months or a year having that conversation. Howo can the web better support payments for individual merchants, and have this API that's close but can't be extended

Amy: I'm not sure if they're not interested or they're planning to make it impossible.

I'm still struggling with this, and how to configure it to work with the specific digital goods store you want to use. To me, it feels like a library which covers different APIs for the different stores, to call the functions that you want to use for that specific store. But they're trying to essentially polyfill this, so you have one API for every store.

Is there a finite amount of stores this covers? It seems like hard coding the Samsung store and Play store? But what about the others we know about (and those we don't)?

Yves: I talked to Ian Jacobs for Web Payments WG, and he pointed me to an issue where Google wants to allow ammount-less payment. You want to buy something based on the SKU, not on the price.

Hadley: that sounds risky.

Yves: The plan is to get the details for the country you're in to get that, so it is a negotiation with hte store for the price.

Hadley: should we introduce them?

Yves: I think they are talking already.

Sorry about the delay. @hadleybeeman, @ylafon and I discussed this in our virtual face-to-face today.

> the UA needs to have custom code to interface with each store. Each store has a slightly different API

Given this, it seems like only a finite number of specific stores could be realistically supported.

1. How many stores are expected to be added,
2. and which ones so far are involved?
3. Are all browsers expected to support the same set of stores, or is it likely that users will get a different experience in different browsers? 
4. Which browsers have expressed intent to work on this?

We're a bit concerned about further entrenching the 'big player' stores. In the explainer this is compared to the Payment Requests API, as there are a finite number of supported payment providers. We're not sure this is a fair comparison, as in practice anyone can spin up a web store to sell digital goods, and as payment providers face regulatory limitations, this pattern should be an exception rather than something to be repeated.

> I'm not sure "Lookup/Listing" is broad enough

It sounds a bit like you're saying payment is both in and out of scope of this API. If this API passes payment to the Payment Request API, then I think it's okay for the name of this API to be less broad. Something like the Digital Goods Inventory API? (Which a developer can expect to use before calling the Payment Request API?)

Hadley: naming issue.. saying payment is in scope for this API even though it's separate from the payment API doesn't make sense to me..

Amy: agreed

... Also related: https://github.com/w3ctag/design-reviews/issues/512 - changing the Payment Request API for the Digital Goods use case

Amy: explainer compares it to payment request API because sites need to integrate with individual payment providers, but I don't think that's fair because there are far fewer payment providers than ptentially stores

Hadley: not a pattern we want to enable, payment request API is an exception

Amy: seems to entrench existing powers

Hadley: plus it's just not scaleable. Payment providers are limited by regulatory things..

Amy: anyone can spin up a web store

Hadley: unfortunate compromise we had to make for payments, but be great not to make it anywhere else. Should have a design principle discussion around it.

[bumped]

Still waiting for feedback, punte

Dan: there is a reply from the requesteor.

Tess: it's very worrisome that it's only Chrome and the play store that are are working on this or interested in it.

Dan: can we say "this shouldn't be part of the web" - but is more of a chrome thing.

Hadley: lack of other implementer interest means it's a chrome thing.

Tess: sometimes things end up being web things - maybe this will go well - if there is a lot of demand for it. Or maybe we will get feedback from another browser that they want to implement - which could be a signal for standardization. So it feels premature to standardize.

Peter: it's always been fine for individual products to experiment - or have a proprietary feature - but when it steps on a standardized name space.. should we recommend they use a chrome specific name for the API?

Tess: would html be better off today if the canvas element were named apple-canvas? Unlike canvas, this seems like a proprietary feature for chrome to integrate with google play.

Dan: could it be similar to the Enterprise api... managed device web api... talks about the "Chrome API"... Is this in WICG? [yes] Why is it even in WICG if it's totally Play and Chrome based...

Hadley: in the explainer they do analyze the samsung in-app purchase API. But see no evidence that they have talked to Samsung [or any other third party].

Thanks, @phlogenix. We've looked at this again in our W3C TAG breakout session.

Given that only Chrome has expressed interest in this, and Google Play Store is the only store that you're working with -- we're not sure this is a standardisation effort. It looks like a product-specific API within one company.

In that light, we are proposing to close this review, and we recommend you name this API something specific to Chrome or the Google Play Store, for example something like "Chrome Digital Goods Inventory API". Alternately, you could engage with some additional parties now and design a higher level API, covering multiple stores.

We wish you luck in incubating and trialing this API. Please do come back to us if you get interest from other parties and are looking to make this a web standard that interoperates with other browsers and stores.

Rossen: proprietary or non-proprietary name?

Tess: canvas is a general purpose api - this isn't. This feels like "chrome wants to expose the google play API."

Rossen: if it's a functionality for allowin in app purchases - digital goods could be generic and underneath there could be google play or propietary. That way if it cathes on there would be the long lived API...

Hadley: if we did that who is going to design the higher level API when no 3rd parties at the table.

Rossen: yes - we want to have the higher level API - but they are designing one API. If they are up for it they should bring more folks to the table and design the higher level API.

Hadley: I agree, but I don't see how that can happen without multi-implementer group coming together..

Amy: doesn't seem like much has changed wrt fundamentals, only API shape

discussed and left a comment asking if there has been any further info on implementations

Dan: I asked a question after last week's call. Didn't look like it's moved on from being a product specific API. That's the basis on which we closed the issue previously. We were requested to reopen it because of API changes. But the reason we closed it was the one vendor issue.

Tess: and that's still the case

Dan: so close it again?

Tess: assuming our original rationale was valid I don't see why it doesn't apply now. Could argue we should review it more closely because if chrome ships it and if everyone else decides to do it they will have to implement it that way. But not inclined to spend time reviewing a google only thing.

Dan: [leaves comment]

closed