Portal Agents
U.CASH Agents · AI payments

Pay-as-you-go machine commerce over HTTP 402.

Sell priced resources to AI agents over a single 402 challenge. Buyers pay direct to your wallet, any coin or gasless USDC on Base. The platform never holds funds.

Get an API key → npm i agents-u-cash
agents.u.cash · /r/{res_id}
$ GET /r/{res_id} HTTP/1.1 402 Payment Required WWW-Authenticate: x402 accepts: usdc_base 0.0001 $ pay --asset usdc_base · sign EIP-3009 relayed on-chain · settled non-custodial $ retry with X-PAYMENT proof HTTP/1.1 200 OK
x402 compatible exact / detect / redirect Gasless USDC on Base UCP discovery JS + Python SDKs MCP server
What it is

The payment layer for autonomous agents

U.CASH Agents is the HTTP-402 payment layer for AI agents: priced resources that answer 402 Payment Required with an accepts list, so any off-the-shelf x402 client pays without changes. Funds always move direct buyer to seller on-chain, strictly non-custodial. It is the interaction surface (API, SDK, MCP) for developers building autonomous agents, LLM tools, and machine-to-machine paywalls; settlement runs through the pay.u.cash door.

How it works

One signed message, settled on-chain

Create a priced resource

POST /v1/resources with an amount and your accepted assets. You get a res_id and a checkout_url on the pay.u.cash 402 door.

Agent hits the door

A request to /r/{res_id} returns HTTP 402 with WWW-Authenticate: x402 and an accepts list of schemes, assets, and amounts.

detect: pay any coin

Pay-and-detect on-chain across every supported coin. The platform matches the buyer's transfer to the exact amount and receive address it issued.

redirect: cards

The buyer is redirected to the agent's own Stripe-powered checkout, so fiat card payments settle to the same merchant account.

exact: sign the authorization

For gasless USDC on Base, the buyer signs an off-chain EIP-3009 transferWithAuthorization in their wallet. No gas, no token approval.

Relay on-chain

The seller's funded relayer submits the signed authorization to Base. It signs only the gas wrapper around a buyer-authored message it cannot alter.

Settle non-custodial

USDC moves direct buyer to seller. The platform detects the on-chain transfer and marks the resource settled. The fee is debited from seller credit; no held balance.

Retry with the receipt

The agent resends the original request with the X-PAYMENT proof header and receives HTTP 200 plus X-PAYMENT-RESPONSE.

System architecture

The U.CASH Agents stack

Agents is the interaction layer: API, SDKs, MCP, and the 402 door. Settlement runs through pay.u.cash, and funds always move direct buyer to seller.

Clients JS SDKnpm agents-u-cash Python SDKpip agents-u-cash MCP server79 tools, stdio REST / OpenAPI 3.1/openapi.json agents.u.cash - API + 402 door /r/{res_id} 402 doorHTTP 402 + accepts[] + paymentRequirements[] WWW-Authenticate: x402 - X-PAYMENT proof header /v1/resources - /v1/walletsprice a resource, set receive addresses UCP /checkout-sessions - /catalog.json - /.well-known/ucp Three payment rails, one door Detect pay + auto-detect on-chain ~40 coins + custom tokens exact vs dust amounts Redirect cards your own card processor checkout in browser Exact gasless USDC on Base EIP-3009 + funded relayer /v1/exact-verify -settle -relay pay.u.cash - settlement on-chain detectionreads the chain, matches exact amount + address HMAC webhook + ledgeridempotent, replayable; fee from prepaid credit On-chain: Buyer wallet -> Seller wallet (direct) non-custodial - the platform never touches the payment Guardrails: per-caller spend caps - OFAC sanctions screening - request expiry - rate limits
Three rails, one door

exact, detect, and redirect

One 402 challenge, three ways to pay. The buyer picks; the seller's wallet is the destination in every case.

