Veyra

Concepts and protocols

What is the x402 protocol?

x402 uses the HTTP 402 status code so a server can ask for payment and an agent can pay in the same request. How it works and what it needs.

x402 is an open protocol for paying for HTTP resources in the request itself. The server replies 402 Payment Required with its payment terms, the client retries with a signed payment payload, and the server verifies and settles it, often through a facilitator, before returning the resource.

Why is this harder than it sounds?

HTTP has had a 402 Payment Required status since the 1990s, but RFC 9110 still lists it as reserved for future use; nothing standard said what a client should do with it. Paying for an API usually means an account, a subscription and a stored card, all of which need a person. x402 fills in the missing piece for machines: a defined way for a server to state a price and for a client, such as an agent, to pay it without signing up first.

How do you do it?

  1. The client asks for a resource. An ordinary HTTP request to a paid endpoint.
  2. The server answers 402. The response carries the payment terms, a base64-encoded PaymentRequired object, in the PAYMENT-REQUIRED header.
  3. The client builds a payment. It chooses an option whose scheme and network it supports and signs a PaymentPayload. On EVM chains the exact scheme defaults to an EIP-3009 transferWithAuthorization signature, with Permit2 and ERC-7710 as alternatives.
  4. The client retries with payment. The same request goes again with the payload in the PAYMENT-SIGNATURE header.
  5. The server verifies and settles. Locally or through a facilitator's /verify and /settle endpoints. The facilitator submits the payment and generally pays the gas, but cannot change the amount or destination.
  6. The server returns the resource. A 200 response with a PAYMENT-RESPONSE header describing the settlement.

What it does not mean

  • x402 is not a wallet or a spending policy. It defines how to pay a server, not whether a given agent should.
  • It isn't tied to one chain. The spec has schemes for EVM, Solana and others; each client and facilitator supports specific scheme and network pairs.
  • It doesn't remove the need for limits. An agent that can sign x402 payments can sign as many as its key allows.

Common questions

Who created x402?

It started at Coinbase; the reference repository says the project has moved to the x402-foundation organisation on GitHub.

Does Stripe support x402?

Stripe's machine payments docs list x402 for USDC on Base, alongside the Machine Payments Protocol.

What is the upto scheme?

Besides exact, which transfers a set amount, x402 describes an upto scheme that authorises a maximum per request and lets the seller settle actual usage up to it.

Where does Veyra fit?

Veyra does not implement x402 today. Its create_payment tool sends a USDC transfer on Base to an address you allow, and once confirmed, get_payment returns tx_ref, the on-chain transaction, plus a Basescan link the agent can show a seller as proof. A standard x402 server expects a signed payload in PAYMENT-SIGNATURE rather than a finished transaction, so Veyra can't answer an x402 challenge directly. What Veyra adds is the part x402 leaves out: limits, a recipient allowlist and approval for what an agent may pay.

Start free with a simulated walletRead the docs

Sources

Terms on this page

This page explains how agent payments and the related technology work. It is not financial, investment, legal or tax advice. Protocols and provider features change; check the linked official sources before relying on a detail.