About this talk
This talk, presented by Kevin Lewis, a developer advocate at Apify, explores the challenges and solutions related to automated payments for agents on the web. He emphasizes that while data is readily available online, obtaining it in a reliable and scalable manner can pose significant hurdles. The speaker introduces HTTP 402, a status code designated for payment requirements that has largely gone unused until now. He discusses the potential of this status code, particularly through the implementation of X402, which allows agents to make payments without the need for credit cards or human intervention. Key concepts include the use of USDC, a fiat-backed stablecoin, as a programmable currency, and the mechanisms through which agents can transact seamlessly in real time. The session further outlines best practices for agents to manage spending and interact with APIs in the Apify ecosystem.
Full transcript
Hello everyone. Am I beaming straight into your skull? Amazing. That This is super super wild to be talking in this silent disco setup. Uh hello everyone. My name's Kevin Lewis. Hello. I'm a developer advocate at Apify. We are a platform and marketplace for web automation and web scraping. The data you want is already on the web, right? You can navigate to it, you can see it, click
it, scroll it. But, getting that data reliably into your pipeline at scale over a long period of time is the gap that Apify fills. So, we are a marketplace for what we call actors. These are small serverless programs that do a thing on the web for you, your apps, your agents. Tens of thousands of these actors exist in the store built by us and maintained by us
and our community of creators. And what this means is I spend a lot of time thinking about what happens when agents need to pay for things. So, by the end of this talk, you will know how an agent can pay for things over HTTP without a credit card, without a subscription, and without a human present. And how to pay for content and implement the standard we'll talk
about yourself. So, HTTP 402. This is a status code for payment required, and it has been reserved in the spec since 1997. And for 28 years, it did absolutely nothing. And that's because the machines that needed it didn't exist yet. But, they do now. HTTP 402, I'm going to have to get good at saying that very quickly over and over again in this talk, was waiting for
agents. So, the internet has protocols for everything, right? HTTP for how servers and clients talk, SMTP for email, RTP for real-time video and audio, FTP for file transfer. But, for money, there isn't a standard. Cuz money moves around the internet, sure, but it's not native to the internet. It's kind of bolted on. And to understand why this matters, we need to talk about money and the archaic
systems that move it around. How fun. So, the US Central Bank, the Federal Reserve, is the most powerful financial institution in the world. And the chairman was once asked directly, "What is the architecture of a dollar?" "What is the backbone of the entire global financial system?" And you're going to absolutely love this. It's super, super cutting-edge. That is a Sun Microsystems. That is a set of Sun
Microsystems mini computers. The Fed runs Oracle databases on these exact machines. The server room is the backbone of the world's reserve currency. It's not a real-time network. It's not a blockchain. It's not anything fancy. It's Oracle on Sun boxes from the '90s. But what are the actual mechanisms that move money around in this system? ACH, the Automated Clearing House, is how most bank transfers work in the
US. Transactions pile up during the day, and then they're processed in batch overnight. They settle 1 to 3 business days later. SEPA here in Europe are faster, typically 1 day, but generally use the same the same overall system. SWIFT for international wires, again, the same, but it can take even longer. The entire global banking system is built on these overnight batch jobs. Now, wire transfers use what
is known as Fedwire in the US. It's a real-time gross settlement system. Each transaction is processed immediately, but you might think, like, "Okay, that's great. Why isn't everything a wire then?" And it's because it's really expensive to run. Really expensive to run. A single transaction could be 15 to 30 bucks worth of fees. So, it's not feasible to move around smaller amounts of money smaller amounts of
money. So, this is the trap, right? You either get cheap, but slow, or you get fast, but expensive. And neither works for machines that need to process money 24/7 in milliseconds. Card payments I also want to mention here. So, things like Visa and and American Express and MasterCard, they use a messaging system called ISO 8583, which dates back to 1978. Every swipe or tap generates a code
in this standard and then routed through the card network. Now, cards are actually, interestingly, a hybrid. There's a real-time authorization that is approved in seconds, like FedWire, but there's a batch settlement that still runs overnight like ACH. So, the card network takes a large percentage, like a 2 to 4% charge in interchange fees, and this is why cards are fast at the register, but the vendor, the
person you're paying, still doesn't get the money for 2 to 4 days afterwards. And Stripe and PayPal built wonderful, beautiful APIs on top of this, but it's still on top of that 1970s plumbing. They handle things like PCI compliance, fraud detection, but it's the same rails. Stripe checkout takes 2 to 3 days for funds to actually hit your account because underneath it is still that same set
of standards. You might think to yourself when I send money using a PayPal account, it just takes seconds. So, how does how does that work? And that's because it's not moving on the money rails at all, right? That's using an internal ledger. They just debit from one account and add it to the other. But the moment money needs to leave that system, when you're like withdrawing to
a bank account, there's still that same wait. The moment it touches those same rails. And all of these were designed for humans, right? With sign-up forms, with KYC, know your customer, the kind of identity verification step, and approval flows. And agents just can't go through all of that. And to be fair, agents can, like very very functionally, they can do this. You know, they can fill out
forms, run headless browsers, you can script it, but the truth is they shouldn't have to. Forms assume visual cognition. They rely on CAPTCHAs, email verifications, 2FA codes, persistent session states, and increasingly platforms are becoming hostile to automated bots on sensitive actions like purchases and transactions and moving money around. To make uh making an agent operate a form is like making a human read raw TCP packets to
browse the web. It's that kind of wrong level of abstraction to think about. And what we really need uh and what HTTP was designed for is a protocol, a status code, some metadata, a signed payload. That is HTTP 402 in a nutshell. Now, just before we get into it, every paid service, every paid API today really there is a prerequisite that there's a human somewhere in that
system. There's an account that needs to be created. There's KYC identity verification and purchasing credits or a subscription, if not immediately then very soon after sign up. An agent can't or shouldn't be creating its own account. It can't upload a passport for know your customer customer verifications. It can't sign a subscription agreement. These are the bottlenecks that the protocol starts to eliminate. So, X402 is the first
really widespread implementation of this 28-year-old status code. It enables internet-native payments built into HTTP itself. It was originally built by Coinbase and then was donated to the X402 Foundation, which is part of the Linux Foundation. And the flow here is a bit more simple. The agent sends a request. It gets an HTTP 402 code back with some metadata, and then the agent pays and shows proof that
it has paid, and then the the action takes place. There's no account required here, no identity verification, and no API key. But what are these agents actually going to pay with, right? Cuz I sure as heck ain't giving it my credit card. I'm not giving it access to my bank account. Absolutely no chance at all. So, we've already covered the fact that existing payment infrastructure does not
really have the characteristics that an autonomous agent needs. What they need is for money to be programmable. So, USDC or USD Coin is what is known as a fiat-backed stablecoin, meaning that every USDC has $1 in cash equivalent held in its reserve and then audited by one of the big accounting firms. It's not a cryptocurrency in a speculative sense. It is a dollar that is digitized with
a dollar sitting somewhere in a very well-protected vault probably uh probably, right? It and by putting it on a blockchain it inherits uh um it uh inherits internet-native qualities like being programmable, being borderless, settling in seconds, being available 24/7 365. I forgot to mention earlier by the way, Fedwire only works during business hours. If you want to run wire transfers and you're out of business hours, you're
tough out of luck. So, we are going to be using USDC in order to allow our agents to pay. You give your agent a dedicated wallet, ideally a dedicated wallet with a USDC balance. Um and then you try and access a resource. The server responds with 402 payment required with some structured metadata. Something called a scheme, which we'll talk about in a moment. Here, the exact uh
the exact scheme, which means there is a fixed price attached to that uh that resource. The network that the transaction is running on, you can run it on Base, which is Coinbase's network or Arbitrum or any EVM-compatible chain. The asset, which is USDC here, and the amount. Don't be alarmed that this is like a million. It runs on a six-point decimal system, so a million here is
is $1 worth of USDC. And you can really add the pay the payee address, right, and the timeout with which to make that transaction. And you can think of it like a coin a coin slot in a URL. Here's the price, here's what you pay, drop your coin in, and it will unlock the goodies. So, let's talk about the actual mechanism at play here, cuz it's fairly
simple, but there are more steps than you might realize. So, we'll work through it here. So, the client, which could be your HTTP client like Postman, for example, your application, or an agent, I'll refer to an agent from here on out, but it's not agent specific, makes a request. The server responds with a 402 with that structured metadata, right? What you need to pay, where you need
to pay, and how long you have to pay. The agent then reads that price and evaluates whether to pay. You can just bail here, right? The timeout elapses and and you just leave it where it is. But, let's say it's ready to go ahead and pay. It signs what is called an EIP-3099 transfer with authorization. Rolls right off the tongue. They need to do a little bit
of branding work on that, I think. Um, this happens entirely off-chain. This is nothing to do with blockchain still. This is just a cryptographic signature that says, "Yes, I authorize this much USDC to be sent to this address." The agent then sends that signed authorization directly to this third party, a facilitator, which in this case is run by Coinbase, but it doesn't have to be. Uh, and
the facilitator then submits that transaction on-chain using a blockchain, and the USDC moves from the client's wallet to uh to the server's wallet. And then the facilitator provides a proof Um, yeah, provides a proof that yes, you did pay, the money did move, and then you retry that request that initially returned the 402 with the with the payment stub, with the receipt, the proof that you actually
moved the money, and then you are responded to with the data that you initially asked for. And while this might seem like a lot of steps, it is worth noting that, you know, there are uh abstractions to this that make the developer experience a lot nicer, which we'll talk about in just a Now, it might feel scary letting your agent spend real money, and that is a
really fair concern. There are a few safeguards commonly accepted as best practice in enabling your agent to say no once it has that initial 402 response with the payment metadata. The first >> [clears throat] >> is a budget cap, right? You You say it could be per session or for a time frame or for or per server. Say the limit's five bucks. You spent 490, the the
request needs 50 cents. It just says, "Nope, that's it. I've hit my limit. I have to say no here." The next is some kind of price to value gating. The agent can evaluate the utility before signing. Is a weather request worth 1 cent? Possibly. Is it worth five bucks? Almost certainly not. And then it decides, "Actually, no. I don't think this is worth it for the cost
of the action." We also have this concept of server scrutiny. Known and trusted servers get lower friction. Um a new server on an unrecognized payment address might get extra scrutiny. Uh it could be around that value gating. Is this quite a high cost for what I'm expecting to pay? Well, now I'm going to apply some extra scrutiny to this transaction. And finally is a circuit breaker. A
payment goes through and a fulfillment never arrives. Well, a circuit breaker says, "Okay, let's stop sending money to this server cuz we're not getting what it was we expected." Another couple of of good practices here is equip your agent, as I said, with its own dedicated wallet um with a low amount of funds, not your life savings, please. Um and applying these uh starts to look into
how to apply these kind of confidently, you might want to look into a mix of deterministic and non-deterministic workflows to uh only strictly allow your agent to do certain things based on scripts that you know the outcome of. Now, some workflows have unpredictable costs. So, the best example here is what we do at Apify, right? Web scraping. An agent hits an Apify actor, but you don't know
how many results are going to come back. And perhaps you're paying for a certain number, you know, based on the number of results that come back. Um Apify's paper event pricing could mean that the final cost is is unknown up front. So, the way this uh initially worked in the standard is you put up a deposit, something that's high enough to uh combat a use, but low
enough uh but low enough uh to be safe. The server then tracks the real usage off-chain. Uh there is no on-chain transactions here, just a counter. And then unused balance is refunded after 60 minutes. So, this is what ships today in a lot of clients. Uh recently into the spec, and the natural evolution of that is what is known as the up-to scheme. So, there was the
exact scheme, and this is the up-to scheme, where you set a maximum price, and the agent authorizes up to that ceiling. The server tracks the usage off-chain and settles only what was consumed. So, there's no refund step, no 60-minute wait, no unnecessary on-chain transactions for the unused portion. Uh so, yeah. So, the these are these are two schemes. There's more schemes that are being developed as well.
Uh and a lot of clients are yet to implement this up-to scheme as it's still very, very new. but, we'll do soon. I wanted to share it with you regardless. So, that's the mechanism. I wanted to take a few moments to show you what this actually looks like. And I'm going to do this with MCPC. This is a CLI-based uh MCP client built by Apify. It's open
source. And as far as we're aware, this is the first MCP client, which is a CLI that supports X402. So, I'm going to switch over to the terminal, and we'll take a look at this. So, the first step here is to check the wallet. I've already configured this ahead of time and put some funds in a wallet. We see here there's like six bucks worth of worth
of funds in this in this wallet. This is what we call a hot wallet, right? Low balance, purpose-built for agent payments. the next thing we'll do is connect to the Apify server. So, we'll go ahead here and use MCPC connect. We'll provide the URL and we'll call this session Apify and flag that we want to use X402 and it's created a new session for us. There was
no API key here, there was no other authorization, there was no account creation, no identity verification. There's just a wallet and a signature and I've connected to the MCP server and enabled X402 as our as our payment mechanism. Now, we're going to call our first tool. This is just a search actors tool. We see it here and we're going to search for Instagram actors. So, Instagram scrapers.
And the agent's going to query here and we see that there's a few here and the one I'm interested in is this one here, the the main Apify Instagram scraper. We see that here, it's called apify/instagram-scraper. Just to be clear, these are read operations, there's no payment required for these. That's only when we're actually going to go ahead and use use the actors. The agent can browse,
it can compare prices, it can decide which actor to invoke, right? Without spending a cent. So, now we're going to dig into this actor a little bit more by calling fetch actor details, Apify Instagram scraper, and we let's wait for it to come back. This is a whole bunch of metadata around this actor, what it does, the input schema, what we need to provide it when we
run it, the pricing point. And just as a note here, X402 running on Apify uses this, the bronze pricing, just to be aware. So, that's how much we're expecting to pay here. This is where an agent would evaluate whether an actor is actually worth invoking a tool right the price to value gating this it could be implemented right here. So we're going to now use our our
last command here. We're going to run another MCP tool here from the server called cool actor. We're going to run this into this Instagram scraper. We're going to pass in a username and we're just going to get three back so it's nice and quick here. And this is where that 402 loop is going to run under the hood. The agent sends the request the server responds with
agent required. The structured metadata including the amount the payee address the timeout. MCP will read the 402 signs the authorization submits it through the facilitator. It's settled on chain. The server confirms payment. The actor starts running. The agent [snorts] gets all of its data in just seconds and while here I'm running commands manually these MCP tools can absolutely be run you know by by an agent that's
choosing which tools to run on the fly. So that's kind of the core loop here. And then just to show you we're going to run the wallet info again and we see here Here we Here it is. It's a dollar less right because this is the exact scheme so we put up a dollar. We took we made the transaction and in an hour I'll get back what
wasn't used. We are currently implementing the opt-out scheme as well in this CLI. So $1 buys around just to kind of give you the economy of scale here just to just so you kind of have a mental model here. This is rough but like $1 buys around 400 Instagram profiles 250 Google Maps places with names addresses ratings hours stuff like that or 650 e-commerce e-commerce products worth
of data at the time of scraping. We grab those live. And then the agent can make an HTTP request to do this. That's the other thing and that's important to know. It doesn't have to be over MCP. This is just a set of HTTP requests. But there is an MCP interface for it as well. Now, I wanted to just briefly talk about what it takes to implement
X402. There are There's already like SDKs in a bunch of different technologies and frameworks and stacks. This is for an Express Node application. So, firstly, you import the packages that you need. You set up the facilitator and the server, so you configure that and which and which chain you're going to use. Again, any that use EVM, the Ethereum virtual machine, all good. And then you configure the
middleware. You define your endpoint, the price, and where the payments are sent. And what's really nice about this is if you build on Apify, you don't even need this middleware. All of the actors that are built on Apify are accessible via the the web UI that any developer can use. No, any Anyone can use, whether they're a developer or not, via the API, the client libraries, via
MCP, and they all support X402 out of the box. You don't need to do anything, and you receive payments for the running of your actors like usual. So, you've seen X402 in action, but it's not the only approach, and it's not the only part of this agentic commerce kind of landscape. So, I wanted to take just a few moments to talk about the the broader ecosystem and
how all of these parts act together. So, firstly, there's commerce, which I would call the the top of the stack. So, ACP, the agentic commerce protocol, built by Stripe and Open AI, and it's live today. You can use it inside of ChatGPT, and it defines a programmatic checkout flow, discovering products, Cool. Discovering Discovering products, rendering a checkout UI, collecting buyer selections, uh and then getting the payment
credentials back to the seller's existing payment processor. So, this is available today. Next is authorization. AP2 uh is uh I believe it was built by Google. Uh this is a an authorization spec that uses verifiable uh digital credentials through a set of mandates. It has modes for both human present and human not present workflows. Uh and this is payment mechanism agnostic. So, whether you're using something like
X402 payment is irrelevant. This is just who authorizes agent to act. It's not identity, it's not payment, it's just proof of permission. Uh if you want more detail on this, wait for talks for this conference to come out and there was a really good one yesterday by Ben Greenberg that covers AP2 in a little more detail. And finally, there's settlement, the actual money moving layer, which is
what this talk has mostly been about. We've been speaking about X402, which is quite a simple standard. Uh it's just a a signature and a facilitator. Now, NPP, the machine payments protocol, uh this was launched by Stripe and Tempo in March. I was about to say last month, but time progresses faster than I thought. In March, um and this supports more payment mechanisms, but is a little
bit more complex to implement because it has more capabilities. And then I also wanted to mention here L402, which really was the original that proved that 402 response and a signed uh auth in the response was the right path. Uh but this required too much of developers to implement, and it's really why X402 went out on developer experience. So, these are the three layers. I also wanted
to just briefly mention that Visa is also building something the intelligent card, um which both holds value and authorizes on behalf of an agent. So, it's the two layers, it's both authorization and settlement on one device on one standard. They've just announced that it doesn't exist in the real world quite yet. So, as we wrap up, I just wanted to to kind of That was That was
a lot. Please do feel free to come and talk to me on the Apify booth. I'll be here all day if you have any questions or want more information. But, we covered how an agent actually pays without a credit card, without a subscription, and without a human in the loop. How stable coins make that possible by putting a dollar on the internet that settles in seconds. Where
this fits in the in the landscape. We spoke about commerce and authorization as well as settlement as three distinct layers that work together in this story of allowing agents to discover, authorize, and buy things. We briefly spoke about how to accept it. Just some light middleware, and then you're you're off to the races. Or, you can build an Apify and it's built in natively if you create
actors. We spoke briefly about what it costs because I think it's useful to have a frame of reference for, you know, what these products actually are going to cost you at the end of the day. And finally, as a closing thought, going back to the very beginning of this talk, HTTP 402 was reserved 28 years ago and sat there doing absolutely nothing didn't exist yet. They do
now, and HTTP 402 is ready to use with things like X402 in order to enable your applications anonymously, or your users anonymously, and your agents to transact on your behalf. If you want to learn more about bringing real-time data to your agents and your applications, you can go to mcp.apify.com. Get access to over 20,000 real-time data sources. Um, or come find us, as I said, on booth
33. Um, there's my website there if you want to keep in touch. Thank you so much for entrusting me with your time today. Uh, have a good rest of your conference. If you have questions throughout the rest of the uh throughout the rest of the conference, if they come to you, by all means, we're we're just over there. I'll I'll be there. Thanks.
