Don't use PaymentRequest

[adrianhopebailie]

It's not clear why this API needs to use the PaymentRequest API at all. The changes that this requires to Payment Request API changes the nature of that API from a payment API to a purchase API.

The whole point of the PR API is to allow a website to request a payment from the user when the website doesn't know yet what payment methods are available to make the payment.

This API only works if the user is using a browser connected to a specific Digital Goods Service.

Why not simply add a purchase method to the DigitalGoodsService?

Example:

const details = await itemService.getDetails(["shiny_sword", "gem"], "one_time");
// Show details to user
const purchaseToken = await itemService.purchase(details)

[mgiuca]

That's an interesting alternative approach, which I think deserves some thought.

My initial reaction is that we do want to use PR here, and not define a new way of making a purchase. There's a lot of infrastructure set up to deal with payments in PR which we'd have to duplicate here. A purchase of a digital good is still a payment. It has all the semantics of making a payment, including the presence of a "total" in the user's currency. The only difference is that "total" is not passed in as a parameter from the site, rather, it is transmitted to the payment provider out-of-band (e.g., by the developer configuring it in an admin console).

[rsolomakhin]

Having two different APIs for purchases on the web seems awkward at best.

[marcoscaceres]

So the intent is to have a particular kind of payment handler deal with these (in the context of a payment sheet)... if so, it would make sense.

Alternative is what @adrianhopebailie suggests... you pull the purchase details from the itemService, and then one could (in theory) construct a conforming Payment Request, including the total. Or is the intent to hide how much things cost from the requesting website?

[rsolomakhin]

@marcoscaceres wrote:

The intent is to have a particular kind of payment handler deal with these.

Correct. There're several payment apps that work this way out there. For example, https://github.com/j3k0/cordova-plugin-purchase#getting-started lists out:

• Apple:
  • In-App Purchase Introduction
  • Auto-Renewable Subscriptions
• Google:
  • In-App Purchases Best Practices
  • Billing Overview
• Microsoft
  • Monetize with In-App Purchases

@marcoscaceres wrote:

Or is the intent to hide how much things cost from the requesting website?

No, the website knows the price through the digital goods service and typically displays it for the user to see.

[marcoscaceres]

Awesome, thanks for the examples!

[mgiuca]

No, the website knows the price through the digital goods service and typically displays it for the user to see.

To expand on this: while the website knows the price through the digital goods API (as an output of that API), we don't want to require the site to send the price back into the system (as an input to payment request), which would be redundant, since the system already knows the price of the item. (Then we'd have to specify what happens if you ask to buy an item for $X dollars when the server knows it costs $Y dollars.)

[marcoscaceres]

@mgiuca, yeah, that makes sense. Thank you.

@adrianhopebailie is correct in that this proposal does modify the Payment Request API to (also!) become a "purchase API"... but that's probably ok so long as it doesn't prevent the PR API to continue to function as a "payment API".

That is, we get "the best of both worlds"... and that's good, right?

[adrianhopebailie]

Then we'd have to specify what happens if you ask to buy an item for $X dollars when the server knows it costs $Y dollars.

This problem still exists. What if I query the server and get told the item costs $X but when I submit the purchase through the PR API I get charged $Y?

[adrianhopebailie]

Are any of these assumptions I'm making incorrect:

• The website has a pre-existing relationship with the digital goods service
• Before calling PR API the website already knows which digital goods service is available

This use of the different APIs still feels very awkward to me. Why would I use browser APIs to communicate with a back-end service that I could just as easily communicate with using fetch()?

[samuelweiler]

My intuition matches what @rsolomakhin says above:

Having two different APIs for purchases on the web seems awkward at best.

I have some clarifying questions:

The changes that this requires to Payment Request API changes the nature of that API from a payment API to a purchase API.

1. What are those changes?
2. Why would that be bad?

