Alex Tuppurainen
AI Payments · API Infrastructure · Blockchain
A proof-of-concept demonstrating how businesses can monetize information through pay-per-request APIs. Explore how AI agents and software applications can purchase information directly from a business website.
Project Overview
Harbour/402 is an experimental web application I developed to explore x402, an emerging payment protocol designed to enable internet-native transactions between software systems.
The demonstration simulates a marine supply business that sells access to specialized information through a payment-protected API. Visitors can explore fictional business information, connect a cryptocurrency wallet, and purchase access to additional data using testnet USDC.
Although the application is relatively simple, the underlying concept has significant implications for how businesses may interact with artificial intelligence.
As AI agents become increasingly capable of completing tasks independently, they will need ways to access and purchase information, software services, and computational resources. Harbour/402 explores one potential solution to that problem.
Understanding x402 and AI Agent Payments
What is x402?
x402 is an open payment protocol introduced by Coinbase that allows websites and APIs to request payment directly through standard internet communication.
Its name comes from HTTP status code 402 — Payment Required.
When software requests information from a server, the server can respond with payment instructions instead of immediately providing the information. Once the client supplies a valid payment authorization, the server can deliver the requested resource.
In practical terms, x402 allows a business to charge for individual interactions with its digital services without requiring every customer to complete a conventional subscription or checkout process.
For example, consider an AI agent researching marine equipment suppliers.
The agent identifies a business with the inventory data it needs. Instead of requiring a human to register for an account, enter credit card information, and purchase a subscription, an x402-enabled system can present the price for accessing that information.
A suitably equipped agent can authorize the payment within its permitted spending limits and retrieve the data.
The process can be reduced to a simple sequence:
The key distinction is that payment becomes part of the interaction between software systems rather than a separate process designed exclusively for humans.
This does not mean AI agents automatically have permission to spend money. They still require compatible payment tools, available funds, and authorization from the people or organizations operating them.
Source: Coinbase — Introducing x402.
Why is this important?
Most commercial internet infrastructure developed around human users. Websites rely on accounts, checkout pages, subscriptions, and payment forms.
These systems work reasonably well when people are making purchasing decisions. However, they can introduce significant friction when autonomous software needs to purchase a small amount of information or access a service for a single task.
Consider three potential applications:
Business information: An AI agent preparing a procurement report could purchase a supplier’s current inventory or pricing information.
Specialized research: A research system could purchase access to an individual dataset without subscribing to an entire database.
Computational services: An AI application could pay another service to perform a specialized computation or execute a task.
In each case, the economic transaction could be handled through a standardized software interface.
For businesses, this introduces a possible alternative to traditional subscriptions: charging directly for the value of each request.
For AI developers, it creates a mechanism for agents to obtain paid resources without requiring a custom payment integration for every provider.
However, pay-per-request pricing is not inherently better than subscriptions. Its advantages depend on transaction frequency, information value, operating costs, and customer behaviour.
Why might the internet move toward agent-based payments?
Artificial intelligence is progressing beyond generating responses toward systems that can interact with tools and complete multistep tasks.
This creates demand for supporting infrastructure that handles authentication, permissions, information access, and payments.
The movement is already visible across the technology industry.
Coinbase introduced x402 as an approach to programmatic payments over HTTP. Cloudflare has documented x402 integrations for paid APIs and AI applications. Google has also introduced the Agent Payments Protocol (AP2), addressing authorization and trust in transactions involving AI agents.
These initiatives approach different parts of the problem, but they point toward a common direction: making commercial infrastructure more accessible to software acting on behalf of users.
My interest in x402 comes from this broader development.
If AI agents become significant participants in the digital economy, the infrastructure supporting transactions between software systems will become increasingly important.
Whether x402 becomes a dominant standard remains uncertain. Adoption will depend on security, interoperability, business incentives, regulatory requirements, and competition from alternative payment systems.
Nevertheless, its architecture provides an opportunity to explore what an internet designed for both human users and autonomous software could look like.
Further reading: Cloudflare — x402 Documentation and Google — Agent Payments Protocol.
How Harbour/402 Works
Harbour/402 uses a fictional marine supply company to demonstrate how a business might monetize its information.
The public-facing interface resembles a conventional supplier portal. Visitors can view marine inventory, service categories, and company information.
Additional structured information is available through a payment-protected API endpoint.
A visitor can connect a compatible wallet and authorize a payment of 0.01 test USDC on Base Sepolia, an Ethereum-compatible test network.
Once the payment is successfully processed, the application returns the protected information as JSON.
The demonstration contains fictional data and uses testnet cryptocurrency without real monetary value. It is intended to demonstrate the payment mechanism, not to operate as a commercial information marketplace.
Technical Overview
Application architecture
I built Harbour/402 using a relatively lightweight application stack:
| Component | Technology |
|---|---|
| Backend and API | Python, FastAPI |
| Payment protocol | x402 SDK |
| Blockchain network | Base Sepolia testnet |
| Payment asset | Test USDC |
| Wallet interaction | MetaMask |
| Source control | Git and GitHub |
| Hosting and deployment | Render |
| Frontend | HTML, CSS, JavaScript |
The architecture separates the customer-facing website from the underlying information API.
The website presents the business and initiates the payment experience. The backend enforces access requirements and returns information only after successful payment processing.
Understanding the HTTP 402 transaction
The central feature is a protected API endpoint:
GET /api/info
Without valid payment authorization, the server returns an HTTP 402 Payment Required response.
Under the x402 version 2 HTTP specification, payment requirements can be communicated through a PAYMENT-REQUIRED header. These requirements identify information such as the accepted payment asset, network, recipient, and amount.
A compatible client can then create a signed payment authorization and repeat its request using a PAYMENT-SIGNATURE header.
The server verifies the authorization and processes settlement, either directly or through a payment facilitator. Once the required checks succeed, it returns the protected information and payment confirmation.
A facilitator helps handle payment verification and blockchain settlement without requiring every application developer to implement those processes independently.
Harbour/402 uses x402 middleware to enforce this payment requirement rather than relying on a frontend button to protect the information.
This matters because access control must be enforced by the backend, independently of what the user sees in the browser.
Technical references: x402 HTTP Transport Specification and x402 Facilitator Documentation.
Security and testing
Beyond completing a successful payment, I wanted to test how the application behaved when requests were invalid or unauthorized.
The development process included automated API tests, payment validation checks, and manual testing of the complete transaction.
Key checks included:
- Confirming that unpaid requests cannot access the protected information.
- Rejecting malformed or invalid payment authorizations.
- Testing whether previously used payment authorizations could be reused.
- Ensuring sensitive configuration values are stored outside the public source code.
- Preventing unintended access to local data files.
I also tested the full payment process using separate buyer and receiving wallets.
These checks improved confidence in the demonstration’s implementation, but they do not constitute a comprehensive security audit or establish production readiness.
What I Learned
I approached Harbour/402 as a nontechnical founder interested in understanding emerging internet infrastructure through practical experimentation.
My objective was to move beyond researching a technology and build something that would require me to understand how it actually works.
1. Understanding how software systems connect
Developing Harbour/402 helped me better understand the relationships between frontend interfaces, backend applications, APIs, payment services, blockchain networks, and deployment infrastructure.
Concepts such as HTTP responses, environment variables, API endpoints, and server-side authorization became substantially clearer when I had to implement and troubleshoot them.
I also gained practical experience with GitHub branches, automated testing, and deploying applications through Render.
2. Payment integration is also a security problem
Initially, the objective was simple: make a payment and unlock information.
However, creating a functioning transaction was only part of the challenge.
I needed to consider what would happen if someone attempted to access the API directly, submitted an invalid payment, or reused a previous authorization.
This highlighted the difference between a feature that appears to work and a system that reliably enforces its intended behaviour.
3. A technical demonstration still needs good product design
Once the underlying payment mechanism worked, I focused on the user experience.
Rather than presenting Harbour/402 as a cryptocurrency experiment, I designed it to resemble a functioning marine supplier portal.
The objective was to make the business use case understandable before introducing the payment technology.
This reflects a broader lesson from my entrepreneurial experience: technical capabilities become commercially meaningful when they solve recognizable problems.
4. Technical feasibility does not establish commercial demand
Harbour/402 demonstrates that a business can protect an information endpoint with x402 and release its contents following a successful test payment.
It does not demonstrate that customers will purchase the information, that AI agents will consistently use these services, or that businesses will pay to implement the technology.
Those questions require separate commercial validation.
The next stage of this exploration is therefore to investigate which businesses possess information worth monetizing, who would purchase it, and whether x402 offers a meaningful advantage over existing distribution and payment methods.
5. AI capabilities depend on the infrastructure around them
My most important takeaway concerns the relationship between advancing AI capabilities and the internet infrastructure supporting them.
AI models are becoming more capable, but their ability to complete real-world tasks also depends on whether they can discover information, access services, authenticate their authority, and carry out transactions.
x402 addresses one part of this larger problem: payments.
Building Harbour/402 gave me a practical introduction to how financial transactions might become part of ordinary software communication.
It also reinforced my interest in developing infrastructure that makes the internet more accessible and useful to AI systems.
Explore the Project
Harbour/402 is a learning project and technical proof of concept. The code is publicly available, and the demonstration can be explored through the links below.
Note: Harbour/402 uses fictional business information and Base Sepolia testnet payments. Test USDC has no real monetary value.
References and Further Reading
- Coinbase. Introducing x402: A New Standard for Internet-Native Payments. Introduction to the protocol and potential applications.
- x402 Foundation. Official x402 Repository. Open-source implementation, documentation, and protocol specifications.
- x402 Foundation. HTTP Transport Specification, Version 2. Technical reference for payment messages and HTTP response handling.
- x402 Foundation. Facilitator Documentation. Explanation of verification and settlement infrastructure.
- Cloudflare. x402 — Agents Documentation. Developer documentation for implementing paid resources using x402.
- Google Cloud. Powering AI Commerce with the Agent Payments Protocol. September 16, 2025. Industry developments concerning authorization and payments involving AI agents.
- Solana Foundation. Building x402 V2 Payments on Solana. An additional implementation illustrating the protocol’s use beyond one blockchain network.