TL;DR
Software is becoming a paying customer
AI agents now do real work. They research markets, write and test code, check freight rates and pull data from dozens of APIs to finish a single task. Sooner or later, an agent reaches a service that charges for access.
That is where things slow down. Most online payment flows assume a person is present to create an account, enter card details, store an API key or approve a monthly bill. Those flows work well for people. An agent acting on its own, mid-task, needs a way to pay in the same moment it asks for the data.
x402 is an open protocol built for exactly that. This piece explains what x402 is, how a payment moves from agent to API, where it is already useful, what a business needs to accept payments from software, and how Tazapay is making that easier.
What x402 is
x402 is an open standard that lets a client pay for a web resource inside the same HTTP request it uses to ask for it. The client can be an AI agent, a script or an app. The resource can be an API response, a dataset, a file or a unit of compute.
The name comes from HTTP status code 402. Every web request returns a status code: 200 means the request worked, 404 means the page was not found. Code 402, Payment Required, was reserved in the early days of the web for a payment system that never arrived, so it went largely unused for decades.
x402 gives that code a defined format. When a server returns 402, the response carries machine-readable payment terms: the amount, the accepted token, the network, the receiving address and a time limit. A server can list several options, and the client picks one it can pay. The client sends its payment in a request header, and the server confirms it in a response header, so no new endpoint, redirect or checkout page is needed, as described in Coinbase's x402 launch announcement.
Payments today run mainly on stablecoins such as USDC. The standard is designed to work across blockchain networks and to extend to other payment methods over time.
Coinbase introduced x402 in May 2025 as an open protocol. In July 2026, the Linux Foundation launched the x402 Foundation to govern it, with Coinbase contributing the protocol and 40 member organisations signing on, including Visa, Mastercard, Stripe, Google, AWS and Cloudflare. That matters for businesses evaluating it: x402 is now a vendor-neutral standard, not one company's product.
How an x402 payment works
Three parties take part in every x402 payment: the agent that wants the resource, the API server that sells it, and a facilitator that checks and settles the payment. Here is the sequence for an agent that needs a freight rate from a paid logistics API.
A little more detail on the key steps:
- The signed payment (step 3). The agent signs an authorisation that names the amount, the recipient, a validity window and a one-time number called a nonce. It uses a standard signing format (EIP-712 on EVM-compatible networks). Nothing is transferred at this point; it is a verifiable promise to pay.
- The retry (step 4). The signed payload travels in a request header (X-PAYMENT in the launch version of the spec), so the agent calls the same endpoint again rather than a separate payment page.
- The receipt (step 7). The server's response carries a header confirming the payment, so the agent has proof of what it paid for.
For the agent, paying becomes one extra round trip, not a separate checkout process. For the API provider, every request can be priced and paid individually, which suits pay per call models better than prepaid credits or monthly plans.
Why it can keep up with agents
An agent might call dozens of paid endpoints to finish one task. If every call had to wait for a payment to fully settle on a blockchain, the agent would spend more time waiting than working. x402 avoids this by separating two jobs that are usually bundled together: checking the payment and settling it.
Verification happens inside the request. The facilitator checks the signed payment against the server's terms. Every check works on the signed message itself, so none of them waits on the network. The nonce check is what stops replay: once a payment has been used, the same proof cannot pay for a second request.
Settlement follows, in the background. Once the payment passes, the server releases the data straight away, while the facilitator submits the transaction, pays the network fee and waits for confirmation. If a submission fails, recovering it is the facilitator's job, not the API's. Whoever runs the facilitator takes on the small risk between approval and final confirmation.
This split is what makes small, frequent payments practical. The cost of each payment comes down to the network fee, which is low on the networks x402 typically runs on. A request can be priced at a few cents, or less, and still make commercial sense.
Where x402 fits
The common thread is simple: one piece of software needs to pay another, at the moment it uses the service. The businesses best placed to sell to agents already price by usage, and their fastest-growing callers are automated.
- Data API providers. Financial, legal, scientific, weather and logistics data sold per query. A research agent hits a premium endpoint, pays for that one lookup and moves on.
- AI infrastructure providers. Compute, inference, embeddings, vector search and storage. In a multi-agent pipeline, each step can pay the next service it calls, without a shared billing account behind every agent.
- Developer tool vendors. Code analysis, testing and deployment services. A coding agent in a CI pipeline can buy a single scan or test run per use.
- Digital content platforms. Licensed images, video, audio and datasets. An AI content agent pays the rights holder per asset as it fetches each one.
- B2B marketplaces and procurement platforms. Freight quotes, customs data, compliance checks and service orders. An agent placing an order gets a payment rail that does not stop for a human to approve every transaction.
x402 does not replace cards, bank transfers or invoicing. Those stay the right tools for people and for most business-to-business payments. It adds a rail for a new kind of buyer, one that needs to pay in the middle of a request rather than at a checkout page.
What a business needs to accept agent payments
Adding x402 to an endpoint takes little code, since open-source middleware handles the 402 response itself. The harder part is everything behind the payment. A business that wants to sell to agents at scale needs answers to five questions.
- Where do the funds land? Stablecoin payments need a wallet or custody arrangement that is secure, monitored and owned by the business.
- Who verifies and settles? Someone has to run the facilitator role described above, including paying network fees and recovering the rare transaction that fails.
- How does the money reach the books? Thousands of small payments need to be matched to requests, reconciled and, for most businesses, converted into the currency they report in.
- Is it compliant? Receiving stablecoins brings licensing, KYB and anti-money laundering obligations that vary by market.
- Does it fit existing payment operations? Agent revenue should sit alongside card, bank transfer and invoice revenue, not in a separate system.
The protocol is still young, and its governance only became vendor-neutral in July 2026. That makes now a good time for API and data businesses to plan for agent payments, before their own customers start asking for it.
How Tazapay enables x402 payments
In simple terms: Tazapay acts as an x402 facilitator for its merchants. API and data businesses can charge AI agents per request and keep the money in stablecoins or pay it out in local currency, without building any blockchain setup themselves. The merchant keeps running its own API, and Tazapay never sees that traffic, only the payment details it needs to check and settle each payment.
Getting started takes three steps:
- Add the standard middleware. The merchant adds the open-source x402 middleware to its API and points it at the Tazapay facilitator (service.tazapay.com/v3/x402) with its existing Tazapay API key. There is no separate blockchain account, third-party SDK or reconciliation code to set up.
- Set a price per route. The merchant decides what each endpoint costs, either a fixed price per call or usage-based pricing up to a maximum the agent authorises. Agents pay in USDC on Base or Polygon PoS.
- Get paid as normal Collects. Funds land in the merchant's Tazapay USDC wallet and appear as normal Collects, then flow into balance, FX and payouts like any other incoming payment.
To the agent, the merchant's API is a standard x402 endpoint. To the merchant's finance team, agent revenue is one more set of Collects.
Settle in stablecoins or fiat
Agents pay in stablecoins, but the merchant does not have to hold them. With Tazapay, agent revenue lands in the merchant's USDC wallet, where it can stay in USDC or be converted and paid out in local currency through Tazapay's existing FX and payouts. A data provider that has never touched a blockchain can price its API per call and still get paid in the currency it reports in.
Tazapay runs the payment checks and on-chain settlement described earlier and covers the network fees, so the merchant never needs to hold gas tokens. Only KYB-approved merchants can receive x402 payments through Tazapay, and payers are screened before settlement.
What merchants get
- No blockchain infrastructure to build or run
- Settlement in stablecoins or in fiat, in local currency, as the merchant prefers
- Network fees and on-chain settlement handled by Tazapay
- Every payment recorded as a normal Collect, with no reconciliation code to write
- Compliance and KYB through a licensed provider
Because x402 runs on Tazapay's existing stablecoin payment infrastructure, agent revenue does not sit in a separate system. For businesses weighing how stablecoins fit their wider payment stack, our guide to stablecoin payments for global businesses covers the bigger picture.
Sources
- Coinbase Developer Platform, Introducing x402: a new standard for internet-native payments, 6 May 2025
- The Linux Foundation, Operational launch of the x402 Foundation, 14 July 2026
- x402 Foundation, x402 overview and FAQs, accessed November 2026
