x402 isn’t good (yet) — Jan Curn, Apify

MCP was exciting, widely discussed, and still clunky when David Cramer delivered “MCP Is Not Good Yet” at the previous AI Engineer World’s Fair. Sentry subsequently built an MCP server that Jan Curn praises, while MCP became a familiar way to connect tools to agents. That combination supplies the premise for this sequel: finding rough edges is part of building a useful integration.

Jan Curn, Apify’s founder and CEO, brings a concrete marketplace problem. At talk time, Apify had about 45,000 tools called Actors, spanning web-data extraction, search, maps, automation, and agentic tasks. Apify and community developers build them; customers pay to use them; Apify passes revenue to their creators. Curn reports community payouts exceeding $1 million per month. Making these tools purchasable by agents means connecting a new payment mechanism to an existing business.

Apify launched its x402 integration with Coinbase two days before the recording. Curn reports that it added 20,000 tools to an x402 catalog that previously contained about 2,000—roughly a tenfold expansion in available tools. Those numbers describe catalog supply. The reason to supply it is straightforward: an agent working without repeated human intervention needs a budget to acquire services as its task develops.

The payment landscape is already crowded. Curn runs through competing efforts from payment networks, technology companies, and crypto providers, then describes the difficulty of keeping up with them. Each wants a share of the transactions agents might eventually generate. For a service marketplace, that competition creates an immediate integration problem: which payment systems should it accept?

Curn’s enthusiasm comes with some personality: “I’m not HODLing anything.” Agent commerce gives a longtime crypto skeptic a practical reason to reconsider. His case has three parts:

• Small payments: Conventional methods such as cards, PayPal, and bank payments have costs that make tiny individual purchases unattractive. Agent-to-service interactions could require many such purchases.
• Seller certainty: Human commerce has identity and fraud signals that sellers can use when accepting payments subject to disputes. Agent identity remains unsettled in this account, so Curn wants sellers to receive payments that buyers cannot later reverse through a bank dispute.
• Shared infrastructure: A sufficiently decentralized blockchain could serve as a public payment standard without one company controlling the network and extracting fees through its dominant position.

The decentralization claim depends on how the network is governed. Removing buyer disputes also leaves a separate question: what protects the buyer if the paid service fails? That question returns when Apify starts collecting money before running a job.

Apify’s implementation experience focuses on x402 from Coinbase and MPP, the Machine Payments Protocol associated here with Stripe. Curn reports that the previous day’s figures put x402 about twenty times ahead of MPP in both transaction count and volume. That talk-time comparison helped Apify prioritize x402, although it added MPP along the way.

x402 gives the payment idea a recognizable HTTP entry point: 402 Payment Required, a status code Curn describes as having waited almost thirty years for its moment. The integration difficulties begin with what happens after the server asks for payment.

The flow described in the recording starts with an ordinary API request. The server responds with 402 Payment Required. The client signs a payment authorization and sends it back. The server asks a facilitator, such as Coinbase, to verify it. Once verification succeeds, the server does the work, then asks the facilitator to settle the payment. Settlement performs the blockchain operation that transfers money to the seller.

Verification and settlement answer different questions. A valid authorization can pass verification without preventing the buyer from spending the same wallet funds elsewhere before settlement. Curn illustrates the exposure with one wallet generating 1,000 signatures and sending 1,000 requests. If sellers treat those signatures as secured funds, they can all begin work against money that will not cover all the requests.

Follow one of those requests through its consequence. A seller receives a signature, gets a successful verification, and starts a job that calls a paid external service. Meanwhile, the buyer spends the wallet’s money in another transaction. When the seller finally requests settlement, the funds are gone. Withholding the result might stop the buyer from receiving the output, but it cannot recover the external-service cost already incurred.

Where does changing the order protect that seller? The comparison below places the costly work on either side of settlement. In the first path, the seller incurs costs while payment remains unsecured. In the second, the seller waits for payment before starting.

Settling first is the available workaround. It is straightforward for a fixed-price call, but places an obligation on the other side: the buyer has paid before receiving the service, so the server must finish the work successfully. Curn considers doing work before settlement tolerable for a simple API call with effectively zero marginal cost. Jobs that consume resources or purchase upstream services need stronger protection.

A separate difficulty appears when payment and authentication share an endpoint. In the requirements Curn describes, x402 demands an initial 402, while MCP authentication demands a 401. An HTTP response has one status code. A server cannot satisfy both initial-response requirements simultaneously.

The workaround is to split access across hostnames: one host for x402 payments, another for MCP, perhaps another for MPP. That avoids asking one response to carry incompatible status codes, but duplicates the service’s entry points around payment choices. Curn’s analogy is having twenty different Amazons for different credit cards. The customer wants the same service; the payment method should not require a different storefront.

