The Web Monetization repository is a specification process, not a library

What the repository actually contains

The first line of the readme is the one that sets expectations correctly. This is the source code for the website hosted at webmonetization.org, and the website is the home of the proposed Web Monetization standard currently incubating at the WICG.

So the repository is not a library and not an implementation. It is a documentation site, a specification document, and the process around them. The top-level entries confirm the shape: a src/ directory for the site, a specification/ directory holding the spec source, a public/ directory for static assets, a netlify.toml for deployment, an astro.config.mjs for site configuration, and the usual governance files including CONTRIBUTING.md, CODE_OF_CONDUCT.md and a w3c.json file.

That distinction matters for anyone who finds the repository through a search for Web Monetization and expects an SDK. There is no client library here, no server component, and no reference implementation. What there is, is the text of the standard and the machinery for changing it.

The documentation itself is split into two entry points. The readme points to the docs, and separately to the proposed specification, so a reader can go straight to the normative text or start with the explanatory sections.

For an adopter, the practical value of this repository is that it is the canonical source of the standard. When a question comes up about what the standard says, the specification directory is where the answer is defined, and the commit history is where you can see when it changed.

A Starlight site on Astro, with the tooling to match

The site is built with Starlight, a documentation framework based on Astro, and the package manifest shows the versions in use: astro at about 7.3.7 and @astrojs/starlight at about 0.42.0.

That choice is visible in the way the content is organised. Starlight looks for .md or .mdx files in the src/content/docs/ directory, and each file is exposed as a route based on its file name. The project recommends the .mdx extension whenever possible, which is the framework's convention for files that need to embed components alongside prose.

The site also carries a set of Starlight plugins that show what the documentation needs to do rather than just display it. There is starlight-links-validator, which checks that internal links resolve, and starlight-llms-txt, which generates a machine-readable text version of the docs for language models. A fullview-mode plugin handles the page layout, and the Interledger docs design system is a dependency, which places the site inside the design vocabulary of the broader Interledger ecosystem rather than a bespoke look.

Search is handled by an optional dependency on @pagefind/linux-x64 pinned to 1.5.2, which is how a static Astro site gets client-side search without a server.

The repository is hosted on Netlify, and there is a .pr-preview.json file, which is the configuration for building a preview of a pull request before it merges. For a repository where a great deal of the traffic is specification review, having each pull request render as a reviewable site is the mechanism that makes the review process workable at all.

The commands, and the linting setup that keeps docs honest

Setting up the site locally is short, and the readme gives the install step directly:

cd webmonetization
npm install

Everything else is run from the root of the project. npm run start starts the local dev server at localhost:1100, npm run build builds the production site to ./dist/, and npm run preview previews the build locally before deploying. There is also npm run astro for CLI commands such as astro add and astro check, and npm run astro -- --help to get help from the Astro CLI.

The two commands that matter for a documentation repository are the lint pair. npm run lint checks code formatting and quality with Prettier and ESLint, and npm run format formats the code and fixes linting issues automatically. Both are configured to fail on warnings, since the ESLint invocation uses the --max-warnings=0 flag.

There is a third command that is specific to this project and worth knowing about. The format:spec script runs tidy with the configuration in tidyconfig.txt against specification/index.html. That is an HTML formatter, and it exists because the specification is written as HTML rather than Markdown, so that it can carry the structure and the machine-readable metadata a standards document needs.

The devEngines block in package.json requires npm 11.10.0 or newer, and onFail is set to error, so a mismatched package manager fails the install rather than silently producing a different tree. There is a .nvmrc and an .npmrc at the repository root to pin the Node version and the registry configuration.

Adding a page means editing three places, not one

The contributing guidance on content is the part that tells you how much work a documentation change actually is, and it is more than writing prose.

Static image assets go in the public/img/docs directory, and when you reference them in Markdown you do not include public/ in the path, so the reference looks like this:

![A lovely description of your beautiful image](/img/your-beautiful-image.png)

There are naming and accessibility conventions attached to that. Alt text should describe the image, the file name should be descriptive rather than something like img01.png, and file names use hyphens rather than the other character to keep the naming conventions consistent.

