# x402 Isn't Good (Yet)

Jan Curn, Apify | AI Engineer World's Fair 2026 | 20:48

Source: https://www.youtube.com/watch?v=h6mi88VrPtQ
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/x402-isnt-good-yet
Published: 2026-09-01
Tags: enterprise, tool-use

## TL;DR
- x402 lets a seller verify a payment signature before settlement, leaving a window where the buyer can spend the same money again.
- x402's 402 requirement conflicts with MCP's 401 requirement, while its exact and up-to payment schemes fit poorly with long-running, metered tools.
- Apify currently charges an amount in full and refunds the remainder, while investigating batch settlement and using a markdown-based agent interface to sell prepaid tokens.

## Summary
Jan Curn presents x402 as an exciting protocol that still has serious implementation problems. Apify operates a marketplace with about 45,000 tools, so it needs payments that work for agents running anything from simple API calls to jobs lasting hours. The main problem is the gap between signature verification and blockchain settlement. A client can create many signatures against the same wallet and send them to different sellers before any transaction is settled. Waiting for settlement avoids that risk, but it does not fit every service. Curn also describes the conflict between x402's required HTTP 402 response and MCP's required 401 response, which pushes companies toward separate payment hostnames. Apify's workaround for metered jobs is to charge in full and refund unused money, creating another transaction and a trust requirement. He is testing batch settlement and has shipped a markdown page where agents buy prepaid Apify tokens.

