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

Transcript

Hello everyone. Last year here at AI Engineer World's Fair, David Kramer from Sentry had a mildly provocative talk called MCP isn't good yet. And back then, MCP was the new kid on the block, right? There was a lot of hype around it, people were excited about it, but it wasn't really developed back then very much, and it was fairly clunky. And in this talk, David argued, hey, this technology is cool, but it has a lot of rough edges, right? So just go play with it, but have your expectations low, right? By the way, they went on and actually built one of the best MCP servers on the market, Sentry MCP. It's a very well-designed server, nice design and so on. And actually, over the last year, MCP became a standard that's widely adopted across the industry. The top AI agents like Claude and ChatGPT, actually Claude offers MCP connectors, right? So you can plug tools into your AI agents. ChatGPT calls it apps, but you can also, the directory of different services you can plug into your Claude. And it actually became a standard thing for agent-to-agent interaction, right? And despite a little hate about MCP, I have yet to see CLI connectors in any of these agents, right? So MCP won. And so, inspired by David's talk, today I have a similar talk, which is called X402 isn't good yet. And in that talk, I would like to argue that while X402 is very exciting technology, it does also still have some rough edges. And perhaps if I do it as well, we'll also build one of the best integrations with X402 on the market like Sentry did with MCP. My name is Jan Cern. I'm the founder and CEO of Appify. And for those who don't know, Appify is the largest marketplace of tools for AI. We have about 45,000 of these tools. We call them actors. And they are spanning use cases like extraction of data from social media sites, e-commerce, hospitality, travel, search engines, maps. But over time, also AI agents or agentic use cases, different automations and so on, right? And some of these tools, some of these actors, are built by our community. Some are built by us. And our community is making now more than $1 million per month on payouts by selling these tools, right? So they build the tools, we sell them to users, and we pass the money to them. And so it's a thriving marketplace. And I guess by now everybody understands why we are so excited about agentic payments, right? Because we really want our tools to be easily accessible to agents, wherever they are, with whatever protocol is out there. Just two days ago, we launched together with Coinbase our X402 integration. I would say the launch went pretty viral. We got about a million views. And before this launch, there were about 2,000 tools available on the agentic market on X402. We brought another 20,000 tools. So basically, we 10x'd the size of the agentic market on X402. So this is very exciting for us, and we believe also for the community. And actually, we're very excited about this topic long-term. So actually, last year here at AI Engineer World's Fair, I was the only one talking about agentic commerce and agentic economy in general, and really argued that in a couple of years, most of the economic activity in the world will be done autonomously between agents. And actually, it looks like it really picked up. I think now everybody understands that agents, in order to get work done, or longer jobs without intervention, will actually need to have budget as well, right? It's not like you can do a lot of things in this world without money. And once agents can be trusted with money, they will complete far longer and more complex tasks than they can do now. So obviously, a lot of people understand this across the industry. So over the past year or so, we saw a lot of new standards or agentic payments protocols coming to the market, because obviously every player in finance or payments is very excited about this opportunity, because everybody wants to get a part of this huge future agentic economy and transaction volume. So first was L402. It was in mid-2020. But then MasterCard AgentPay, we have X402 by Coinbase in May last year, KYPay from Skyfire with Visa, APA2 by Google, ACP by OpenAI and Stripe, Tab by Visa, UCP by Google and Shopify, ACTP by Alipay, MPP by Stripe and Tempo, AMP by Alipay, APOP by UnionPay, APP by OKEx, and finally, AgentPay for Machines by MasterCard. You can see this is really becoming a heated battleground for the future of agentic commerce. And it's really hard to keep track of all the standards and all the technologies. We're trying to. But I would say for the crypto world, actually, Svix asked all the speakers not to use sloppy AI-generated images in presentations, but I couldn't resist myself here. I think for the crypto world, agentic commerce has been super exciting news, because finally there is a really solid use case for crypto, except for trading and gambling, buying illegal substances on marketplaces, and hiding money away from your spouses, right? So finally, agentic commerce really brings a long-sought use case for crypto that I actually think is pretty solid. And I'm not a crypto bro myself. I'm not hodling anything, actually. I was fairly skeptical of crypto all the time. But I feel that crypto is really well suited for agentic commerce or agentic payments. Why? Because the traditional payment methods designed for people are super expensive, right? And credit cards, PayPal, ACH, and bank debits, they cannot be used for microtransactions. They are just very ineffective, as we saw in the previous presentation as well. But there's another problem. There are buyer disputes. Anybody who's selling things online, you know that there are some people who buy services from your website and then dispute the payment and ask for a refund, or dispute it through their bank and you have to pay for it. In the traditional human economy, there are some trust signals you can do with credit cards. Stripe and others have different services to prevent fraud and so on. But in agentic interaction, you really have no idea who the agent is. There's no agent identity. I mean, there are some standards being developed, but it's really not clear who you are transacting with. So you just can't allow them to dispute the payments. It really needs to be a one-way transaction, and it needs to be safe for you, right? So, I think crypto is a superposition for that, but also there's an important part. Crypto, if done well, is truly decentralized blockchain, where no company has a majority of the vote in the network. It can be really decentralized, and it can be a public standard not owned by a single company who, for example, like Visa or MasterCard, would abuse their dominant power to extract fees from the system. So I'm very, very bullish on crypto in this space, and there are basically currently two largest crypto payment providers for agentic payments. One is X402 from Coinbase, and second was MPP, Machine Payments Protocol, from Stripe. Looking at the stats just yesterday, X402 is 20 times larger in the number of transactions and the volume. So obviously, we went first with implementation of X402, but we added MPP in the process as well. And today, I'm gonna share a bit of our experience. This was also presented in the slide before. X402 built on the status code introduced almost 30 years ago in the original HTTP specification, called 402 Payment Required. So this status code was waiting for 30 years patiently for someone to pick it up. And obviously, Coinbase took that opportunity because, obviously, it's great for marketing. We finally make internet money work. It's awesome. So how it works, I'll just go quickly because we saw it in the last presentation as well. So first, the client initiates, calls server with some API request. The server responds, and actually this is important part. Specification enforces the server to respond 402 Payment Required. And today, I'm gonna share a bit of our experience. This was also presented in the slide before. [SPEAKER_00] X402 built on the status code introduced almost 30 years ago in the original HTTP specification, called 402 Payment Required. So, this status code was waiting for 30 years patiently for someone to pick it up. And, obviously, Coinbase took that opportunity because it's great for marketing. We're finally making internet money work. It's awesome. So, how it works, I'll just go quickly because we saw it in the last presentation as well. So, first, the client initiates calls server with some API request. The server responds, and actually, this is an important part. Specification enforces the server to respond 402 Payment Required. There is no other way to do that. It needs to use the 402. Then, the client creates a signature, withdrawing money from the wallet or allocating the budget from the wallet. Sends the signature to the server. Oh, the server verifies with the facilitator, which can be Coinbase, for example, but if the transaction is correct, it gets confirmation that the transaction is right. And then, it's supposed to do the work, right? But there is a problem there. I'll get to that in a second. And after the work is done, you send a transaction, you send a request to the facilitator to settle, which means physically transfer the money to your own wallet. And then facilitate performance operation on the blockchain. Transaction is confirmed. Everything is settled. All good. But there is a problem here. In this moment, until the transaction is actually submitted to the blockchain, the buyer can use the same wallet and same money to other transactions, basically. There is nothing preventing the client from double spending. So, it can just create 1,000 signatures like that, send 1,000 requests, and then maybe it will not get the results. But let's say, if it's a simple API call where there's zero marginal cost for you as a provider, you can do it. You can do the work before you settle. But imagine there is some non-tribal work, or maybe you have to pay external service. And then you realize, oh, the money is gone, right? The client skipped out on the bill, which is not great. So, there is a workaround for that. You can actually just do the work after the transaction is settled. You just need to make sure you actually get the work done, you don't fail, and so on, because then the clients would be pretty angry, I guess. But there is a workaround for this. And then you send 200 okay, and payment response, all good. So, there is a problem, though. As I showed before, the standard requires HTTP 402 as a first response from the server. But, MCP plus OUT requires HTTP 401. So, there are two conflicts in the standards, and each of them are actually enforcing it, and you cannot have two error codes or two status codes at the same time. So, how do companies resolve that? Well, quite often, they create a dedicated host name, host, let's say, x402.alchemy.com to serve just the agentic payments gateway. So, they implement basically a new API host just to serve the agentic payments, and then they have mcp.alchemy.com, and maybe mpp.alchemy.com, right? But it sounds like an antepattern. Why would you have to duplicate your API host for different payment providers? It's like, imagine you had amazon.com for different credit cards. You had 20 different Amazons. It doesn't make sense, right? So, I think that it's one of the weaknesses. I understand using HTTP 402 is great for marketing, but I think there should be, in protocol, some way to circumvent that and use just purely headers. So, for example, the payment-required header without the status code. And then originally, when Explorer 2 was created, it was designed for fixed payments. The first payments they introduced was called Xact, and it's for simple API calls. There's a fixed fee per transaction, fixed fee per call, which is great for simple APIs. But, unfortunately, Appify Actors are tools on the marketplace. They typically perform bad jobs, and they can run for a few seconds, but they can also run for a few hours and consume a lot of resources on the way. They are typically built as you go, metered billing. So, how to do that? How to put this on XFOR2? So, in May 2025, Coinbase introduced XFOR2 with the Xact Payment scheme. In December 2025, they announced the version 2 of the protocol, which was promising the App2 Payment scheme to fix this problem of metered billing. But it took another half a year, almost, to release the App2, finally. It was just two or three months ago. So, we were super excited about that. We were finally, we can make this work for our services. But then we realized, actually, the same double spending problem on Xact is also with up to. Up to, it was just a small improvement to the protocol, where, when you call the tool, you say, oh, my maximum is $5. And then the server can charge anything up to $5. But it doesn't prevent the double spending problem. So, basically, we are stuck again. So, we have to go back to the drawing boards and figure how to do that. And so, one way we did it was we just used Xact Payment scheme. So, fixed, charge a fixed payment. And then, after the job is done, we would refund the wallet with the leftover money, basically, the money that wasn't spent. That worked. But you charge, you do the work, you refund the remainder. But that means there's suddenly two blockchain transactions. That means there's a time to settle those transactions. There might be some fees associated with that, and so on. And also, the clients really need to trust the server to, hey, I give you the money, but you give it back, right? But I think that's a milder issue. But it just feels somehow clunky. Why would we need to do these workarounds? This protocol should support these things out of the box. So, just two months ago, Coinbase introduced a new payment scheme, which is called Batch Settlement, which looks very promising. We haven't implemented it yet, so we'll report soon on that. But basically, just quickly, it works like this. So first, the clients deposit some money. So basically, it's actually real transactional blockchain using some Ethereum virtual machine black magic. Basically, the money is put into escrow. And then, the client gets back a voucher from the server. Say, hey, here is some cryptographic voucher. And you can use it to sign microtransaction as part of this batch. And then the client sends requests, for example, API calls, or for individual tokens, whatever. And uses, passes this voucher to sign those micropayments. New payment scheme, which is called Batch Settlement, looks very promising. We haven't implemented it yet, so we'll report soon on that. But just quickly, it works like this: first the clients deposit some money. So, it's actually real transactional blockchain using some Ethereum virtual machine black magic; the money is put into escrow. And then the client gets back a voucher from the server. Say, hey, here is some cryptographic voucher. And you can use it to sign microtransaction as part of this batch. And then the client sends requests, for example, API calls, for individual tokens, whatever. And uses, passes this voucher to sign those micropayments. But these transactions are basically off-chain. They are just cryptographically guaranteed locally. But you don't need to write these to the blockchain. Which, again, is inefficient, slow, expensive. And then, at some point, you're like, hey, I accumulated a lot of these microtransactions, so I just settle them in batch. And then you perform the transaction on blockchain. And then you can do this a couple of times. And eventually, refund the rest of the money, release the escrow, right? So, actually, this looks really cool, very exciting. We're currently working on implementing it now. So, we'll see. But how did we resolve all this to make it work, right? So, we didn't really want to create new endpoints for different payment services. We didn't want to hack the variable usage to our services. And also, we really don't want to tweak too much our API, because we have tens of thousands of customers depending on that API. So, we just can't do whatever new agentic payment standard is out there, just implement it right away. So, to fix these problems, let me introduce our newest service on Apify, which is called agi.apify.com. And agi is not what you mean it is. Actually, it stands for Agent General Interface. So, instead of Application Programming Interface, we have Agent General Interface, which can change any time, but because it's used by agents, they're flexible, right? And on agi, it's just a simple website with one markdown document. It's not designed for people, so it looks ugly, but it's okay. And there are instructions for agents, like, hey, how can you actually buy things on Apify yourself through X402, MPP. We can iterate quickly on this website or on this service because agents can pick up new version. It's not a fixed API that needs to be backwards compatible all the time. And the way it works is, the agent comes to agi.apify.com, gets, can buy a prepaid token. So, they say, hey, here's five dollars. Give me Apify token. We give them Apify token back, and then they can use the Apify token through our normal API or through MCP to run our jobs and services normally. And it works pretty well. There is no skill required. You just point your agent to agi.apify.com. It picks it up. And I have here a short demo. We're running out of time. So, this is just an example of how it works. Actually, the X40 ecosystem is really early, so even we have to build our own local wallet tool, which you can create local cryptographic key to charge with money and show QR code. These things are still not existing. The ecosystem is super, super early. So, I have local wallet with $10. Then I call the agi.apify.com, allocate token with $1. I get back 402 payment required. So, there is this super long payment required signature. I use Apify, I use our MCPC, which is MCPC client, to sign the payment. And then I can send the oh, oh, oh, oh. This demo didn't work as expected. Here we go. Hmm. Well, anyway, I have one minute left. Demo will come later. Sorry about that. So, to conclude my presentation, really, try it out and try to build, try to use it. Actually, I tried to use it for the first time a couple of weeks ago. Because I always thought, oh, my God, it's somehow complicated. There is a lot of this weird crypto lingo. I don't know what it means. But actually, it's really, really simple to play with that. You can get up and running in ten minutes. And it's still super early. I think there's $1 million transaction volume per month. This is nothing, right? The economy is much, much bigger. But I think it will soon ramp up. And I think once this era of token subsidies will end, when you really will have to pay for the tokens that your agents consume, I think suddenly this decision whether to build or buy will make more economic sense, actually, to buy external services for those things rather than build from scratch. And I think at this time, really, the agent payments will explode. And very soon the agent e-commerce might overtake the normal commerce. Thanks a lot for your attention. And please come to join us in our booth. And actually, I have another talk coming up in two hours about MCP and CLI. So, you can check this one as well in Expo Stage 2. Thank you. Thank you. Thank you. So, basically, they say, like, hey, here's five dollars. Give me, give me Apify token. We give them, like, Apify token back, and then they can use the Apify token, uh, through our normal API or through MCP to, uh, run our jobs and services, you know, uh, normally. And it works pretty well. Uh, there is, like, no skill required. You just, like, point your agent to agi.apify.com. It picks it up. And, uh, I have here, like, a short demo. Uh, we're running out of time. So, this is just, like, example how it works, like. Actually, the X40 ecosystem is, like, really early, so that even, you know, uh, we have to build our own, like, local wallet, uh, tool, which you can, like, create, like, local, like, cryptographic key to charge, you know, with money and show QR code. Like, I mean, these things are still not, not, not existing. I mean, the ecosystem is, like, super, super early. So, I have local wallet with $10. Then I call, like, uh, the agi.apify.com, uh, allocate, like, token with $1. I get back, uh, 402 payment required. So, there is, like, this, like, super long, like, payment required signature. Uh, I use Apify, uh, I use our MCPC, which is, like, MCPC, like client, to sign, uh, the payment. And then I can send the, oh, oh, oh, oh. This demo didn't work as expected. Uh, here we go. Hmm. Well, anyway, uh, I have one minute left. Demo will come later. Sorry about that. So, to conclude my presentation, like, really, like, try it out and, like, try to build, try to use it. Like, actually, I tried to use it for the first time, like, a couple of weeks ago. Because I always thought, oh, my God, it's somehow complicated, you know. There is a lot of this, like, weird crypto lingo, you know. Like, I, like, I don't know what it, what it means. But actually, it's really, really simple to, to play with that. You can, you know, get, get up and running in, like, ten minutes. And, uh, it's still super early. Uh, I think there's, like, $1 million transaction volume, like, per month. Like, this is nothing, right? Like, the economy is much, much bigger. But I think it will soon ramp up. And I think once, uh, really this, like, era of, like, uh, token subsidies will end, I mean, when, when you really will have to pay for the tokens, you know, that your agents consume, I think suddenly this decision whether to build or buy will, you know, make more economic sense, actually, to buy external, you know, services for those things rather than build from scratch. And I think at this time, really, the agent payments will explode. And, uh, very soon, uh, uh, the agent e-commerce might, uh, overtake the normal commerce. Thanks a lot for your attention. And please come, uh, to join us, uh, in our booth. And actually, I have another talk coming up in two hours, uh, about MCP and CLI. So, you can check this one as well in Expo Stage 2. Thank you. Thank you. Thank you.