Native HTTP
No custom RPC. x402 rides on the same request/response your agents already make.
x402 · spending limits
Hard spending limits for x402 agent payments
Set per-agent and per-tool x402 budgets, stop overspend before settlement, and reconcile every payment — without holding funds or private keys.
About this page
How to use this page
- Read the What is x402? explainer to see how machine-to-machine payments flow over HTTP.
- Use the spending-limit model section to map a wallet cap to per-agent x402 budgets.
- Check the code sample to see how
@harpd/observeenforces a budget before settlement. - Hit See pricing or Quickstart to start sending x402 events.
What you'll find here
- A plain-language x402 overview, the spending-limit model, a code sample, and an x402 FAQ.
Machine-to-machine payments, over plain HTTP.
x402 reuses the HTTP 402 Payment Required status as a native payment handoff: an agent requests a resource, the server states a price, the agent settles it through a facilitator, and the resource is served. Harpd sits above that flow as the policy layer.
Facilitator-agnostic
Works with Coinbase, Stripe, Circle, Alchemy, AltLayer, or your own settlement layer.
Any EVM chain
Settle on Ethereum, Base, Arbitrum, Polygon, Avalanche and more.
From one wallet cap to real x402 budgets
A single wallet ceiling is too blunt for autonomous agents. Harpd breaks spend control into the units that actually matter.
| Control | A raw wallet cap | Harpd x402 budgets |
|---|---|---|
| Granularity | One number, whole wallet | Per-agent, per-tool, per-session |
| Attribution | No | Every paid call tagged to agent + tool |
| Approval step | — | Block, fallback, or human review on exceed |
| Reconciliation | Manual | Independent, exportable audit trail |
| Custody | Keys in the wallet | Non-custodial — keys never touch Harpd |
Stop x402 overspend before it settles.
Harpd checks your budget policy before the facilitator settles an x402 payment, then independently verifies the result. Funds and keys stay with you.
- Per-agent daily / monthly x402 caps
- Pre-settlement approval threshold
- Non-custodial by design
// enforce a hard x402 budget before settlement
import { enforceBudget } from '@harpd/observe'
await enforceBudget({ apiKey: process.env.HARPD_KEY, endpoint: 'https://api.harpd.com' }, {
agentId: 'agent-1', tool: 'premium-search',
maxUsdPerDay: 25, onExceed: 'block', // or 'approve'
})
Frequently asked questions
What is x402?
x402 is the HTTP
402 Payment Required status reused as a native standard for machine-to-machine payments. An agent hits a paid endpoint, the server returns a payment requirement, the agent (or its facilitator) settles it, and the resource is released — all over plain HTTP.Can I set spending limits on x402 payments?
Yes. Harpd applies a budget policy before settlement: every x402 request is checked against per-agent and per-tool spend limits, and calls that would exceed a limit are blocked or routed to an approval step before any money moves.
Does Harpd hold the funds or the signing keys?
No. Harpd is non-custodial. It observes x402 flows and enforces your policy through your existing facilitator (Coinbase, Stripe, Circle, or your own) — it never takes custody of funds or private keys.
What happens when an agent exceeds its x402 budget?
The call is stopped at the guardrail. Depending on your configuration, Harpd either blocks it, falls back to an approved model, or sends it to a human for review — and records the decision for audit.
Which chains and facilitators are supported?
Harpd is facilitator-agnostic and chain-agnostic across EVM: Ethereum, Base, Arbitrum, Polygon, Avalanche and others, via Coinbase, Stripe, Circle, Alchemy, AltLayer or a self-hosted facilitator.
How is this different from just setting a wallet cap?
A wallet cap is a single crude ceiling. Harpd gives you per-agent, per-tool, per-session budgets with attribution, approvals, and independent reconciliation — so you can see exactly which agent spent what and why, and prove it afterwards.