Agent commerce · Paid APIs and tools

Turn one useful resource into a paid door for AI agents.

I help teams choose a resource agents will pay to use, expose it through a clean API or tool, and implement the x402 request, payment, verification, and delivery path. The first release stays narrow enough to test demand without rebuilding the whole billing stack.

Discuss an x402 implementation Direct answer

Direct answer

The engagement connects the commercial idea to a working paid request.

An x402 integration lets a machine discover that an HTTP resource has a price, authorize payment, retry the request with proof, and receive the response without a human checkout or account-first flow. I use it for bounded agent-facing resources such as a paid API result, dataset lookup, MCP tool call, protected file, or job-specific expert tool. The work includes the product decision around the resource and price, the seller and buyer paths, and the controls needed to release one credible paid endpoint.

Related work

One technical problem often crosses several systems.

The capabilities page shows the other ways I can help and the case studies behind them.

When this helps

Use x402 when the value is specific enough to price per request.

You have an API, dataset, search index, content archive, or tool whose output saves an agent time or improves an expensive decision.
The buyer may be an AI agent or automated workflow that should be able to pay and continue without waiting for a person to create an account.
A fixed-price call, usage cap, or small metered charge fits the resource better than a sales call or full subscription.
You want to test one paid route before investing in a broader agent-commerce product.
The underlying content or data can be made clean, current, licensable, and useful through an API, MCP tool, feed, or search endpoint.
Your team can support crypto-native settlement, a receiving wallet, and the operational decisions that come with irreversible payments.

When to pause

Do not add a payment rail before the resource earns its price.

The resource is still a generic AI wrapper with no proprietary data, trusted source, repeatable job, or measurable advantage.
Customers need seats, invoices, account recovery, support entitlements, procurement, or complex contracts before they can buy.
The rights to sell or expose the underlying data, content, or expert archive are unclear.
The price depends on several human approvals or cannot be bounded before the protected response is delivered.
The team cannot yet own the wallet, network, facilitator, refund, monitoring, and support decisions.

What the work covers

One release covers the resource, interface, payment gate, and operating evidence.

The useful unit is not “add x402 everywhere.” It is one agent job with a resource worth buying, a clear interface, a deliberate price, and enough telemetry to decide what happens next.

Paid-resource definition

Choose the narrow decision, lookup, answer, file, or tool call an agent needs repeatedly. Verify the source rights, freshness requirement, buyer, free-versus-paid boundary, and first pricing hypothesis before implementation.

Agent-readable interface

Turn the useful material into a stable API route, MCP tool, search endpoint, feed, or protected asset with a documented request and response contract. Clean data and predictable errors come before payment middleware.

x402 seller and buyer paths

Implement HTTP 402 payment requirements, wallet and network configuration, the chosen payment scheme, verification or facilitator handling, signed retry behaviour, settlement feedback, and protected delivery.

Release controls and measurement

Add unpaid, paid, rejected, duplicate, timeout, and settlement tests; log the commercial events without exposing payment credentials; and release with rate limits, support notes, and a small measurement plan.

Compare the options

Use the commercial gate that matches the buying relationship.

Gate	Best fit	Main limitation
x402 paid request	One-off or metered machine purchases where an agent should discover the price, pay, retry, and continue inside the HTTP flow.	It does not replace customer accounts, support plans, refunds, procurement, or wider billing operations.
Account and API key	Recurring developer products with quotas, dashboards, teams, identity, support, and a continuing customer relationship.	Signup and provisioning add friction to one-off agent purchases.
Subscription or metered SaaS billing	Ongoing use where invoices, cards, tax handling, entitlements, and predictable account-level billing matter.	The account lifecycle may be heavier than a small resource bought by a machine at request time.
Browser checkout or content paywall	Human buyers who read, compare plans, manage access, and expect a conventional checkout and recovery journey.	It is not a native purchase loop for autonomous tools or agents.

How the work runs

Start manually, prove one paid job, then productize what repeats.

Choose the resource and buyer

Name the agent job, the valuable output, who already pays for help, what changes often, and why a paid request is better than an account or subscription.

Package and price the interface

Clean the source material, define the API or tool contract, separate free discovery from paid value, and choose a fixed, capped, or deferred settlement shape.

Build and test both sides

Protect the seller route, configure settlement, and exercise the buyer flow from the initial 402 through signed retry, payment verification, and final delivery.

Release a measured pilot

Launch one narrow door, observe requests and failures, review whether the price and output create repeat use, and expand only when the evidence supports it.

Sources

The offer combines the market framing with the protocol’s implementation contract.

Cloudflare will make 1000+ AI millionaires

Greg Isenberg’s framing of the agent internet: clean resources, agent-readable interfaces, request-level payment, and manual services that can later become products.

x402 introduction

The protocol overview and the request, payment requirement, signed retry, verification, settlement, and delivery flow.

x402 quickstart for sellers

Seller-side middleware, route protection, facilitator configuration, payment schemes, network identifiers, and production considerations.

x402 quickstart for buyers

Buyer-side signing, automatic retry behaviour, supported clients, and paid-request handling.

MCP server with x402

A concrete agent-facing tool flow where MCP access is paid through x402.

Relevant work

The public proof is a working x402 gate around an agent-facing API.

Agentic Brief already uses the official x402 SDKs around a protected HTTP route. The implementation covers an exact EVM payment scheme, PAYMENT-REQUIRED and PAYMENT-RESPONSE handling, local and live facilitator modes, free and paid output boundaries, and regression tests for both the commercial gate and the final response. The related Insight explains the protocol choices and their limits.

FAQ

Questions to settle before an x402 implementation.

What can I sell through x402?

A bounded HTTP resource: an API result, dataset lookup, MCP tool call, protected file, search response, content answer, or another output whose value and delivery rules are clear. The stronger offers are clean, trusted, useful, repeatable, and difficult to replace with a generic model response.

Do I need Cloudflare to use x402?

No. x402 is an open protocol and can be implemented in different server stacks. Cloudflare can be a useful deployment and enforcement layer when the resource already runs there or edge verification fits the architecture, but the route, buyer flow, settlement choice, and operating model still need to be designed.

Does x402 replace Stripe, subscriptions, or API keys?

No. It fits request-time machine purchases. Conventional billing remains the better tool for card payments, invoices, tax workflows, seats, account recovery, support entitlements, and longer customer relationships. A product can use both when the boundaries are explicit.

Should I start with an API, an MCP tool, or a paid page?

Start with the interface closest to the buyer’s job. Use an API for a stable programmatic contract, an MCP tool when the resource belongs inside an agent tool workflow, and a protected page or file when retrieval itself is the product. The first version should prove one use case, not every channel.

How do we choose the first price?

Price the outcome and the cost of delivering it, then test the smallest credible unit. A fixed price is easiest when the work is known before the request. A usage cap is useful only when the final work varies. The pilot should record paid requests, repeat use, failed settlements, and support cost before the price is treated as settled.

What must be tested before launch?

At minimum: unpaid access, a valid paid retry, invalid or expired authorization, wrong network or amount, duplicate requests, facilitator failure, timeouts, protected-output leakage, settlement feedback, rate limits, logs, and the behaviour clients should follow when payment or delivery fails.

Start with one paid resource

Bring the API, dataset, archive, or tool an agent should be able to buy.

I will help decide whether x402 is the right gate, define the smallest paid job, and scope the seller, buyer, settlement, test, and release work without pretending the protocol is the whole business.

Discuss an x402 implementation