[Proposal] Web Monetization - A new Revenue Model for the Web

(UPDATED: 5 Sept 2019)

An API that allows Websites to request a stream of very small payments from the user.

Web Monetization is an alternative revenue model for the Web. It allows Websites to earn revenue from users without:

  • Requiring users to sign-up to a subscription
  • Needing to deliver content/services through 3rd-party platforms
  • Advertising

For a more detailed description, see the Explainer and track design discussion in the issue log.

There is also an early Specification, which is obviously subject to change.

Basic Flow

Users sign up with a Web Monetization sender which is capable of sending very small payments to websites. This would likely be a digital wallet or a service that specializes in sending micropayments for content.

Websites sign up with a Web Monetization receiver, a specialised digital wallet capable of processing an incoming stream of very small payments.

When the user visits the website, her browser parses a <meta> tag in the header of the site that contains the websites receiving address.

The browser determines how much to pay the website and then contacts the websites WM receiver to get a unique receiving address for payments for the current session (page load/refresh).

The browser begins sending small payments via the user’s WM sender (using the Payment Handler API).

For each payment the browser emits an event that the website can listen for.

In return for payment the website provides the user with an alternative “paid for” experience such as not showing advertising, delivering premium content etc.


The Web Monetization model decouples the user’s sender (making payments on their behalf) from the website’s receiver (a digital wallet capable of accepting payments for the website).

By using the browser as an intermediary the privacy of the user is preserved from both the website and the WM sender.

By providing an alternative revenue model to advertising, WM indirectly reduces the need for websites to do invasive tracking of their users.


I think we need to discuss the different types of privacy that different Payment Providers could offer, as differentiators.

Provider X needs only to know the origin of the page (and the creator’s payment pointer in the metatag). That’s enough to send money.

Provider Y might want to offer extra opportunities - e.g., a creator registers a YouTube/ SoundCloud URL with them (because there is no way to add one’s own metatag at the moment). A web visitor with Provider Y registered as their payment provider could consent to sharing the full URL with the provider so they can pay registered content creators.

Providers could also offer to not pay sites on a blacklist, or boost payments to sites on a whitelist. (These lists could be in-browser, so browsers could pass a banned/ boosted flag to the provider. Alernatively, sites registed as banned in the browser could simply ignore the monetization metatag, and therefore pass no info to the payment provider that this URL is banned, which I would prefer as a user.)

1 Like

I have logged an issue to discuss this further.

I think it boils down to some kind of spectrum of user privacy vs provider capability.

On the one end of the spectrum we have maximum user privacy where users don’t have the option of sharing any data with the providers and providers just pay every website the user visits the same amount.

On the other end users sign up with the provider and opt in to share data about their browsing activity with the provider and in return the provider pays out different amounts to different sites based on what they believe is best for the user.

1 Like

Thanks @marcosc and @brucelawson and others for the feedback.

The explainer is now updated to reflect the discussions and a cleaner architectural model.

  • Users have a WM Sender which is just an implementation of a Payment Handler that can send money on their behalf.
  • Websites have an account at a WM Receiver (a digital wallet) where they can receive payments.
  • The browser makes decisions about how much to pay each site and sends these payments via the user’s WM sender

I’ve also logged issues to track the outstanding discussion points.

If you’ll be at TPAC we’re going to have a workshop on this topic on the Wednesday. Please join us to help us refine this API.

1 Like

W3C interviewed Stefan Thomas about this monetization proposal. Some good context on the motivations: https://www.w3.org/blog/2019/09/w3c-interview-coil-on-interledger-protocol-and-web-monetization/


Given the announcement on Mozilla foundation blog, it’s safe to say that Mozilla supports this. @ahopebailie, can we work together to transfer the repository over to the WICG?


We’ve got everything consolidated at webmonetization.org now. The code behind that is at https://github.com/interledger/webmonetization.org

Do you want to move that repo?

1 Like

@ahopebailie I hope this is the correct place to post this question. At Musicoin we offer users to stream music and pay the content creator immediately with smart contracts. We are looking into web monetization, we are wondering whether it’s possible to only make the user pay while streaming? :thinking:

1 Like

Sorry for the possibly naive question, but I do not see much information on how the user can give their input on the decision to start or not the payment to the website, plus any influence on the amount or rate for the payments. Or is this out of scope for this specification and it is already tackled somewhere else?


Moved into repository: http://github.com/WICG/webmonetization

Best place to ask questions is as issues on GitHub


I don’t think that is something that would be standardised as part of the API. That would eb determined between the user and their provider

1 Like