the status code
plans & keys
HTTP 402 sat unused for decades — 'Payment Required' with no standard way to pay.
x402 integration + a2a
x402 gives 402 a usable meaning: price the request, pay, and proceed in-band.
pay-per-call, explained
x402 for agent builders: payment before execution.
x402 revives the dormant HTTP 402 'Payment Required' status code so a server can price a request and a client can pay to proceed. That in-band handshake is an external integration for a2a today. Behind it, a2a can run the agent call, return signed execution evidence, and record native per-call economics separately after the run.
external payment rail · signed execution · separate ledger
0
status code, revived
0%
signed per paid call
0
signup forms for an agent
the problem
Agents can't sign up for a plan. They need to pay per call.
The web's payment model was built for humans: create an account, enter a card, buy a subscription. An agent making a single metered request can't do any of that. HTTP 402 was reserved for exactly this — 'Payment Required' — but sat unused for decades with no standard way to actually pay. x402 gives 402 a usable meaning, and that's the flow agents have been missing.
Monthly plans and signup forms assume a human onboarding, not an agent making one call.
Invocation authority and payment authority are different controls.
A charge on a statement is disconnected from the specific request it paid for.
Without per-call settlement, agent-to-agent commerce needs a human to provision access first.
the a2a way
Put x402 payment before a2a execution.
Use an external x402 adapter for the HTTP challenge, payment verification, and spend policy. Once authorized, a2a runs the call under scoped authority and signs the covered execution. Direct gateway responses include evidence; Agent API evidence is persisted with separate receipt-linked economics.
x402 is an external payment railThe receipt proves executionIdentity and authority on the callerMetering the runtime already doesOne tool, many calling surfacesSeparate invocation scope from spend policy
x402 is an external payment rail
x402 revives HTTP 402 Payment Required so a server can price a request and a client can pay to proceed. a2a has native Agent API per-call pricing with a known-credit preflight and receipt-linked debits, but does not implement the x402 challenge-and-payment handshake.
The receipt proves execution
For an authenticated Agent API paid call, the control plane signs and persists caller, skill, input evidence, the grants that authorized it, outcome or result preview, and timing. Its economics live in a separate receipt-linked row; direct gateway receipts record zero platform economics.
Identity and authority on the caller
An a2a caller can present short-lived signed authority bound to identity, audience, TTL, and scope. Spendable balance is not encoded in that grant; the authenticated Agent API performs a separate known-credit check before paid work, while direct gateway routes do not create platform economics.
Metering the runtime already does
The runtime records execution timing in the signed receipt, then the control plane stores compute, markup, fee, and payout fields beside the verified run. Per-call payment uses that ledger record without implying the economics were signed by the agent runtime.
One tool, many calling surfaces
The same hosted agent can be reached over MCP, the REST/OpenAPI gateway, and A2A. An application can put an x402-compatible payment adapter in front, while a2a continues to sign execution facts and maintain its own per-call ledger.
Separate invocation scope from spend policy
Scoped grants bound what a caller may invoke, with an audience and a TTL. They do not carry a spending cap. Enforce autonomous spend limits in the external payment or entitlement layer before the request reaches the runtime.
side-by-side
The old payment model vs. x402-style pay-per-call.
granularity
plans & keys
Monthly plans and API keys, sized for humans signing up, not agents making one call.
x402 integration + a2a
Per-call settlement sized for how agents actually consume — bursty and metered.
onboarding
plans & keys
An agent can't fill in a signup form or a credit-card checkout to buy one request.
x402 integration + a2a
An x402-compatible client handles the in-band challenge and payment for the request.
proof
plans & keys
A charge on a statement, disconnected from the specific request it paid for.
x402 integration + a2a
A verified receipt ID links the call record to a separate settlement ledger entry.
control
plans & keys
A shared key grants broad, ambient invocation authority.
x402 integration + a2a
a2a grants scope delegation; Agent API checks native credit, while x402 can add in-band payment proof.
dimension
plans & keys
x402 integration + a2a
the status code
HTTP 402 sat unused for decades — 'Payment Required' with no standard way to pay.
x402 gives 402 a usable meaning: price the request, pay, and proceed in-band.
granularity
Monthly plans and API keys, sized for humans signing up, not agents making one call.
Per-call settlement sized for how agents actually consume — bursty and metered.
onboarding
An agent can't fill in a signup form or a credit-card checkout to buy one request.
An x402-compatible client handles the in-band challenge and payment for the request.
proof
A charge on a statement, disconnected from the specific request it paid for.
A verified receipt ID links the call record to a separate settlement ledger entry.
control
A shared key grants broad, ambient invocation authority.
a2a grants scope delegation; Agent API checks native credit, while x402 can add in-band payment proof.
questions
Frequently asked.
What is x402?
x402 is an approach to internet-native payments that revives the long-dormant HTTP 402 'Payment Required' status code. It lets a server respond to a request by asking for payment, and a client pay to proceed — an in-band, pay-per-call flow. It's aimed squarely at machine clients like AI agents that need to buy a single request rather than sign up for a plan.
Why does x402 matter for AI agents?
Agents consume services in short, bursty, metered ways and can't fill in signup forms or credit-card checkouts. Pay-per-call over HTTP fits that behavior: the agent pays for exactly the request it makes, when it makes it. That unlocks agents transacting with services and with each other without a human provisioning access first.
How does a2a relate to x402?
a2a cloud supports native per-call pricing through price_per_call_usd, but it does not implement x402's HTTP challenge-and-payment exchange. An external x402 adapter can verify payment before forwarding a call. The covered a2a execution is then signed: direct gateway responses include evidence, while Agent API evidence is persisted with separate receipt-linked economics.
What proof do I get that a paid call happened?
For an authenticated Agent API paid call, the control plane signs and persists caller, skill, input evidence, the grants that authorized it, outcome or result preview, and timing. The charge is separate and linked by receipt ID; public `/invoke` and standard MCP receipts carry zero platform economics.
Can a2a scoped grants cap how much an agent spends?
No. Scoped grants constrain audience, lifetime, files, and tools; they do not encode a spend cap. The authenticated Agent API separately checks known native credit before a paid call, then debits after success. An external x402 layer can add cryptographic in-band payment or a separate allowance policy, especially for direct gateway access that records zero platform economics.
keep reading
Related guides.
All guides live in the guides index.
don't trust the agent
Pay first. Then sign what ran.
Use an external x402-compatible layer to verify payment before forwarding the request. a2a cloud then runs the agent under scoped authority and signs execution evidence. Native Agent API price_per_call_usd economics are stored separately and keyed to the receipt ID rather than represented as signed payment proof.