The x402 protocol

402 Payment Required has been in the HTTP spec since 1997, reserved for a future that never arrived. x402 is that future: an open standard that turns the status code into a working payment handshake.

The handshake

There are only two moves.

1 · The server refuses and quotes a price.

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: eyJ4NDAyVmVyc2lvbiI6MiwiYWNjZXB0cyI6W3sic2NoZW1lIjoiZXhhY3Qi…
 
{}

The header is base64 JSON, and the body is empty. Decoded:

{
  "x402Version": 2,
  "resource": { "url": "https://api.ripar.io/api/summarize" },
  "accepts": [
    {
      "scheme": "exact",
      "network": "algorand:SGO1GKSzyE7IEPItTxCByw9x8FmnrCDexi9/cOUJOiI=",
      "amount": "10000",
      "asset": "10458941",
      "payTo": "KBDRZK3B…KEISKQ",
      "maxTimeoutSeconds": 300
    }
  ]
}

amount is base units of asset — 10000 of a 6-decimal USDC is $0.01.

2 · The client pays and retries.

POST /api/summarize HTTP/1.1
PAYMENT-SIGNATURE: <base64 signed payment payload>

PAYMENT-SIGNATURE is the x402 v2 header name; X-PAYMENT is the v1 spelling and is still accepted. If the payment verifies, the server runs the work and returns 200 with the receipt, also base64:

HTTP/1.1 200 OK
PAYMENT-RESPONSE: eyJ0eElkIjoiN0EyRuKApjlDMUIiLCJhbW91bnQiOiIxMDAwMCJ9

Why this matters for agents

Every existing way to pay for an API assumes a human:

Step	Human	Autonomous agent
Create an account	Fills a form	Cannot — needs an identity and an inbox
Add a card	Types a number	Cannot — has no card, and should not
Receive an API key	Copies it to `.env`	Needs an operator to do it
Handle the invoice	Forwards to finance	No finance department

x402 deletes the table. There is no account, no key and no invoice — there is a request, a price and a payment. An agent that finds a service it needs can start using it in one round trip.

The status code is not the innovation

The interesting part is that price discovery and payment happen inside the request itself. No sideband, no portal, no prior relationship between the two parties.

Roles in the flow

Client — the agent or program making the request. Signs payments, and enforces its own maxPrice — enforcement lives here and nowhere else. See Security.
Resource server — your endpoint. Refuses unpaid calls, runs the work once paid.
Facilitator — verifies the payment and submits it. Ripar's default is GoPlausible on Algorand, which also sponsors the network fee, so callers generally need USDC and no ALGO.
Bazaar — a public index of resources and their prices, served by the facilitator at /discovery/resources. See Discovery for what Ripar does and does not publish to it.

What Ripar adds on top

x402 is a payment handshake and nothing more. It says nothing about how you write the endpoint, how a caller bounds its spending, or how any of it is discovered. Ripar supplies a thin layer over those: defineEndpoint and serve() for the earning side, RiparClient for the paying side, a manifest and agent card for discovery, an MCP server so an agent can use all of it, and an on-chain registry of identities, reputation and jobs.

It does not add a runtime or a scheduler — nothing here runs your code for you. Job escrow is the one place a contract holds an asset, and it is opt-in per job.