The Web Monetization API and Micropayments

What Web Monetization Actually Does

Web Monetization introduces a fundamentally different payment model to the web. Instead of discrete transactions where a player decides to buy something, Web Monetization creates a continuous stream of tiny payments that flow automatically while the player is on your page. The player loads your game, their browser detects a monetization meta tag, and their wallet begins sending small amounts of money to your wallet at a steady rate, typically a fraction of a cent per second.

The developer adds a single HTML element to their page: a <link rel="monetization" href="https://wallet.example/your-payment-pointer"> tag. This tag contains a payment pointer, which is a URL-like identifier for the developer's digital wallet. When a visitor with Web Monetization support arrives at the page, the browser reads this tag and initiates a payment stream from the visitor's wallet to the developer's wallet.

The JavaScript API fires events that your game code can listen for. The monetization event on the document's monetization link element tells you when payments start flowing. Your game can use these events to detect whether the current player is actively monetizing and respond accordingly, such as removing ads, unlocking bonus content, or displaying a supporter badge. The game remains fully functional without Web Monetization; the API simply adds a layer of passive revenue and optional perks for supporting players.

The Interledger Protocol

The Interledger Protocol (ILP) is the payment infrastructure that powers Web Monetization. ILP is an open protocol for routing payments across different payment networks, banks, and currencies. It works similarly to how the internet routes data packets across different networks: the sender and receiver do not need to be on the same network, use the same currency, or even know about each other's financial institutions. ILP handles the routing, currency conversion, and settlement automatically.

This interoperability is essential for Web Monetization to work at a global scale. A player in Brazil using reais can stream payments to a developer in South Korea receiving won, with ILP handling the currency conversion through its network of connectors. The player's wallet denominates the spending in their local currency, and the developer's wallet receives deposits in theirs. Neither party needs to manage foreign exchange or maintain accounts in multiple currencies.

ILP was originally developed by Ripple and is now maintained as an open standard by the Interledger Foundation. The protocol is designed for micropayments, with transaction costs low enough that transferring fractions of a cent remains economically viable. This is different from traditional payment rails like credit card networks, where minimum transaction fees of $0.20 to $0.30 make sub-dollar payments impractical.

The protocol's architecture uses a network of connectors that relay payments between the sender's and receiver's payment networks. Each connector takes a small fee for forwarding the payment, similar to how internet routers handle data. Payments are cryptographically secured so that connectors cannot steal funds in transit. The entire settlement happens within seconds, meaning the developer starts receiving money almost immediately when a player lands on their page.

Setting Up Web Monetization for Your Game

Implementing Web Monetization in a web game requires three components: a payment pointer linked to a digital wallet, the monetization meta tag in your HTML, and JavaScript code that detects and responds to the payment stream.

Getting a payment pointer starts with creating an account at a Web Monetization-compatible wallet provider. Uphold and GateHub are two of the most established providers that support ILP and issue payment pointers. After creating an account and completing identity verification, the provider assigns you a payment pointer in the format https://ilp.uphold.com/your-identifier or a similar URL structure. This pointer is what you place in your HTML to receive payments.

Adding the meta tag is a single line of HTML in your page's <head> section or, for web games hosted on platforms that generate the HTML wrapper, in whatever configuration file controls the page template. The tag is: <link rel="monetization" href="YOUR_PAYMENT_POINTER">. There is nothing else to configure on the receiving side. If a monetization-capable browser visits your page, payments begin flowing automatically.

Detecting monetization in JavaScript allows your game to offer perks to paying players. The core pattern checks whether the document.monetization link element exists and listens for the monetization event. When the event fires, your code knows that the player has an active payment stream, and you can unlock features accordingly. Common implementations gate ad removal, cosmetic bonuses, or small gameplay advantages behind the monetization check.

Game engines with Web Monetization plugins simplify the integration further. Phaser, one of the most popular HTML5 game frameworks, offers a Web Monetization plugin that wraps the API into engine-native callbacks. Defold, another popular web game engine, provides a similar extension. These plugins abstract the low-level event handling into game-engine patterns, making it straightforward to add monetization-gated features to your game logic.

What to Offer Monetizing Players

