Skip to content
Web Monetization logo Web Monetization
GitHub

Sending payments

Three key components of sending a Web Monetization payment are:

  • Web Monetization providers
  • Open Payments-enabled accounts
  • Web Monetization agents

Web Monetization providers

For a site visitor to send a Web Monetization payment, the visitor must have some kind of relationship with a Web Monetization provider. A Web Monetization provider is an entity that provides a funded Open Payments-enabled account from which payments can be sent. A provider can take a number of different forms, such as:

  • A company that uses its own account to make payments on behalf of its customers
  • An app that’s authorized to hook directly into a user’s personal account
  • An individual that hooks their personal account up to a Web Monetization agent

In addition to providing funded accounts, Web Monetization providers are responsible for defining the payment models they support and implementing business logic and rules. For example, a Web Monetization provider might:

  • Only send payments in fiat currencies
  • Support one-time payments and micropayments Very small payments, e.g., fractions of a cent , but not real-time streaming payments
  • Stream real-time payments at a fixed rate, for example $0.006 per minute
  • Allow user-defined payout rates, frequencies, limits, and so on

For a provider to send a Web Monetization payment on behalf of an individual, the provider must support the Open Payments specification.

Open Payments and wallet addresses

Open Payments enables open and interoperable payments between Web Monetization providers and Web Monetization receivers. As such, accounts supplied by both Web Monetization providers and Web Monetization receivers must implement the Open Payments (OP) specification.

The OP specification defines standards for access to accounts. When granted access, applications and other entities can integrate payments into their feature sets by connecting to their users’ accounts. The ability to then execute payments between OP-enabled accounts relies on the availability of a common payment rail between the accounts.

Wallet addresses

Access to an OP-enabled account, whether for sending or receiving, always starts with a wallet address. In this context, a wallet address is a unique URL that identifies an OP account and provides an entry point for the Open Payments API.

A wallet address allows certain account details to be safely shared with third-parties. Third-parties use the details to initiate payments to or from the account. A Web Monetization agent is an example of a third-party.

Depending on the form a Web Monetization provider takes, the provider’s user may not know, nor have a need to know, any details about the sending account’s wallet address.

Web Monetization agents

One goal of Web Monetization is for vendors to natively build the standard into web browsers. But we aren’t there yet. For now, users must install a separate Web Monetization agent, such as an extension, into their browsers.

The Web Monetization agent is code that discovers web monetized pages, exposes the Web Monetization API, and communicates via the Open Payments APIs to obtain authorization and issue instructions for making a payment.

How it works

The Web Monetization agent checks each page an individual visits for a monetization <link> element. A monetization <link> element must contain a valid Open Payments wallet address. For example:

<link rel=”monetization” href=”https://wallet.example/alice”>

When detected, the Web Monetization agent begins a series of API calls to:

  1. Get the details about the underlying account
  2. Receive permission to send a payment to the account
  3. Create a monetization session within the site visitor’s browser tab/window
  4. Create the outgoing payment request

Visit the Add Web Monetization to a page and Web Monetization flow pages for more information.

The Interledger Foundation has developed an open-source Web Monetization browser extension (agent) for users. Web Monetization providers could also choose to develop their own Web Monetization agents. Regardless of who supplies the Web Monetization agent, the agent must have a way to link to a provider. For example, a browser extension could allow individuals to select and sign in to their provider from within the extension UI. By signing in, the individual authorizes the extension to obtain settings from the provider and send payments on their behalf.

Note that the Web Monetization specification itself doesn’t define the interface between the browser and the Web Monetization provider. This is intentional. How a browser ultimately chooses to allow Web Monetization providers to integrate is up to the browser. We feel that a browser’s extension system is the ideal way to support integration.