allow402/Docs
← Back
x402 Protocol

What is allow402?

allow402 is a payment proxy for the x402 protocol — an open HTTP extension that lets any API charge per-call using on-chain micropayments (USDC on Base L2). You create API keys with a credit budget and call any x402-compatible service. The proxy handles EIP-3009 signing, on-chain settlement, and billing automatically.

The x402 protocol

x402 extends standard HTTP: when a client requests a paid resource without payment, the server returns 402 Payment Required with an X-Payment-Requirements header describing what to pay and where. The client signs and retries with a PAYMENT-SIGNATUREheader, then receives 200 OK.

allow402 sits as a transparent intermediary: your app sends a normal request, allow402 intercepts the 402, signs the EIP-3009 USDC authorization from its proxy wallet, and retries — your code only ever sees the 200.

Request flow

The animated diagram below shows the complete lifecycle of a proxied call:

AI Agent
allow402
x402 API
Waiting…
01
Your app calls the SDK or REST API
Pass the target URL and your API key. No wallet, no private keys.
02
allow402 forwards to the x402 service
Initial request without payment headers.
03
Service returns 402 Payment Required
X-Payment-Requirements specifies amount, network, and recipient.
04
allow402 signs an EIP-3009 authorization
USDC transferWithAuthorization signed from the proxy wallet on Base L2.
05
Retry with PAYMENT-SIGNATURE header
The facilitator verifies on-chain and settles payment atomically.
06
You receive 200 OK
Full response returned. Credits deducted from your balance.

EIP-3009 signing

EIP-3009 defines transferWithAuthorization — a gasless, off-chain-signed USDC transfer. allow402 holds a proxy wallet that signs these authorizations. Your app never manages private keys. The signature is valid for a single transfer to a specific recipient at a specific amount, preventing replay attacks.

Credits & pricing

Unit

1 credit = 1 micro-USDC (10⁻⁶ USDC). All amounts in the API and dashboard are denominated in credits.

CreditsUSD equivalent
1$0.000001
1,000$0.001
100,000$0.10
1,000,000$1.00
10,000,000$10.00

Commission

allow402 charges a 5% commission on each proxied call, rounded up, minimum 1 credit.

text
Service cost:   1,000 credits
Commission:        50 credits  (5%, ceil, min 1)
──────────────────────────────────────────────
Total charged:  1,050 credits

Top-ups

Credit card (Stripe)
Pay in USD via the dashboard. Credits available instantly. Minimum: $1.
USDC on Base L2
Send USDC to your allow402 deposit address. Converted 1:1 on-chain confirmation. Minimum: 1 USDC.

Response cache

allow402 can cache upstream API responses in Redis. When a cached response is available, the call is served instantly — no payment is triggered, so credits are only spent on the first unique request. This makes high-read workloads significantly cheaper and faster.

Performance tip
Setting a cache TTL on read-heavy endpoints (prices, weather, blockchain data) can reduce your credit spend by 10–100× depending on call frequency.

How to enable

Pass cacheMaxAge (seconds) in the proxy request body. The header X-Cache: HIT or MISS tells you whether the cache was used.

json
POST /v1/proxy
{
  "url": "https://prices.example.com/BTC",
  "method": "GET",
  "cacheMaxAge": 60   // cache for 60 seconds
}

Cache key

The cache key is derived from the full URL + method + request body hash. Two different users calling the same URL share the same cached response — only the first caller pays.

TTL tradeoffs

cacheMaxAgeUse caseCost impact
0 (off)Real-time data (orderbook, live prices)Full cost per call
60sFast-moving data (market data, weather)Large reduction at high frequency
3600sSlow data (ENS resolution, token metadata)Near-zero for repeated reads
86400sStatic data (contract ABIs, schemas)Essentially free after first call

Privacy

allow402 operates as a pass-through proxy. Request and response payloads are never stored persistently.

API request bodies are not stored or logged
API response bodies are not stored (cache entries auto-expire)
Only billing metadata is retained (timestamp, service, credits used, latency)
On-chain payment proofs are public by design (Base L2)