From primitive to platform — how five API calls become a content monetization engine
Everything we've built — t-shirt checkout, content paywalls, dashboards, multi-rail payment — rests on these five interactions. This is the entire protocol.
PAYMENT-REQUIRED header (base64-encoded; decodes to the body below){ x402Version: 2, resource: { url, mimeType }, accepts: [{ scheme, network, amount, payTo, asset, maxTimeoutSeconds }] }
Server → Client
signTransaction(usdcTransfer) → transaction
Client → Wallet (Phantom, Coinbase Embedded, etc.)
PAYMENT-SIGNATURE header{ x402Version: 2, accepted: { scheme, network, amount, payTo, asset }, payload: { transaction } }
Client → Server → Facilitator
PAYMENT-RESPONSE header (base64-encoded)Set-Cookie: x402_access={signed_token}; PAYMENT-RESPONSE: <base64>; 200 OK
Server → Client
Each layer builds on the one below it. The protocol is the foundation. Everything above is optional configuration.
Payment flow wireframes, admin dashboards, newspaper paywall mockups. Established the UX patterns and Northwoods brand guidelines for all payment interfaces.
Deep research into the x402 ecosystem, competitive landscape, revenue models, facilitator APIs, and security audit. Built the knowledge base that informed all implementation decisions.
End-to-end proof: real Stripe payments, real Braintree/Venmo, real Phantom wallet signing on Solana (devnet on this public site). 79 tests. SQLite persistence. Seller dashboard with live stats.
Strip x402 to its essence. Prove the primitive works. Then show how it scales — from one recipient to thousands, from one article to a content library, from manual publish to an agentic pipeline.
Each scenario uses the same x402 primitive. The only difference is what's on top.
One sender, one recipient, $0.01 of test USDC on Solana devnet. The entire x402 protocol in one page, zero backend.
A reader opens the proof page → picks a recipient from the dropdown → clicks "Pay with Phantom" → Phantom signs USDC transfer → Transaction settles on Solana devnet (~1 sec) → Receipt with Solscan link
Same primitive, but the recipient dropdown grows. Each author has a wallet address. Payment routes directly to them.
Reader opens an article by "Dr. Smith" → Article is x402-gated → Reader pays $0.05 → USDC goes directly to Dr. Smith's wallet → No intermediary, no 30-day payout cycle Dropdown could hold 10, 100, or 10,000 authors. The protocol doesn't care — it's one PayTo address per resource.
The Morning Ledger demo: real articles behind x402 paywalls. Reader hits a 402, pays, gets access. Cookie persists so they don't pay twice.
Reader visits morningledger.com/article/fed-digital-dollar → Server returns HTTP 402 + payment requirements → Paywall overlay: "This article costs $0.05" → Reader connects Phantom, signs payment → Facilitator verifies, server sets access cookie → Article renders. Reader can return anytime (cookie valid 24hr). Scale: 10,000 articles, each with its own price and author wallet. The middleware handles it all — one config entry per path.
The protocol is the foundation. Everything above it is a business decision, not a technical one.
Production payment keys on a public URL. Real orders from real people.
Northwoods experts create content through a voice-first app. Northwoods staff agents consume it via x402 micropayments. The company is customer zero — both supply and demand side. Real usage data, real case study.
Titan CMS integration. External publishers. Personal agents with wallets buying content overnight. The HTTP 402 status code doing what it was designed for: automated payment negotiation at internet scale.