x402 Payments for AI Agents: USDC Access to Allocation Analysis
A practical guide to x402 HTTP payments, USDC on Base, payer wallets, idempotent retries, and paid API access for AI agents.
Published Jul 6, 2026 . Stakao . 7 min read
Direct answer
x402 is a protocol pattern for paid HTTP resources. A server can return HTTP 402 Payment Required with machine-readable payment requirements; an agent or client pays the requirement and retries the same request with proof of payment.
Why x402 fits agent payments better than a normal checkout page
A human can click Stripe Checkout. An autonomous agent needs an HTTP-native payment loop it can complete from a wallet without using a browser session.
For Stakao, x402 is used only on the paid allocation analysis endpoint. The catalog, OpenAPI, MCP tools, skills, auth documentation, pricing file, and public search remain free so agents can evaluate the service before payment.
This keeps the commerce boundary precise: the agent pays only when it wants the backend to create a real analysis record.
The Stakao x402 payment flow
The agent pays before the backend performs the allocation analysis work, but after it has enough public information to understand the paid API call.
- The agent reads the catalog and validates that the selected catalog_item_id exists.
- The agent calls free preflight to validate the wallet and receive a Stakao-generated request id.
- The agent posts the paid allocation request with that request id and receives HTTP 402 payment requirements.
- The payer wallet pays the 3 USDC requirement on Base.
- The agent retries the exact same request with x402 payment proof.
- Cloudflare validates the payment, signs an internal header, and forwards to FastAPI.
- FastAPI stores the paid request and returns an informational agent_decisions record.
Payment needs idempotence, not double computation
Agents retry. Networks fail. A paid API must treat repeated requests predictably or users will be charged for confusion.
| Retry case | Expected behavior |
|---|---|
| Same Stakao-generated client_request_id and same request body | Return the same decision without creating a duplicate paid calculation. |
| Same Stakao-generated client_request_id and different request body | Return 409 because the server-issued request id now conflicts with a different request hash. |
| Payment valid but backend reference allocation stale | Return an explicit stale-data error rather than inventing a slow live result. |
Why Stakao starts with USDC on Base before TAO payments
USDC on Base is the lowest-friction V1 rail for agent commerce. TAO-native payments can come later without blocking the product validation.
The public Stakao agent endpoint uses Base USDC at 3 USDC per paid allocation analysis. TAO or alpha-token payments are a V2 consideration because they need additional liquidity, settlement, and accounting decisions.
FAQ
Does the agent pay before knowing the exact output?
Yes, but only after it has read the free catalog, OpenAPI, pricing, and safety documentation. The paid unit is one allocation analysis attempt for a valid request.
What token does Stakao accept for agent payments?
V1 accepts USDC through x402 on Base. The public paid allocation analysis price is 3 USDC.
Can a failed retry double-charge the agent?
The backend uses a Stakao-generated client_request_id plus request hash idempotence. Identical retries return the same result; conflicting retries return 409.
Related pages
Agent entrypoints
These endpoints are public discovery surfaces. Paid allocation creation remains gated by x402 USDC and returns informational allocation analysis output.