Skip to content
Web Monetization logo Web Monetization
GitHub

Web Monetization flow

Web Monetization (WM) relies on Open Payments (OP) and OP-enabled accounts to coordinate payments.

The WM agent Code in a web browser, such as an extension, that discovers web monetized pages, exposes the Web Monetization API, and communicates with the Open Payments APIs first issues a series of API calls to the receiving account’s payment pointer A URL that identifies an Open Payments account , then to the sending account’s payment pointer, to obtain the necessary authorization and instructions for sending a payment.

Sequence diagram

WM receiverWM providerAuth serverOpen Paymentsreceiving accountWeb pageWM agentOpen Paymentssending accountAuth serverOpen Paymentsreceiving accountWeb pageWM agentOpen Paymentssending accountThe auth server can belocated outside of the WM receiver's domainConnection persists untilrequest moves from 'pending'state to 'sending' statePayment processing and settlement occurs between the WM provider and WM receiver, outside of the WM flowDetects monetization <link> element,extracts payment pointer1Requests the payment pointer's public info2Returns info, including auth server URL3Requests access rights4Returns access token5Requests creation of an incoming payment resource6Responds with unique payment details for addressing the payment to the account7Requests an outgoing payment becreated against the sending account8Responds with details about the'receive', 'send', and 'sent' amounts9Fires monetization event10

Web Monetization flow example

This section provides an example of the API calls that occur when a web monetized user visits a web monetized site.

There’s a few points to keep in mind as you review the example.

  • It’s up to the site visitor, not the web monetized site, to decide how often and how much to pay, as well as the currency in which to send a payment.
  • While Web Monetization and Open Payments work together to coordinate payments, neither moves money. Payment processing and settlement must occur between the sending and receiving accounts over a common payment rail.

Scenario

Alice adds the monetization <link> element to her website. Included within the <link> is her payment pointer, https://wallet.example/alice, assigned to her by her WM receiver An entity that provides an Open Payments-enabled account into which payments can be received .

Bob signs up with a WM provider An entity that provides a funded Open Payments-enabled account from which payments can be sent who supplies him with a funded sending account. The sending account’s payment pointer is https://anotherwallet.example/bob. After installing a WM agent in his browser and linking the WM agent to his WM provider, his WM agent now has permission to request payments be sent from his account.

1 - Check for Web Monetization

As Bob browses Alice’s site, his WM agent detects a monetization <link> element.

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

2 - Send request to payment pointer (receiving account)

The WM agent issues a request to Alice’s payment pointer to discover the Open Payments service endpoint.

Request

GET /alice HTTP/1.1
Accept: application/json
Host: wallet.example

3 - Send grant request to WM receiver’s auth server

The WM agent issues a request to the WM receiver’s grant request endpoint (authorization server) to get an access token.

In this example, the WM agent requests access to create and read incoming payments (i.e., payments coming in to Alice’s WM receiver).

Request

POST /auth/ HTTP/1.1
Accept: application/json
Content-Type: application/json
Host: wallet.example
Content-Length: 218

{
  "access_token":{
    "access":[
      {
        "type":"incoming-payment",
        "actions":[
          "create",
          "read"
        ],
        "identifier":"https://wallet.example/alice"
      }
    ]
  },
  "interact":{
    "finish":{
    "method":"redirect"
  }
},
"client":"https://anotherwallet.example/bob"
}

4 - Send incoming payment request to payment pointer (receiving account)

The WM agent creates an incoming payment for the session (e.g., the open browser tab) by issuing an incoming payment request to Alice’s payment pointer. The request uses details obtained from the previous API calls.

Request

POST /alice/incoming-payments HTTP/1.1
Accept: application/json
Content-Type: application/json
Authorization: OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0
Host: wallet.example

5 - Send outgoing payment request to payment pointer (sending account)

The WM agent uses the details obtained thus far to create an outgoing payment request against Bob’s account (via his payment pointer). Note that this is just a request to send a payment. The payment itself has not been sent and the request is in a pending state.

Request

POST /bob/outgoing-payment HTTP/1.1
Accept: application/json
Content-Type: application/json
Authorization: {{ outgoingPaymentGrant.accessToken.value }}
Host: anotherwallet.example