## Key ideas
### MCP became widely adopted even though it started with rough edges
[00:01](https://www.youtube.com/watch?v=h6mi88VrPtQ&t=1s)
Curn opens by recalling David Cramer's "MCP isn't good yet" talk from the previous AI Engineer World's Fair. MCP was heavily hyped but clunky, and Cramer advised people to experiment while keeping expectations low. Curn says MCP then became widely adopted by major AI products. Claude offers MCP connectors, while ChatGPT calls its integrations apps. He also points out that Sentry followed the talk by building what he considers one of the best MCP servers. Curn uses that story as the model for his own argument: x402 is exciting, but engineers should expect rough edges and work through them.

### Apify wants agent payment protocols to expose its large tool marketplace
[02:02](https://www.youtube.com/watch?v=h6mi88VrPtQ&t=122s)
Apify has about 45,000 tools, which it calls actors. They cover data extraction from social media, e-commerce, travel, hospitality, search engines, and maps, along with agentic automations. Some come from the community and some from Apify. Community developers receive more than $1 million per month in payouts from tool sales. Curn says this makes agent payments directly relevant to Apify. Two days before the talk, Apify launched an x402 integration with Coinbase. The x402 market had about 2,000 tools before the launch, and Apify added another 20,000. Curn describes that as making the catalog ten times larger.

### Crypto fits agent payments because sellers cannot rely on human payment protections
[04:47](https://www.youtube.com/watch?v=h6mi88VrPtQ&t=287s)
Curn lists a growing set of agent payment standards, including L402, Mastercard Agent Pay, x402, Skyfire's KY Pay, Google's AP2 and UCP, OpenAI and Stripe's ACP, Visa's TAP, and several others. He says crypto finally has a practical use case beyond trading, gambling, illegal marketplaces, and hiding money. Traditional methods such as credit cards, PayPal, ACH, and bank debit are expensive for microtransactions. Sellers also face disputes, while an agent's identity and ability to dispute a charge may be unclear. Curn argues that agent commerce needs one-way payments that are safe for the seller. He also prefers a decentralized public system over one controlled by a dominant payment company.

### x402's settlement gap lets one wallet fund many competing requests
[08:25](https://www.youtube.com/watch?v=h6mi88VrPtQ&t=505s)
x402 uses HTTP 402 Payment Required, a status code introduced almost 30 years ago. The client first calls a server, which must respond with 402. The client then creates a payment signature and sends it back. A facilitator verifies the signature, after which the server is expected to do the work. Settlement happens afterward, when the facilitator submits the transaction to the blockchain. Curn identifies the problem in that order. Until the transaction is submitted, the buyer can reuse the same wallet and money elsewhere. A client could create 1,000 signatures and send them to 1,000 requests. A seller can safely do low-cost work before settlement, but expensive work or work that requires paying another provider creates a direct risk.

### The protocol conflict between HTTP 402 and MCP 401 pushes teams toward duplicate hosts
[11:10](https://www.youtube.com/watch?v=h6mi88VrPtQ&t=670s)
x402 requires the server's first response to use HTTP 402, while MCP requires HTTP 401. A response cannot carry both status codes. Curn says companies often resolve this by creating a separate hostname for the payment gateway, such as an x402-specific host alongside their normal MCP or MPP host. He calls this an antipattern because the same API is duplicated for different payment methods. His preferred solution would put the payment information in headers, such as a payment-required header, without forcing the server to choose a status code that conflicts with another protocol.

### Exact and up-to payments do not solve the risk for metered jobs
[12:59](https://www.youtube.com/watch?v=h6mi88VrPtQ&t=779s)
The original x402 exact payment scheme charges a fixed amount for each call, which works for simple APIs. Apify's actors can run for a few seconds or several hours and consume different amounts of resources, so they need usage-based billing. Coinbase later introduced the up-to scheme, where a client sets a maximum such as $5 and the server can charge any amount up to that limit. Curn says up-to still leaves the same double-spending window as exact. Apify therefore charges the full amount, runs the job, and refunds whatever was not used. That workaround works, but it creates two blockchain transactions, adds settlement time and possible fees, and asks the client to trust the server to return the remainder.

### Batch settlement could move frequent payments off-chain until a later transaction
[13:55](https://www.youtube.com/watch?v=h6mi88VrPtQ&t=835s)
Curn describes Coinbase's batch settlement scheme, which Apify had not implemented yet. The client first deposits money into an escrow arrangement on the blockchain. It then receives a cryptographic voucher that can sign many small payments. Individual API calls or token purchases use these vouchers and remain off-chain, where they avoid the delay and cost of writing every payment to the blockchain. Once enough payments accumulate, the parties settle them in a batch. The escrow can later release the unused balance. Curn says this approach looks promising, but Apify was still working on its implementation and had not yet reported results.

### Apify uses a markdown page to sell prepaid tokens without changing its existing API
[16:38](https://www.youtube.com/watch?v=h6mi88VrPtQ&t=998s)
Apify did not want separate endpoints for each payment service, a special variable-usage hack, or large changes to an API used by tens of thousands of customers. Its workaround is AGI, short for Agent General Interface. The service is a simple website containing one markdown document written for agents rather than people. The instructions explain how an agent can buy from Apify through x402 or MPP. An agent sends money, such as $5, and receives a prepaid Apify token. It can then use that token with Apify's normal API or MCP integration. Curn says this lets Apify update the agent instructions quickly without treating them like a permanently fixed API.

### The current ecosystem is early, with small transaction volume and incomplete tooling
[19:26](https://www.youtube.com/watch?v=h6mi88VrPtQ&t=1166s)
Curn says agents can get started with x402 in about 10 minutes, although the surrounding ecosystem is still immature. In Apify's demo, the team had to build its own local wallet tool to create a cryptographic key, fund it, and display a QR code. The demo itself failed during the presentation. He estimates current x402 transaction volume at about $1 million per month and calls that small compared with the wider economy. His longer-term view is that agents will need budgets for longer tasks, and that paying for external services may become more attractive once token subsidies end. He expects agent payments to grow, but presents the protocol's present limitations plainly.

## Notable quotes
- "While X402 is very exciting technology, it has also still some rough edges." (01:22)
- "Basically, there is like nothing preventing the client from double spending." (09:59)
- "Why would you have to duplicate your API host for different payment providers?" (11:36)
- "This protocol should support these things out of the box." (14:27)
- "It's not designed for people, so it kind of looks ugly, but it's okay." (17:06)

## Tools & references mentioned
- Apify
- x402
- Coinbase
- MCP
- Sentry
- David Cramer
- Claude
- ChatGPT
- L402
- Mastercard Agent Pay
- Skyfire
- Visa
- Google AP2
- OpenAI
- Stripe
- Visa TAP
- Google UCP
- Shopify
- Alipay
- UnionPay
- OKX
- MPP
- AGI
- Agent General Interface

## Who should watch
- You are adding payments to agent-accessible APIs and need to understand why signature verification alone does not protect work that happens before settlement.
- Your service has metered or long-running jobs and the fixed-price model of x402 exact payments does not match your costs.
- You maintain an MCP server or an existing API and want to avoid creating separate payment-specific hosts or changing the public API.
