Three key components of sending a Web Monetization (WM) payment are:
- WM providers
- Open Payments-enabled accounts
- WM agents
For a site visitor to send a Web Monetization payment, the visitor must have some kind of relationship with a WM provider. A WM 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 WM agent
In addition to providing funded accounts, WM providers are responsible for defining the payment models they support and implementing business logic and rules. For example, a WM provider might:
- Only send payments in fiat currencies
- Support one-time payments and
, but not real-time streaming payments micropayments
- 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 payment pointers
Web Monetization works with two complementary technologies that enable open and interoperable payments between WM providers and WM receivers: Open Payments and payment pointers.
Accounts supplied by both WM providers and WM 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.
Access to an OP-enabled account, whether for sending or receiving, always starts with a payment pointer. A payment pointer is a unique, standardized identifier for a payment account and always resolves to an HTTPS URL.
A payment pointer 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 WM agent is an example of a third-party.
Depending on the form a WM provider takes, the provider’s user may not know, nor have a need to know, any details about the sending account’s payment pointer.
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 WM agent, such as an extension, into their browsers.
The WM 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 WM agent checks each page an individual visits for a monetization
<link> element. A monetization
<link> element must contain a payment pointer. For example:
<link rel=”monetization” href=”https://wallet.example/alice”>
When detected, the WM agent begins a series of API calls to:
- Get the details about the underlying account
- Receive permission to send a payment to the account
- Create a monetization session within the site visitor’s browser tab/window
- Create the outgoing payment request
Link a WM agent to a WM provider
The Interledger Foundation is currently developing an open-source WM agent for users (release date TBD). WM providers could also choose to develop their own WM agents. Regardless of who supplies the WM 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 WM provider. This is intentional. How a browser ultimately chooses to allow WM providers to integrate is up to the browser. We feel that a browser’s extension system is the ideal way to support integration.