The design philosophy for Web Monetization rewards should follow the same principles as good free-to-play design: the game must remain fully playable and enjoyable without monetization, and the perks should feel like genuine bonuses rather than restored features that were deliberately removed. Players who support your game through Web Monetization are voluntarily contributing, and the experience should feel appreciative rather than transactional.

Ad removal is the most straightforward perk. If your game shows display ads, interstitials, or even rewarded video prompts, you can hide or reduce them for players with active Web Monetization. This is a natural fit because the player is already paying you through the micropayment stream, so advertising becomes redundant as a revenue source for that player. The implementation is simple: check the monetization state before rendering ad units.

Cosmetic bonuses such as exclusive character skins, color schemes, particle effects, or UI themes reward monetizing players with visible flair without affecting game balance. These items are purely visual and do not give any competitive advantage, making them safe to offer without creating pay-to-win concerns. They also serve as social signaling, letting other players know that someone is a supporter.

Convenience features like additional save slots, faster loading of certain resources, or expanded inventory space offer tangible value without changing the core gameplay difficulty. These features make the experience slightly smoother for monetizing players without punishing non-monetizing players. The key principle is that the base game should feel complete, and the perks should feel like appreciated extras.

Bonus content such as additional levels, characters, or game modes can be gated behind Web Monetization, effectively treating it as a lightweight subscription. The player gets access to the bonus content as long as they have monetization active, and loses access if they disable it. This model requires more content development but creates a stronger value proposition for players who want more from the game.

Current Browser Support and Adoption

Web Monetization is not yet natively supported by any major browser. Current support comes through browser extensions, with the most prominent being those provided by wallet services like Coil (which has since wound down) and newer alternatives. The Web Monetization specification is under active development as a proposed W3C standard, which means native browser support is the long-term goal but has not yet been achieved.

This limited adoption means that Web Monetization should be treated as a supplementary revenue channel, not a primary one. The percentage of your players who have Web Monetization enabled will be small, likely in the low single digits at best. Revenue per monetizing player will also be modest, typically accumulating to a few cents per hour of play. However, the implementation cost is minimal (a meta tag and a few lines of JavaScript), so even small returns represent essentially free revenue.

The Grant for the Web program, funded by the Interledger Foundation, Coil, and Mozilla, has invested in developing the Web Monetization ecosystem through grants to developers, content creators, and toolmakers. This funding has produced tutorials, plugins, sample projects, and advocacy resources that make it easier for developers to experiment with the technology. The Phaser and Defold plugins mentioned earlier were both developed with support from this program.

Looking ahead, the trajectory of Web Monetization depends on browser vendor adoption and the growth of the ILP wallet ecosystem. If a major browser ships native Web Monetization support, the potential audience would expand dramatically overnight. Until then, the technology remains a forward-looking experiment that costs almost nothing to implement and provides a small but genuine revenue stream from players who choose to support web creators.

Web Monetization vs. Traditional Micropayments

Traditional micropayment systems have been attempted repeatedly on the web and have largely failed due to transaction costs. Credit card processing fees of $0.20 to $0.30 per transaction make it economically impossible to charge $0.01 or $0.05 for a piece of content. Even PayPal's micropayment pricing (5% plus $0.05) creates disproportionate overhead for sub-dollar transactions.

Web Monetization solves this by streaming aggregated payments rather than processing individual microtransactions. The player's wallet sends a continuous stream that is settled periodically in batches, spreading the transaction cost across many micropayments and making the per-unit cost negligible. The player does not approve each fraction-of-a-cent payment individually; they set a spending rate in their wallet and the browser handles the rest.

This streaming model also removes purchase friction entirely. There is no checkout flow, no confirmation dialog, no price evaluation. The player just plays the game, and money flows. For game developers, this means monetization that scales with engagement time rather than conversion events, rewarding games that keep players engaged over long sessions rather than games that are good at prompting purchase decisions.

The philosophical difference is significant. Traditional monetization asks "how do I get this player to pay?" while Web Monetization asks "how do I give this paying player a better experience?" The developer's incentive shifts from conversion optimization to engagement optimization, which tends to produce better games and happier players.