Most API billing systems assume that a human creates an account, adds a credit card, selects a subscription, generates a key, and manually approves future spending.
That process works for conventional SaaS products. It becomes a bottleneck when an AI agent needs to discover and purchase a service while completing a task.
An autonomous research agent may need web search for one request, speech transcription for the next, and blockchain data several minutes later. Creating a separate account and monthly subscription for every possible provider is neither efficient nor truly autonomous.
The x402 protocol offers a more machine-native alternative. A service can respond with HTTP 402 Payment Required, provide structured payment requirements, and allow the agent to authorize payment before retrying the request.
JarvisClaw applies this model across AI models and thousands of marketplace APIs, allowing agents to discover services, understand their cost, pay in USDC, and receive results through one infrastructure layer.
What Is an x402 Payments API?
An x402 Payments API uses the HTTP 402 status code as part of a programmable payment process.
Instead of returning only a generic payment error, the server provides the client with information such as the amount, supported network, payment asset, recipient, and authorization requirements.
The basic flow is:
- An agent sends a request to a paid endpoint.
- The server returns HTTP 402 with payment requirements.
- The agent checks the price and its spending policy.
- The agent signs a payment authorization.
- The request is sent again with a
PAYMENT-SIGNATUREheader. - The gateway verifies the authorization and executes the service.
- The agent receives the API response and settlement information.
JarvisClaw also accepts X-PAYMENT as an alias for PAYMENT-SIGNATURE. Its SDK can handle the 402, signing, and retry process automatically, so application code does not need to implement every payment step manually.
Why Pay Per Call Fits AI Agents
Subscriptions are based on predictable human usage. Agent workloads are often unpredictable.
One agent may call a specialized OCR service once a month. Another may make hundreds of low-cost market-data requests in a day. Requiring both to purchase fixed plans creates unused capacity or unnecessary operational work.
Pay-per-call infrastructure gives developers several practical advantages:
- Pay only when the agent executes a paid service.
- Avoid separate subscriptions for occasional capabilities.
- Let the agent discover new services without creating another billing account.
- Apply a maximum price before execution.
- Track spending at the wallet or task level.
- Give different agents separate budgets.
- Build machine-to-machine workflows without manual checkout pages.
The largest benefit is not simply lower cost. It is reducing the gap between discovering a useful API and being able to call it.
Two Ways to Use x402 on JarvisClaw
JarvisClaw supports two payment approaches.
Option 1: API Key With Managed Settlement
The application sends a conventional Bearer token:
Authorization: Bearer sk-your-api-keyJarvisClaw uses the account’s managed HD wallet to complete the x402 settlement behind the scenes. Developers do not need to manage the 402, signing, and retry cycle.
This option is appropriate when:
- A team wants familiar API-key authentication.
- Billing should be managed centrally.
- The application needs straightforward server-side integration.
- Model calls should be billed from actual token usage.
- Developers do not want the agent to hold its own private key.
Option 2: Direct x402 Wallet Payment
The agent holds a wallet key and signs the payment authorization directly.
The paid request includes:
PAYMENT-SIGNATURE: <base64-payment-payload>This approach is appropriate when:
- The agent needs control of its own funds.
- No JarvisClaw account or platform API key should be required.
- Services are being purchased autonomously.
- Payments need to be authorized request by request.
- The workflow involves agent-to-agent transactions.
Both approaches use x402 settlement, but the responsibility for signing is different. With an API key, the platform manages settlement. With direct x402, the agent controls the wallet and authorization.
A Practical Integration Workflow
A production integration should begin with discovery rather than payment.
JarvisClaw provides a public x402 discovery endpoint:
curl https://api.jarvisclaw.ai/.well-known/x402The discovery response tells an agent which payment protocol, networks, assets, and services are available. Marketplace resources can expose real callable paths and individual pricing, allowing the agent to compare services before choosing one.
A practical workflow looks like this:
1. Define the Capability
Begin with the result the agent needs, such as:
- Transcribe a 20-minute audio file.
- Retrieve the current price of an asset.
- Compare prediction-market contracts.
- Search the web and return cited sources.
- Generate an image for a product listing.
Avoid vague requests such as “find an AI API.” Clear outputs improve service selection and budget accuracy.
2. Discover Suitable Endpoints
Search the JarvisClaw API Marketplace by capability.
Compare the request method, required parameters, output format, price, coverage, and expected latency. Do not let the agent execute the first result automatically.
3. Validate the Payment Requirement
When the selected endpoint returns HTTP 402, validate:
- The amount
- The USDC asset identifier
- The destination
- The supported network
- The authorization expiry
- The maximum amount permitted by the task
An agent should reject any payment request that exceeds its configured limit or uses an unsupported network.
4. Sign and Retry
Use the JarvisClaw SDK for automatic signing and retries where possible.
A manual integration must construct the authorization correctly, sign the exact amount in the challenge, and retry using PAYMENT-SIGNATURE or X-PAYMENT.
Do not round the quoted amount or reuse a previous signature. Amount mismatches, expired authorizations, signature mismatches, and reused nonces can cause the facilitator to reject the payment.
5. Validate the Result
A successful payment does not remove the need for API validation.
Check the response status, required fields, timestamps, source coverage, and result quality before allowing another agent or application component to use the data.
Base or Solana: Which Network Should You Use?
JarvisClaw supports USDC settlement on Base and Solana.
An EVM private key beginning with 0x is recognized as a Base wallet. A compatible base58 keypair can be used for Solana through the supported Python SDK configuration.
Base is a practical choice for teams already using EVM wallets and tooling. Solana may suit agents that already operate with SPL assets or require its faster confirmation profile.
Solana users should note one important setup requirement: the wallet needs an initialized USDC Associated Token Account. A wallet funded only with SOL is not enough to complete a USDC payment.
Never send another token or transfer USDC over the wrong network. Test with a limited wallet before funding a production agent.
The Hidden Cost of Direct x402 Model Calls
Direct x402 payments are authorized before the model generates its response.
This creates a cost difference between API-key billing and wallet-signed direct payment.
With API-key access, the platform can calculate the final charge from actual token usage after the call. With direct x402, the amount in the payment challenge is estimated before execution.
For model requests, that estimate uses the configured max_tokens. If the application allows 4,096 output tokens but the model returns only 40, the signed estimate may still reflect the much larger ceiling. Direct x402 does not perform a later refund or reconciliation for unused output capacity.
The practical fix is simple:
- Set
max_tokensaccording to the task. - Use a smaller output limit for classification or extraction.
- Use different limits for summaries and long-form generation.
- Reject unexpectedly high 402 quotes.
- Use API-key billing when actual token-based reconciliation is more important than direct wallet control.
This is one of the easiest ways to prevent unnecessary agent spending.
Set Spending Limits Before Going Autonomous
Wallet access should never mean unlimited access.
JarvisClaw’s Wallet API supports:
- Per-request maximum spending
- Daily spending limits
- Monthly spending limits
- Automatic pause below a specified balance
A limit update can be made with:
curl -X PUT https://api.jarvisclaw.ai/v1/wallet/limits \
-H "Authorization: Bearer sk-YOUR-KEY" \
-H "Content-Type: application/json" \
-d '{
"daily_max_usd": 30,
"per_request_max_usd": 0.50,
"monthly_max_usd": 200,
"auto_pause_below_usd": 5
}'The correct field is per_request_max_usd, not per_call_max_usd. Using the wrong field may leave the intended restriction unchanged.
Production agents should also use:
- Separate development and production wallets
- Capability allowlists
- Limited wallet balances
- Maximum retry counts
- Request timeouts
- Alerts for unusual spending patterns
- Human approval for expensive or irreversible actions
- Logs containing the endpoint, quoted price, result status, and latency
Common x402 Payment Failures
The Agent Receives HTTP 402 Repeatedly
Check whether the wallet has sufficient USDC and whether the retry includes a fresh, valid payment signature.
The Signature Is Rejected
Confirm that the private key controls the address named in the authorization. Sign the exact amount from the challenge without rounding.
Solana Is Not Offered
The wallet may not have an initialized USDC token account, or the required payment path may not currently advertise Solana.
The Authorization Expired
Generate a new signature and retry. SDK-based integrations normally handle this automatically.
The Agent Spends More Than Expected
Review max_tokens, retry behavior, duplicate requests, and the difference between API-key billing and direct x402 authorization.
A Failed Request Was Charged
Separate an upstream application failure from a payment or network failure. Store request IDs, settlement data, and the original response so the transaction can be investigated accurately.
When Should Developers Use x402?
x402 is particularly useful for:
- Autonomous research agents
- Agent-to-agent marketplaces
- AI tool discovery and execution
- Pay-per-call data services
- API aggregators
- Crypto-native applications
- Temporary or low-frequency API use
- Services sold to software rather than human subscribers
It may be unnecessary for a fixed internal application that uses one provider under a predictable monthly contract.
The right question is not whether every API needs blockchain payment. It is whether a machine needs to discover, authorize, and pay for a digital service without waiting for a person.
From API Access to Agent Commerce
Giving an agent access to tools is only one part of autonomy.
The agent also needs to discover available services, understand pricing, follow spending rules, authorize payment, verify the result, and create an audit trail.
JarvisClaw combines these layers through its API Marketplace, x402 payment infrastructure, Wallet API, MCP server, and Agent Intent Protocol.
Developers can start with familiar API-key authentication and move selected agents to direct wallet payments when stronger financial autonomy is required.
Explore the JarvisClaw API Marketplace, review the x402 documentation, and test the first workflow with a limited wallet and strict per-request budget.
FAQ
What is the x402 payment protocol?
x402 is a machine-readable payment protocol based on the HTTP 402 Payment Required status. It allows a server to quote a price and a client to authorize payment before accessing a paid resource.
Can an AI agent pay for an API without an API key?
Yes. With direct x402 payment, an agent can sign a payment authorization using its own compatible wallet instead of sending a conventional platform API key.
What currency does JarvisClaw use for x402 payments?
JarvisClaw uses USDC for x402 settlement on supported networks.
Does JarvisClaw support Base and Solana?
Yes. JarvisClaw documents x402 payment support for USDC on Base and Solana. SDK and wallet setup requirements differ between the two networks.
What is the difference between API-key billing and direct x402?
API-key billing lets JarvisClaw manage x402 settlement from a platform wallet. Direct x402 allows the agent to hold its own key and sign each payment authorization.
Is a failed API call charged?
JarvisClaw’s direct x402 documentation states that a non-successful response does not settle payment. Developers should still log request and settlement data to distinguish API, network, and payment failures.
How can I stop an AI agent from overspending?
Use a per-request limit, daily and monthly caps, a limited wallet balance, capability allowlists, retry limits, and human approval for unusually expensive calls.
Why does max_tokens matter for x402 payments?
Direct x402 model calls are quoted before execution. A high max_tokens value can produce a larger payment quote even if the final response is short.
Where can an agent discover JarvisClaw’s x402 capabilities?
Agents can query:
https://api.jarvisclaw.ai/.well-known/x402The endpoint publishes supported payment networks, assets, services, and discovery information.