Two Approaches to Browser-Native Payments
If you're building a web payment system in 2026, you've likely encountered two competing visions: the W3C Web Monetization API (formerly known as the Interledger-based streaming micropayments proposal) and HTTP 402 Payment Required as implemented by protocols like Vlexivo.
Both are trying to solve the same fundamental problem: the web has no native payment layer. The subscription model and ad-supported model are both workarounds. A protocol-native payment mechanism is the right solution. But the two proposals take fundamentally different architectural approaches.
This comparison covers architecture, browser support status, payment model mechanics, developer integration complexity, and the use cases each serves best.
Web Monetization is a browser API for passive streaming micropayments (like tipping while you read). HTTP 402 is a protocol mechanism for active request-response payments (like paying for a specific resource). Different use cases. Use HTTP 402 for paywalls and API billing. Consider Web Monetization for ambient content support models.
The Web Monetization API
The W3C Web Monetization proposal (originally introduced by Mozilla and Coil, currently maintained by the Web Platform Incubator Community Group) defines a browser API for streaming micropayments from a user's payment provider to a publisher's wallet.
How It Works
Publishers add a <link> tag pointing to their payment pointer (a wallet
address URL), typically in the form $wallet.example.com/username:
<!-- Publisher declares their payment pointer in <head> -->
<link rel="monetization" href="https://wallet.example.com/publisher">
When a user with a Web Monetization extension (or a compliant browser) visits the page,
the browser detects the <link rel="monetization"> tag and begins
streaming micropayments to the publisher's wallet automatically — while the page is open.
JavaScript events let publishers react to payment state:
// Publisher can detect and respond to payment status
if ('monetization' in document) {
document.monetization.addEventListener('monetizationstart', (event) => {
// Payment stream started — user is paying
hideAds();
unlockPremiumContent();
});
document.monetization.addEventListener('monetizationstop', (event) => {
// Payment stream stopped — user's wallet may be empty
showAds();
});
}The Streaming Payment Model
Web Monetization is fundamentally a streaming tipping model. Payments flow continuously while the page is open — measured in fractions of a cent per second. A reader who keeps an article open for 5 minutes might send $0.003. The publisher receives a trickle of revenue proportional to time-on-page.
This is philosophically aligned with the "support creators" model: users opt into paying for content they value, and payment flows as passive ambient support rather than as a transaction for a specific resource.
HTTP 402 Payment Required
HTTP 402 is a server-side mechanism, not a browser API. The server returns a 402 status code when a resource requires payment, along with a cryptographic challenge. The client wallet completes the challenge (submits payment, returns proof), and the server unlocks the resource.
How It Works
# 1. Client requests protected resource
GET /articles/analysis-2026 HTTP/1.1
Host: publisher.example.com
# 2. Server returns 402 with payment challenge
HTTP/1.1 402 Payment Required
Content-Type: application/json
{
"challenge": {
"nonce": "e3b0c4...",
"price": "0.25",
"currency": "usd",
"scope": "per-article",
"expires": 1747234249
}
}
# 3. Client pays and resubmits with proof token
GET /articles/analysis-2026 HTTP/1.1
X-Vlexivo-Token: eyJhbGc...
# 4. Server verifies and returns content
HTTP/1.1 200 OK
Set-Cookie: vlx_access=eyJ...
{ "content": "Full article text..." }The payment is for a specific resource, at a specific price, with cryptographic proof that the transaction occurred. It's a transactional payment model — you pay for what you get, exactly when you get it.
Head-to-Head Technical Comparison
| Dimension | Web Monetization API | HTTP 402 (Vlexivo) |
|---|---|---|
| Architecture | Browser API + streaming protocol | HTTP status code + challenge-response |
| Payment model | Continuous streaming while page open | One-time payment per resource |
| Price per transaction | Fractions of a cent per second | Publisher-set price per resource |
| Browser support (2026) | Extension-only (no native browser support) | Works in any browser (HTTP-level, no browser changes) |
| Works for APIs | No (browser-only) | Yes (native HTTP) |
| Server-side verification | Optional (publisher can verify receipt ID) | Yes (cryptographic proof on every call) |
| Works for AI agents | No (requires browser) | Yes (standard HTTP, no browser required) |
| User wallet required | Yes (must have WM-compatible wallet extension) | Yes (Vlexivo hosted wallet) |
| Publisher implementation | 1 HTML tag + optional JS events | 1 HTML tag (client) or middleware (server) |
| Content gating | Soft (JS-based, easily bypassed) | Hard (server-side, payment required for access) |
| Open standard | W3C WICG proposal | IETF HTTP/1.1 (RFC 9110) |
The Key Architectural Differences
- Streaming: payments flow continuously
- Ambient: no user action required per page
- Soft gates only: JS can be disabled
- Browser/extension dependent
- Best for: patronage, "leave a tip" model
- Not suitable for APIs or server resources
- Transactional: one payment per resource
- Active: user approves each payment
- Hard gates: server holds content until paid
- Works in any HTTP client
- Best for: paywalls, API billing, gated data
- Works for APIs, agents, and non-browser clients
Browser Support: The Critical Gap
As of 2026, no major browser natively implements the Web Monetization API. It requires a browser extension. This means your readers need to:
- Know the Web Monetization API exists
- Find and install a compatible wallet extension
- Fund the wallet
- Enable monetization for your site
That's a high-friction onboarding path for passive tipping. In practice, Web Monetization adoption has been limited to readers who actively seek out the technology.
HTTP 402 has no browser requirement. The payment widget is loaded as a script from your site — it works in any browser, on any device, without extensions. The reader just needs a funded Vlexivo wallet (which they create via standard web signup).
The Web Monetization spec has been in development since 2019, moved through multiple organizations (Coil, Grant for the Web, WICG), and remains in draft status with no committed browser implementation timeline. If you're building payment infrastructure for production in 2026, betting on browser-native WM shipping is high-risk.
Can You Use Both?
Yes — and for content publishers, there's a case for running both simultaneously:
- Web Monetization readers (users with WM wallets) get ad-free access as a passive benefit of their streaming payments
- Non-WM readers see the Vlexivo paywall: pay per article or subscribe
// Detect Web Monetization, fall back to Vlexivo paywall
if ('monetization' in document) {
// WM user — unlock content when stream starts
document.monetization.addEventListener('monetizationstart', () => {
revealContent();
});
} else {
// No WM — show Vlexivo paywall
initVlexivoPaywall({
price: '0.25',
scope: 'per-article',
resourceId: articleId
});
}This gives you coverage across both user segments. WM users get seamless access. Everyone else gets a clean pay-per-article option. Neither group sees ads.
When to Use Each
| Use Case | Web Monetization | HTTP 402 | Verdict |
|---|---|---|---|
| Blog / newsletter paywall | Soft gate (bypassable) | Hard gate (server-enforced) | HTTP 402 wins |
| API billing | Not applicable | Native per-call billing | HTTP 402 only |
| AI agent payments | Not applicable | Native HTTP, no browser | HTTP 402 only |
| "Support the creator" model | Ambient streaming, no friction | Per-article, requires action | Web Monetization wins |
| Video / podcast streaming | Time-proportional payments | One payment per play | WM for ambient, 402 for pay-to-watch |
| Data API with granular pricing | Not applicable | Dynamic per-call pricing | HTTP 402 only |
| Downloadable files / software | Not applicable | Per-download authorization | HTTP 402 only |
The Protocol Argument for HTTP 402
HTTP 402 has one architectural advantage that Web Monetization can't match: it's part of
the core HTTP specification. 402 Payment Required has been in the HTTP spec
since RFC 2068 (1997) — every HTTP client in the world knows what a 402 status code is,
even if most didn't implement payment handling for it.
That matters because the web is not just browsers. APIs, agents, scrapers, CLI tools, mobile apps, server-to-server calls — all of these are HTTP clients. Web Monetization is explicitly and intentionally a browser feature. HTTP 402 works everywhere HTTP works.
As AI agents become significant consumers of web content and APIs, this distinction becomes decisive. An agent browsing the web for data doesn't have a browser UI for installing extensions. It has an HTTP client and a wallet. HTTP 402 is the only payment standard that serves that use case natively.
The next major consumer of paid web content isn't a human with a subscription — it's an AI agent executing research tasks on behalf of a user. HTTP 402 is the only payment standard designed to work at the protocol level for non-browser HTTP clients. If you're building infrastructure for the agentic web, HTTP 402 is the only viable path.
Implement HTTP 402 Today
Vlexivo is HTTP 402 infrastructure — the SDK, the hosted consumer wallets, the challenge-response protocol, the settlement layer. You add it to your site in 5 minutes and start earning from readers who won't subscribe.
<script src="https://www.vlexivo.online/sdk.js"
data-publisher-id="pub_your_id"></script>
<button data-vlx-price="0.25" data-vlx-scope="per-article">
Unlock this article — $0.25
</button>See the full integration guide at vlexivo.online/docs.
import { VlexivoServer } from 'vlexivo';
const vlx = new VlexivoServer({ apiSecret: process.env.VLX_SECRET_KEY });
app.use('/api/v1', vlx.paywall({ price: '0.001', scope: 'per-call' }));Two lines. Any Node.js Express server. Works for APIs, not just web pages.