His proposed protocol change is to allow payment requirements to travel through headers without mandating the 402 status. A response could then carry payment information while using the status code needed by another protocol. This is a suggestion in the recording, rather than an implemented solution.

The original Exact scheme fits a simple purchase: pay a fixed fee for one API call. Apify Actors have a different cost shape. They often run batch jobs, lasting anywhere from a few seconds to a few hours, and consume resources along the way. Metered billing follows that consumption; the final price need not be known when execution begins.

Coinbase introduced x402 with Exact in May 2025. Curn describes Up To as a later scheme promised with the protocol’s December 2025 update and released after a further wait. It lets a client authorize a ceiling—for example, $5—and allows the server to charge an amount within that ceiling. This answers how much the seller may charge, but leaves the earlier spending window intact. Permission to charge up to $5 does not secure $5 for the job.

Apify therefore used Exact to collect a fixed amount, ran the job, and refunded whatever the job did not spend. The initial payment covers work before the final bill is known, and the refund reconciles that payment with actual consumption.

The workaround carries two distinct costs:

• Two blockchain transactions: Collecting payment and returning the remainder each require a transaction, adding settlement time and potentially fees.
• Trust in the refund: The buyer hands over the full amount and depends on the server to return the unused portion. Curn considers this a milder issue than exposing the seller to unpaid work, but still finds the arrangement clunky.

Batch Settlement changes where the money sits while work proceeds. In Curn’s account, the client first makes a real blockchain deposit into escrow. The server returns a cryptographic voucher that the client can use to sign small payments within the batch. Requests—for API calls or individual tokens, for example—then carry those signed micropayments.

The small payments occur off chain. The server accumulates them and periodically settles them together through a blockchain transaction. Settlement can happen multiple times before the remaining escrow is released. Frequent service purchases therefore do not each require a blockchain write: money enters escrow up front, while the chain records aggregated settlement afterward.

Which operations still reach the blockchain? The diagram distinguishes the deposit and batch settlement from the repeated off-chain requests between them. Escrow changes the funding arrangement; batching reduces how often individual purchases need a chain write. Apify was working on this scheme but had not implemented it at talk time, so its practical benefits for Actors remained prospective.

Apify still needed a usable integration without rebuilding its API around every emerging payment standard. Tens of thousands of customers depended on that API. Separate payment-specific service endpoints and awkward adaptations of variable usage would make the established product harder to maintain.

The resulting entry point is AGI.Apify.com: Agent General Interface. The acronym is a joke with an architectural point. The interface is a simple website containing one Markdown document that explains how agents can buy access through x402 or MPP. Curn expects agents to read changed instructions as the purchasing flow evolves, allowing Apify to iterate without continually changing the API used by existing customers.

The purchase produces a prepaid Apify token. In Curn’s example, an agent pays $5 and receives that token, then uses it through the normal API or MCP to run jobs. The agent-facing page handles how to buy access; existing interfaces handle how to spend that access on Actors. The Apify API documentation and MCP integration documentation explain the execution side.

The prepaid token has different terms from the earlier charge-and-refund job workaround. The AGI service documentation supplied as of September 19, 2026 specifies a $1 minimum purchase, non-refundable unused credit, and a temporary account deleted after a 14-day lifetime. The token carries a fixed spending cap, and usage is metered against its balance. Buying credit therefore does not promise a refund after each job.

The live demonstration attempts a smaller purchase. Apify had built a local wallet tool to create a cryptographic key, fund it, and display a QR code. The wallet begins with $10. Curn requests a token carrying $1 of credit from AGI and receives 402 Payment Required. He then uses an MCP CLI client to sign the payment. The request has moved from asking for access to answering a payment challenge, but the demo fails before a completed purchase is shown. Time runs out before token delivery or subsequent Actor execution is demonstrated.

Despite the failed demo, Curn’s closing invitation is practical: try building with the payment flow. Crypto terminology had made it seem intimidating even to him, but he found getting started much simpler than expected and estimates an initial experiment can take about ten minutes. The invitation is to explore an early system whose integration problems are still being worked out.

The scale remains small in his account: roughly $1 million in monthly transaction volume for the emerging payment ecosystem. That measures payment activity, distinct from Apify’s earlier $1 million-plus monthly creator payouts. Curn’s growth forecast depends on a change in agent economics: when subsidized model tokens give way to costs users must actually pay, generating a bespoke solution may become less attractive than purchasing an existing service.

An agent then needs a way to choose a service, fund access, and use it when buying is cheaper or more effective than building from scratch. Curn predicts this could make agent payments grow sharply and eventually let agent commerce overtake ordinary commerce. That remains his forecast. The shipped integration offers a concrete place to test the smaller proposition that agents can buy useful capabilities.