exact
detect
redirect
Settles
Gasless EIP-3009 USDC
On-chain, BTC to XMR and beyond
Fiat card charge via Stripe
Buyer experience
Sign one message, pay no gas
Send the exact amount to a unique address
Card checkout in browser
Custody
Direct buyer to seller
Direct buyer to seller
Direct buyer to seller
Wire format
x402 X-PAYMENT header
accepts[] challenge
Redirect URL
EIP-3009 Base chainId 8453 Multi-coin Non-custodial
Capabilities

What U.CASH Agents can do

HTTP-402 native

Priced resources answer 402 Payment Required with WWW-Authenticate: x402, so any stock x402 client pays without code changes.

Three payment rails

exact (gasless USDC on Base), detect (pay-and-detect, every coin), and redirect (cards) share one door and one challenge format.

Strictly non-custodial

Funds move direct buyer to seller; the platform holds no balance and no user key. The chain is the proof.

Gasless exact rail

USDC on Base via EIP-3009 transferWithAuthorization: the buyer signs, a relayer submits, so the buyer pays no gas and sets no approval.

UCP agent discovery

/.well-known/ucp + /catalog.json expose your storefront as schema.org/Product JSON-LD, with checkout-sessions and orders for autonomous buyers.

JS + Python SDKs

Zero-dependency packages on npm and PyPI: signup, wallets, resources, payment requests, transactions, and full merchant power.

MCP server

A 79-tool stdio MCP server drops into Claude Desktop or any MCP client to create resources, manage wallets, and list settlements.

Per-caller spend caps

Set maxPerCaller by wallet or IP with a time window; over-cap buyers are refused before charge, server-side across all rails.

OFAC address screening

Receive addresses are screened against the sanctions blocklist at signup and wallet set, keeping barred wallets off the rail.

How it fits in U.CASH

Agents and the rest of the network

Agents is the machine-payment surface; settlement and identity run through the U.CASH rails underneath.

Agent / clientU.CASH door
GET /r/{res_id} →
X-PAYMENT (signed) →
402door
← HTTP 402 · accepts[]
← HTTP 200 · settled
FAQ

Questions, answered

Is U.CASH Agents custodial?
No. Funds always move direct buyer to seller on-chain. The platform verifies signatures and confirms transfers but never holds a balance or a user key, which keeps it out of money-transmitter scope.
What can an agent pay with?
Any supported coin on the detect rail (BTC plus Lightning, ETH and ERC-20s, Solana, Tron, XRP, Monero, UCASH, custom tokens), gasless USDC on Base via the exact rail, or cards via the redirect rail. One door, three schemes.
How does the gasless USDC rail work?
The buyer signs an off-chain EIP-3009 transferWithAuthorization for USDC on Base. A funded relayer submits it on-chain, so the buyer pays no gas and needs no token approval. Funds move buyer to seller; the fee is debited from seller credit.
Do I need to change my x402 client?
No. The door speaks the standard x402 handshake (WWW-Authenticate: x402, X-PAYMENT header) and exposes POST /v1/exact-verify and /v1/exact-settle facilitator endpoints, so an off-the-shelf x402 client pays without changes.
How do agents discover what I sell?
Through UCP. GET /.well-known/ucp returns your business profile and signing key, /catalog.json returns a schema.org/Product JSON-LD catalog, and /checkout-sessions plus /orders/{id} handle multi-item mixed-currency carts.
Can I cap how much one caller spends?
Yes. Set maxPerCaller by wallet or IP with a window in hours. A buyer whose settled spend reaches the cap is refused new authorization before charge, enforced server-side across every rail.
Is there an SDK or MCP server?
Yes. Zero-dependency SDKs ship on npm (agents-u-cash) and PyPI, and a 79-tool stdio MCP server runs in Claude Desktop or any MCP client. An OpenAPI 3.1 spec is live at agents.u.cash/openapi.json.
What is the difference between a resource and a payment request?
A resource is a persistent priced door at /r/{res_id} returning a checkout_url. A payment request is a one-off /id/ link with an expiry (15m to never) that closes when paid or when it lapses.

Put your agents on HTTP 402

Price a resource, sell it per request, settle direct to your wallet. SDKs, MCP, and OpenAPI ready.

Open U.CASH Agents → Developer hub