(Then we'd have to specify what happens if you ask to buy an item for $X dollars when the server knows it costs $Y dollars.)

This edge case seems similar to those that need to be handled anyway. e.g. failed payments, out of stock ("no more shiny sword for you!"), and charged-back payments. Is it so unique that it warrants a new API?

[adrianhopebailie]

My intuition matches what @rsolomakhin says above:

Having two different APIs for purchases on the web seems awkward at best.

Then why is the Digital Goods API (for purchasing digital goods) a different API to the Payments API (for making payments)?

We are already fighting with the privacy implications of the payments API having too much non-payments functionality (shipping address, email, etc) and now we want to start supporting more non-core use cases?

What are those changes?

Linked in the explainer: w3c/payment-request#912

Why would that be bad?

The Payment Request API is for requesting a payment, irrespective of how that payment is processed by the user. The proposal is to remove the amount and submit payment requests that can ONLY be processed by the app store. If the payment can only be processed by the app store, why submit them via a browser API at all, just submit them directly to the store via fetch? The change is unnecessary and adds complexity where it can be avoided.

This edge case seems similar to those that need to be handled anyway. e.g. failed payments, out of stock ("no more shiny sword for you!"), and charged-back payments. Is it so unique that it warrants a new API?

Correct. So we shouldn't change the whole nature of the Payments API to avoid this edge case. If the website knows what the shiny sword should cost it should request that amount from the API.

[danyao]

My intuition matches what @rsolomakhin says above:

Having two different APIs for purchases on the web seems awkward at best.

Then why is the Digital Goods API (for purchasing digital goods) a different API to the Payments API (for making payments)?

The Digital Goods API as proposed here is primarily an API for consuming and acknowledging digital goods that are already purchased. It still relies on the Payments API to facilitate the "buy flow": i.e. invoking the relevant digital store as a payment app and taking user through that payment flow.

If we don't use Payment Request API, then the Digital Goods API would need to provide facilities for invoking a buy flow. This would lead to a more confusing state with two different APIs for making payments on the web.

What are those changes?

Linked in the explainer: w3c/payment-request#912

Why would that be bad?

The Payment Request API is for requesting a payment, irrespective of how that payment is processed by the user. The proposal is to remove the amount and submit payment requests that can ONLY be processed by the app store.

We are proposing that there is a category of payment methods that does not require a price as input. When a developer creates a PaymentRequest for such a payment method, we'd like to give them the convenience of not having to specify a total. In this case, the developer is choosing to only have the payment request processed by the app store.

However, if a developer creates a PaymentRequest with two payment methods, say "https://example.com/billing" and "https://bobpay.xyz/pay", where one of them actually requires "total", then the browser will throw an exception if "total" is not specified.

If the payment can only be processed by the app store, why submit them via a browser API at all, just submit them directly to the store via fetch? The change is unnecessary and adds complexity where it can be avoided.

In this particular case, fetch cannot be used because the entity processing the payment is a platform-specific service that does not currently provide a REST API. Technically, this is no different from other platform-specific services that are exposed through the browser such as USB, geolocation, etc. The only difference is that billing can perhaps be conceivably exposed via a REST API. But this is just not the case today.

This edge case seems similar to those that need to be handled anyway. e.g. failed payments, out of stock ("no more shiny sword for you!"), and charged-back payments. Is it so unique that it warrants a new API?

Correct. So we shouldn't change the whole nature of the Payments API to avoid this edge case. If the website knows what the shiny sword should cost it should request that amount from the API.

Just to re-iterate, the primary reason why Digital Goods API need to exist is because it does not make sense to jam the acknowledge() method, which is an integral part of a digital goods flow, into Payment Request API. Making "total" optional is merely a convenience for developers.

Today, not all native apps that make use of in-app-purchase query item details before invoking the buy flow. For example, a game may show "buy gem" without showing the price. So we could tell these developers to simply use a dummy "total", but that would seem pretty odd, wouldn't it?

[marcoscaceres]

this still feels kinda weird... I'm still not really convinced that communication with the DigitialGoodsService can't just happen over the fetch API? I.e., if you have the PMI for DigitialGoodsService, why not ping it directly to interrogate it about items details?

[mgiuca]

@marcoscaceres There's really only one reason for this to exist, and it's a kinda dumb one, but these stores often do not provide REST endpoints. (Such as the Play Store.) They are designed to be called from native apps on their respective systems, so they provide Java APIs or whatever native SDK is used.

If we could get them to expose REST endpoints, then there wouldn't be much need to have this API exposed by the browser. But the fact is, there is no other way that we can facilitate a website to talk to a private system API like this, than to expose it through the browser.

I think @danyao put it best above:

In this particular case, fetch cannot be used because the entity processing the payment is a platform-specific service that does not currently provide a REST API. Technically, this is no different from other platform-specific services that are exposed through the browser such as USB, geolocation, etc. The only difference is that billing can perhaps be conceivably exposed via a REST API. But this is just not the case today.

[marcoscaceres]

@marcoscaceres There's really only one reason for this to exist, and it's a kinda dumb one, but these stores often do not provide REST endpoints.

Ok. I missed @danyao comment! Sorry, about that. Ok, let's go with the model whereby it's a system service that is the same as Geolocation (e.g., browser talks to "Skyhook" or whatever... I think that's what Firefox does IIRC).

It seems feasible that interrogating the DigitialGoodsService would give a developer a PaymentDetails (including total) that could just be plugged into PaymentRequest.

The Payment Handler itself could then just discard total (or display adapt it specifically for the end-user) without the need to modify the Payment Request API?

[marcoscaceres]

One clarifying question: if I have a random site (e.g., marcosc.com) and I call this API, how does the DigitialGoodsService know that my site is allowed to communicate with it? Do I need to pre-register my site (I'm guessing, yes)?

I guess I'm wondering because there seems to be a lot of parallels to how this works and how Apple Pay works with respect to setting up a site. <-> payment handler relationship.

So, I can understand the "does not provide REST endpoints" issues... but if I need to establish a "B2B" relationship between marcosc.com, and, say, (system) bobpay.com, then why not also establish the REST endpoints between the servers? That just seems like, um, "laziness" on the part of the Payment Handler provider and not a technical or security constraint.

[mgiuca]

It seems feasible that interrogating the DigitialGoodsService would give a developer a PaymentDetails (including total) that could just be plugged into PaymentRequest.

Interesting idea...

Do I need to pre-register my site (I'm guessing, yes)?

Yes, that would be up to an out-of-band relationship between sites and payment servers. Which is much the same as how you need to set up an out-of-band relationship between your site and a payment handler in the Payment Request flow.

That just seems like, um, "laziness" on the part of the Payment Handler provider and not a technical or security constraint.

That's true, but we aren't in control of that. As spec writers / browser vendors, we can only write specs and implement browser APIs. I agree, it isn't ideal, but it's a solution to a problem that would not otherwise solve itself.

[marcoscaceres]

Yes, that would be up to an out-of-band relationship between sites and payment servers.

Similarly, an argument could be made that a digital-goods service query relationship could be established out-of-band: if one is setting up a bunch of certs to verify that a payment went through, then surely one can set up a simple service to query for digital goods info, no?

For example, marcospay.com would just provide "awesomegame.com" an API key. Then awesomegame.com can do as many digital-goods lookups server-to-server as it wants.

That's true, but we aren't in control of that.

In a way we - spec writers / browser vendors - can be in control of it: we can say, "we have this really nice Fetch API that allows you to do all that you want: if you kindly expose a REST API, it will do everything that you need and more! < fetch API sales pitch goes here ... extensible web manifesto ramble here... jazz hands... jazz hands... >... and that's why fetch() is REALLY what you actually want.".

Note that the "merchant validation" can still happen within PaymentRequest (already supported/spec'ed), which is nice. This allows PaymentRequest to work with built-in/native payment handlers and web-based Payment Handlers. It's not exactly a digital-goods API, but it does solve some of the puzzle.

As spec writers / browser vendors, we can only write specs and implement browser APIs. I agree, it isn't ideal, but it's a solution to a problem that would not otherwise solve itself.

In a way, it could: sites can just use whatever payment handler they want right? What's preventing them from just using, say, a hypothetical marcospay.com (which could also provides a nice REST API for getting details)?

[mgiuca]

In a way we - spec writers / browser vendors - can be in control of it: we can say, "we have this really nice Fetch API that allows you to do all that you want: if you kindly expose a REST API, it will do everything that you need and more! < fetch API sales pitch goes here ... extensible web manifesto ramble here... jazz hands... jazz hands... >... and that's why fetch() is REALLY what you actually want.".

Right, but you'd be making that pitch to an app store operator who is primarily interested in running a store for native apps. There is no incentive for them to build and maintain a whole separate entrypoint to their API just for PWAs. We're the ones who want this, so we need to build it.

In a way, it could: sites can just use whatever payment handler they want right? What's preventing them from just using, say, a hypothetical marcospay.com (which could also provides a nice REST API for getting details)?

Unfortunately, that wouldn't be an option in the use case I'm considering. (As outlined at the top of the explainer,) if your app has been listed in an app store, and installed via that store, the store policy would prevent you from being able to accept payments for digital goods outside of their billing API. So you could not use marcospay.com. That's why this is so important for us: right now, PWAs listed in the Google Play Store are prevented from accepting payments in any way. This API enables that.

Note that the API spec as proposed does not have this restriction built into it (for example, you could make a marcospay.com digital goods provider). It's just that in the specific context of a PWA installed via the Play Store (or another app store), you wouldn't be able to use another digital goods provider.

[marcoscaceres]

That's why this is so important for us: right now, PWAs listed in the Google Play Store are prevented from accepting payments in any way.

Ok, that's extremely unfortunate. The question to ask is if it justifies adding an API to the Web Platform (i.e., ideally to every web browser) because of the policy of a particular app store? an important store, but still...

We're the ones who want this, so we need to build it.

I understand that Chrome needs this, but let's put this in the context of the wider Web Standards project.

Like, how do I go and sell this to Mozilla to get it added into Gecko? By adding this API, we would be kinda shooting ourselves in the foot to placate a Google problem, right? because essentially Google's Play Store is forcing developers to use a Google Payment Solution to be listed in a Google Store at the exclusion of all other payment solutions - and by being stubborn, Google Play is forcing Google Chrome to add this API. And not for any valid technical reason, but because of a policy which they could change tomorrow.

Although convenient that this policy is expressed as a browser DigitalGoods API, that level of centralization seems harmful to the Web.

I'm not saying you shouldn't add this to Chrome, but is this really a "web API" or a "Play Store API"?

Note that the API spec as proposed does not have this restriction built into it (for example, you could make a marcospay.com digital goods provider). It's just that in the specific context of a PWA installed via the Play Store (or another app store), you wouldn't be able to use another digital goods provider.

Right, but gets us back to the whole Payment Handler, or general web platform, integration discussion. If we put aside the Google Play Store policy, it still appears that fetch addresses all the technical use cases.

So, policy aside, is there any technical reason for this API to exist?

[mgiuca]

Ok, that's extremely unfortunate.

Agreed.

I understand that Chrome needs this, but let's put this in the context of the wider Web Standards project.

Noted. I should be more careful when I say "we".

Chrome wants this, for sure. But I was trying to mean "we" the greater web platform community. I think it should be our goal to try and work with app stores and not wall ourselves off. We hear a lot from developers that the decision to make a PWA vs a native app often comes down to "will it appear in the major stores"? I hate it when they're making this on a "how can people find my app" basis, rather than based on the technology, but it's the reality. Stores have very little incentive to carry web apps (since they're primarily focused on native apps). On the other hand, we (the web community) have a lot of incentive to have stores list the apps built with our platform. So I believe it is in our best interest to cooperate.

Like, how do I go and sell this to Mozilla to get it added into Gecko? By adding this API, we would be kinda shooting ourselves in the foot to placate a Google problem, right?

I believe Firefox is looking into TWAs, right? I'm not sure on all the details here, but it's possible that installing an app from the Play Store could use Firefox as the engine, if it's set as the user's default browser. (I could be mistaken... I don't know exactly what the policy is here.) If that's the case, Firefox would serve the exact same role as Chrome: as an intermediary between the website and the store. Firefox would have to implement this API, otherwise if the user is using Firefox, those websites would not be able to make purchases if installed via the store. That's ultimately why we decided to take this to WICG and not just expose it in Chrome: because as with any web API, it enables a website to use the service regardless of which browser the user is using.

Although convenient that this policy is expressed as a browser DigitalGoods API, that level of centralization seems harmful to the Web. ... I'm not saying you shouldn't add this to Chrome, but is this really a "web API" or a "Play Store API"?

This isn't intended to be Play only. The same could apply to the Samsung Store, or any other app store. It's a similar centralization model to Payment Request itself. It's not a truly open API that works with any backend. The site needs to interop specifically with this store or that store. But by making a standard API, at least the site doesn't also need to interop with this browser and that browser. They can use a standard interface to talk to the Play Store, or the Samsung Store, for example.

Background context: we did originally design this as a "Play Store API" (see this thread). But our web platform folks rightly suggested that this wasn't exclusive to Chrome, or the Play Store, and so we should take it through the public standards process. So here we are, four months later :)

If we put aside the Google Play Store policy, it still appears that fetch addresses all the technical use cases.

I consider it to be a technical barrier (not a policy barrier) if a web developer would be unable to integrate with a store unless they can convince the store to build a whole new API. Doing so would be out of the developer's hands. Thus, I propose an API that would empower the developer to integrate with that store without needing that store to change the way they operate.

[marcoscaceres]

Thanks @mgiuca for the additional details. Mozilla is only experimenting with TWAs, but would being a TWA prevent a browser engine from providing additional built-in payment handlers (e.g., let's say Firefox was a TWA but it also has built-in support for other payment solutions/handlers)? ... or would that render Firefox an "untrusted web activity" and get it booted from the Play Store?

It be great to hear from other folks about what they think. @adrianhopebailie?

[adrianhopebailie]

The assertion that stores have no incentive to solve this has come a lot:

There is no incentive for them to build and maintain a whole separate entrypoint to their API just for PWAs.

and

Stores have very little incentive to carry web apps (since they're primarily focused on native apps).

I don't agree with this. Stores are incentivised grow their ecosystem, which is a two sided market. They want to attract developers so their store gets more good apps which attracts users. They want to attract users so they have a wider distribution platform which attracts developers.

Attracting developers means giving them the best tools to build and make money from their apps and the widest distribution platform.

The size of the Web developer community far exceeds the native app community so if you are attracting Web developers to your platform you have a much larger addressable market.

You attract Web developers by giving them the same features and services you give native app developers, in this case the ability to sell digital goods and subscriptions with very low user friction.

So, I would argue that there is a strong incentive for app stores to provide Javascript SDKs to PWA developers so they can access the store's services from the Web.

Presumably this would still require that the developer has an app store account and be subject to same terms when accessing these services as they would in the app store.

The real problem I think this API solves is allowing the app store to enforce their terms.

If apps use digital goods services via the APIs on the Internet (vs via a browser API) it's impossible for the app store to know if the app was loaded via the app store (and is therefor subject to the app store terms) or via the Web. This presents two problems:

1. the app store may not want the app to be able to use the app store services if it was not loaded via the app store as there is no guarantee the user has an app store account.
2. the app store does not want the app to offer the user alternative ways to pay for the digital goods or subscriptions if the app was loaded via the app store (as these are the app store terms).

I believe what we really want, to start with, is a solution to problem 1.

Apps need a way to get a handle/pointer to the app store user id of the user using the app. If this is not present then the app knows it is being accessed outside the app store context and is not subject to the app store's terms. It should also not attempt to use the app store's services (it likely won't be able to without a handle/pointer to the app store id of the user using the app).

It will then be up to the app stores to decide how (or if) they enforce their policies around preventing apps from accessing competitive services when in an app store context.

A positive side-effect of this is that app stores that embrace this potentially extend their total addressable user market beyond their native platforms.

For example, an app that is written for the Web but also distributed via an an app store may prefer to use the app store's digital goods services even when accessed via the Web on a desktop device simply because it is a great user experience.

App stores could enable this by simply making it easy for users to sign up for an account via the Web (which I think they all support already).

[danyao]

I think there's a misconception here that the Digital Goods API as proposed would somehow only benefit the Play Store and hurt the open web. Here are the reasons why I believe it is not true:

1. Digital Goods API does not mandate a particular app store backend. With Modify interface to allow client to choose which service to connect to #9, developer can choose which app store they want to use, akin to how Payment Request API allows a payment handlers to be selected via a payment method identifier. Before Modify interface to allow client to choose which service to connect to #9, Matt and I had thought that giving browsers the choice of which app store backend to offer would be a good starting point (like how search engines were initially baked into the browser) and we can trivially open it up when demand from alternative app stores show up. So I'm glad that @adrianhopebailie mentions Coil's interest in participating in digital goods and now that we're starting with supporting multiple stores at the get-go.

2. The web platform benefits when web developers can easily include in-app-purchase experiences in their apps and I believe the Digital Goods API provides a good solution. The fact that the first app store that is ready to integrate with Digital Goods API to bring a low-friction IAP experience to the web is the Play Store, is just a recognition that the native ecosystem is a few steps ahead and browsers can help bring these better experiences to the web platform by acting as a bridge between web apps and native services, to level the playing field between web developers and native developers.

Like, how do I go and sell this to Mozilla to get it added into Gecko? By adding this API, we would be kinda shooting ourselves in the foot to placate a Google problem, right?

I think Gecko should consider this proposal for the same reason it should consider Payment Request API. It will help developers build better commerce experiences on the web for users. The Internet has been likened to a bazaar [1]. A bazaar is not a showroom: vendors and users have to be able to not only discover each other but complete transactions. IMHO, the web is becoming more like a showroom these days and users are having transactions where it is easy to do so. Developers are following them. They may not come back one day. So it is on us, the web platform community, to offer developers the right tools to build a great bazaar to attract the users back.

because essentially Google's Play Store is forcing developers to use a Google Payment Solution to be listed in a Google Store at the exclusion of all other payment solutions - and by being stubborn, Google Play is forcing Google Chrome to add this API. And not for any valid technical reason, but because of a policy which they could change tomorrow.

This may be the immediate cause, but the bigger issue is that developers want to be listed in app stores. That's what gives app stores this leverage. This is also why I respectfully disagree with @adrianhopebailie 's comment:

If apps use digital goods services via the APIs on the Internet (vs via a browser API) it's impossible for the app store to know if the app was loaded via the app store (and is therefor subject to the app store terms) or via the Web. This presents two problems:

1. the app store may not want the app to be able to use the app store services if it was not loaded via the app store as there is no guarantee the user has an app store account.
2. the app store does not want the app to offer the user alternative ways to pay for the digital goods or subscriptions if the app was loaded via the app store (as these are the app store terms).

I believe what we really want, to start with, is a solution to problem 1.
...
A positive side-effect of this is that app stores that embrace this potentially extend their total addressable user market beyond their native platforms.

We are not fundamentally solving an app store problem. They were not the ones who came to us asking for this API. We are solving a web developer problem: they want to list in app stores (partially because there's no good way to monetize on the open web besides ads) and they don't have good ways to build IAP flows. I think as tool builders, we can tackle this problem two ways:

• Build web alternatives to the app stores, including payments and IAP functionalities exposed as web services.
• Build bridges to bring the best of the native world to the web, as a stop gap.

Folks like Stripe, PayPal are doing a great job pushing the first front, especially for regular sized transactions. They are not addressing the IAP use cases (yet?). Coil is making good strides for IAP-type experiences. But solutions are both few and far between today and fragmented, so it is hard for web developers to adopt. I hope Digital Goods API will become a standard access point for web developers to access all IAP providers.

That said, the first way takes time. In the mean time, browsers can help "import" good native experiences to the web. I believe integrating Play Store behind Digital Goods API is a good first step, as long as we take care to make sure we choose a design that's extensible, so when the pure-web solutions become available, they can easily plug in as well, and the developers get upgrade for free.

I feel the pushbacks on this thread are calling for the former path at the exclusion of this second path, which I believe is putting theoretical purity ahead of user and developer needs, and will have the consequence of making the web fall further behind on the commerce regard.

I hope the proposal authors' intention to keep DG API an open solution is evident in that we designed it to work in conjunction with Payment Request API. If we (the evil Google guys??) really want to push a Play Store only solution to lock the web out, it would have been much easier to create a Google specific API for Play Store in Chrome behind closed doors and not be having this conversation at all...

Although convenient that this policy is expressed as a browser DigitalGoods API, that level of centralization seems harmful to the Web.

Perhaps we should have proposed #9 from the start... Does this PR address your concern that Digital Goods API is not sufficiently open?

[1] http://www.catb.org/~esr/writings/cathedral-bazaar/

[marcoscaceres]

1. Digital Goods API does not mandate a particular app store backend.

In a way it does... it again centralizes and privileges payment solutions to the ones provided/installed on the OS or by the browser. This is the same problem with including the default search engines lists... yes, they are useful (and make a lot of money for browsers, including Firefox!)- but they privilege those who already dominate the market or have pre-arranged deals with browser vendors. Replicating that model doesn't seem great, and relegates everyone else who wants to compete in this space to be second-tier.

2. The web platform benefits when web developers can easily include in-app-purchase experiences in their apps and I believe the Digital Goods API provides a good solution.

On the face of it, this is true - but there is nothing special about the Digital Goods API experience that couldn't be replicated with a simple <script> tag and some JS + existing web platform APIs. Irrespective of JS or browser API, distribution of the web application would need to happen through a particular App Store, and we are again back to centralizing control and choice.

I think Gecko should consider this proposal for the same reason it should consider Payment Request API....

I don't disagree with anything you stated here, but I don't see how this technically is superior to just using fetch(). I know I'm being super repetitive.

This may be the immediate cause, but the bigger issue is that developers want to be listed in app stores.

This may be true for some developers, but not all developers. I can agree that developers want to be where people can find their apps. How users find apps vary a lot.

I feel the pushbacks on this thread are calling for the former path at the exclusion of this second path, which I believe is putting theoretical purity ahead of user and developer needs, and will have the consequence of making the web fall further behind on the commerce regard.

But there is nothing particularly fancy about this API that solves "hard problems" developers have right now. It's literally a method call that gives you back and object. Like, if this was doing a whole bunch of super fancy complicated browser stuff behind the scenes (like Payment Request/Handler does), then I'd be inclined to agree with you here... but this is just a network call to get some digital goods info from PMI-like URL? Why not just skip that and go directly to the source?

If we (the evil Google guys??) really want to push a Play Store only solution to lock the web out, it would have been much easier to create a Google specific API for Play Store in Chrome behind closed doors and not be having this conversation at all...

Hey! I won't have you saying bad things about my favorite Googlers! (but seriously, this is totally not where I think @adrianhopebailie and I are coming from... I'm just trying to say "we have the technology, let's just use it"... it's more, "Marcos is lazy... he doesn't want to build new APIs unless he really really has to".)

Perhaps we should have proposed #9 from the start... Does this PR address your concern that Digital Goods API is not sufficiently open?

I don't feel it does... at least without the Payment Handler plan?

[mgiuca]

Hi Marcos,

Just on the technical notes:

On the face of it, this is true - but there is nothing special about the Digital Goods API experience that couldn't be replicated with a simple <script> tag and some JS + existing web platform APIs. Irrespective of JS or browser API, distribution of the web application would need to happen through a particular App Store, and we are again back to centralizing control and choice.
...
I don't disagree with anything you stated here, but I don't see how this technically is superior to just using fetch(). I know I'm being super repetitive.

It isn't possible to communicate with the Play Store, and possibly other stores, using JavaScript and fetch(). That's simply a technical impossibility, because they do not expose a REST (publicly accessible HTTP) endpoint.

We can argue about what it would take to have them change their server to support this, or the merits of us simply not supporting those stores since they aren't willing to "play ball". But that is the ask we're getting from developers, and the problem we're trying to solve. We're proposing a solution here. We're open to other solutions, but "just do it in user space" is not a functioning solution to the problem.

This may be the immediate cause, but the bigger issue is that developers want to be listed in app stores.

This may be true for some developers, but not all developers. I can agree that developers want to be where people can find their apps. How users find apps vary a lot.

The bar for whether an API is useful enough is not "all developers". It's always "some developers". The question is how many (enough to make it worthwhile?). The jury is out on that, but luckily, we don't need to answer that question right away to get started. We need to prototype it out and run a trial and then we'll see how much interest there is.

But there is nothing particularly fancy about this API that solves "hard problems" developers have right now. It's literally a method call that gives you back and object. Like, if this was doing a whole bunch of super fancy complicated browser stuff behind the scenes (like Payment Request/Handler does), then I'd be inclined to agree with you here... but this is just a network call to get some digital goods info from PMI-like URL? Why not just skip that and go directly to the source?

It isn't (directly) a network call. The browser implementing this feature to talk to, say, the Play Store would not be directly making a network call to the server. It would be talking to an API in the Android SDK, and that in turn would privately make a call across the network. So this is much closer to a web API exposing an OS feature (that the OS typically exposes to its native platform), than a web API abstracting over a fetch().

[marcoscaceres]

@mgiuca, @danyao, thanks again for the discussion, details, and for answering all my questions. This has been really helpful in understanding the API and overall idea.

Although this is probably not something we would pursue at Mozilla, we will keep an eye on it as it evolves and can provide feedback as needed.

[phoglenix]

I think this discussion has concluded, so closing the issue.