To add a new document, you create a Markdown file in the relevant folder under src/content/docs, using the .mdx extension where possible. Then, and this is the part people miss, you have to add the new document to the sidebar, which is configured in astro.config.mjs. A page that is not in the sidebar is published but not navigable.

Editing an existing document is the same idea: go to src/content/docs, find the file, and edit it. The frontmatter block in each document carries the title, in the form shown here:

---
title: This Doc Needs To Be Edited
---

Edit me...

Custom pages are the fourth case, and they live in the src/pages directory. The readme is honest that these come with absolutely nothing out of the box, and describes the approach: the project created custom layout components that form the frame of a basic HTML page, and populate the main element through the concept of slots, where a slot element specifies where individual page content should be injected.

---
import i18next, { t, changeLanguage } from "i18next";
import Base from '../layouts/Base.astro';
---
<Base>
  /* Page content goes here */
</Base>

The i18next import in that example is not incidental, since the site is bilingual and the custom page has to be able to switch language.

How a change to the standard gets reviewed

The review process is described in its own section, and it is short. After a pull request is submitted, it will be reviewed by a member of the Web Incubator Community Group, and the readme asks that you ensure you are able to receive GitHub notifications so you will know when the pull request is approved and can be merged, or whether updates are required before approval is given.

That is the whole governance model, and it is worth understanding what it implies. WICG is an incubation venue: proposals live there until they are judged ready to move to a more formal standards track. The review is by a WICG member rather than by a named editor, and approval of a pull request means the community is satisfied with that change to the document, not that a specification has been published.

Specification changes follow their own path, and the readme points to CONTRIBUTING.md for the specification development section rather than describing it inline. The repository includes a CHANGELOG-style tool in the form of the format:spec script for tidying the HTML, and a .prettierignore and .prettierrc that control how the Markdown and MDX files are handled.

The community calls are open. The readme states they have catch-up calls every fourth Thursday at 14:00 GMT via Google Meet, and gives the video link, the phone number and a PIN, plus a link to add the call to Google Calendar. That is a WICG working group, and its rhythm is a monthly call with a quarterly-standard agenda.

Apache 2.0 in the manifest, and a licence file to check

The package manifest declares the licence as Apache-2.0, and the repository root contains a LICENSE.md file alongside a w3c.json file, a netlify.toml for deployment and a tidyconfig.txt for the specification formatter.

GitHub classifies the repository licence as a custom one it cannot categorise, which is worth a moment's attention. This is normal for WICG repositories, where the licence file usually carries a short notice pointing at the W3C document licence and related policies rather than reproducing a standard text inline, and the result is that the automated classifier sees a format it does not recognise.

The practical advice is narrow: read LICENSE.md if you need to know the terms, and treat the Apache-2.0 field in package.json as the statement about the code rather than about every document in the tree.

The dependency list also says something about the ecosystem. The Interledger docs design system appears as a dev dependency, which places the project within the Interledger working group, the group that has been the main home for the streaming payments and web monetization work. A repository hosted by WICG but built on Interledger's design system is a reasonable picture of how this proposal is situated: incubated in a community group, but written by people who have been working on payment standards for a long time.

The topics on the repository are documentation, open-payments, specification, web-monetization and webmonetization, and the last push was on 2026-10-20. The project publishes no GitHub releases, which is consistent with a document that changes through pull requests rather than through versioned releases.

Editorial conclusion

Web Monetization suits an engineer who needs to read the current text of the standard, track how it changes over time, or contribute to it through the WICG review process, and who is willing to read a proposal rather than a finished specification. It is the wrong tool if you are looking for a client library or a payment integration, because the repository contains the prose and the site source and nothing else, and it is the wrong tool if you need a stable guarantee, since an incubating proposal can change in ways that break an implementation. Before building against it, read the current specification in full and the CONTRIBUTING.md guidance on specification development, then check the w3c.json file and the specification directory to see how the document is versioned, because the version marker in your integration has to track a document that is still moving.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. WICG/webmonetization on GitHub