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. - Read the Quickstart for existing x402 integration instructions.
What you'll find here
- A plain-language x402 overview, the spending-limit model, a code sample, and an x402 FAQ.
Quick answer
How do x402 spending limits work in Harpd?
Harpd puts a policy layer above x402: every agent payment is checked against per-agent, per-tool and per-session budgets before your facilitator settles it, and the result is independently verified afterwards. Overspend is stopped at the guardrail — blocked, routed to a fallback, or sent for human review — and every decision is recorded for audit. Harpd never holds funds or keys.
- Granularity
- Per-agent · per-tool · per-session
- On exceed
- Block · fallback · review
- Custody
- Non-custodial
Data source: Harpd protocol referenceLast updated:
Why it matters
Autonomous agents that can spend need a spending policy finer than a single wallet cap. Per-agent, per-tool budgets with attribution and independent reconciliation let a team let agents pay for API and tool calls while still being able to prove exactly which agent spent what, and why — the minimum bar for delegating money to software.
Limitations
- This page is a spending-limit explainer, not a step-by-step integration guide; see the Quickstart for setup.
- Harpd is non-custodial — it enforces policy through your existing facilitator but never takes custody of funds or keys.
- On-chain verification and supported facilitators depend on the connector you deploy; coverage is EVM-based.
Data source: Harpd protocol reference
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'
})
x402 is one of four agent payment protocols shipping in 2026. For the full picture — how it compares to Stripe MPP, Google AP2 and Mastercard Agent Pay on fees, rails and integration effort — read the x402 vs MPP vs AP2 comparison.
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.