x402 payment integration
x402 turns HTTP status 402 into a working payment flow: agents pay per request in USDC - we implemented it end to end in Azeth, live on two testnets.
The problem
Agents are becoming buyers - of API calls, compute, data, and other agents' work. Card checkouts assume a human with a browser; API-key billing assumes a signed contract and a finance department. Neither survives contact with software that wants to buy one request from a service it discovered thirty seconds ago.
x402 is the smallest fix that works: the price is in the HTTP response, the payment is a stablecoin transfer, the receipt is cryptographic. We did not read about this in a spec - we built it into Azeth's service layer, where paying for a call is also what makes your rating of that call count.
Engagement
Two directions, same protocol: making your service charge machine clients, or making your agents able to pay. Either way the build is fixed-scope - endpoint gating or client flows, settlement wiring, and tests against public testnets first. You get working code, the operational runbook, and an explicit list of what must be true before mainnet.
Start by email: what to include is on the contact page.
What we ship
- Payment-gated API endpoints: 402 challenge, verification, and settlement flow
- Client-side payment handling for your agents and SDKs
- USDC settlement wiring and receipt verification on-chain
- Pricing catalogs per endpoint or per capability
- Testnet-first rollout with a documented path to mainnet
Proof
- Azeth: trust infrastructure shipped to two testnetsCase study
- AzethPortfolio entry · testnet alpha
Common questions
What is x402?
An open pattern that revives HTTP status 402 ('Payment Required'): a service answers a request with a priced challenge, the client pays in USDC, retries with proof of payment, and gets the response. No accounts, no invoices, no card forms - which is exactly what autonomous machine clients need.
Why not API keys and monthly invoices?
Keys and invoices assume a human signed a contract beforehand. Machine-to-machine commerce needs the opposite: pay-per-request between parties that may never have met. x402 makes the payment part of the protocol, so an agent can buy exactly one API call, priced in cents, settled in USDC.
Is this production-ready?
The pattern is young and we say so plainly. Our implementation runs inside Azeth on Ethereum Sepolia and Base Sepolia - testnets, by design, with no external audits yet. For client work we build testnet-first and define the mainnet criteria together; nothing gets called live that is not.
Does it require its own token?
No. Settlement is in USDC, a dollar-denominated stablecoin. No token launch, no speculative asset - payments are boring here, deliberately.
How does x402 relate to ERC-8004?
They compose. x402 answers 'how does a machine pay?'; ERC-8004 answers 'who is this machine and what is its track record?'. In Azeth, payment receipts gate reputation - an agent's opinion counts when it actually paid for the service it is rating.
Industries
last edited 2026-07-02