What Is x402? Payment Rails vs. Agent Identity and Spend Controls
TL;DR
- x402 is an HTTP payment protocol for accessing paid resources. It coordinates payment and settlement, but it does not establish agent identity or enforce spending limits.
- A resource server can respond to a request with HTTP 402 and payment requirements. The client then provides payment information and retries the request.
- A settled payment does not tell the resource server which agent acted or whether someone authorized that agent to spend.
- We treat delegated authority, spending limits, and approval of individual transactions as separate controls that a payment flow does not provide on its own.
What x402 is and how the HTTP 402 payment flow works
x402 is a protocol for requesting payment when a client tries to access an HTTP resource. A resource server can respond with HTTP 402, or “Payment Required,” and specify how the client can pay. The client then retries the request with payment information. We treat that exchange as a way to pay for access, not as proof that the client was authorized to spend.
For example, an AI agent requests a paid data endpoint. The API server returns a 402 response with payment requirements, including the amount, accepted asset, network, and recipient for the payment option it offers. The agent’s payment software prepares a signed payment authorization and retries the API request with that authorization in the PAYMENT-SIGNATURE header. The signature lets the server check the proposed payment. It does not, by itself, mean settlement has finished.
The API server can use an x402 facilitator to verify the payment authorization and submit the payment for settlement. Once the server confirms that the payment meets its requirements, it returns the paid data. The facilitator handles payment verification and settlement work on the server’s behalf, but it does not decide whether the agent had permission from its owner to buy the data.
A blockchain-based x402 payment depends on the network and asset named in the server’s payment requirements. Stablecoins can be used for that exchange, but a reader should not assume every x402 request uses the same stablecoin or chain. The specific payment option offered by the resource server determines what the client must provide.
What x402 settles and what it leaves unanswered
An x402 payment can establish that a client met the payment terms for a resource. It does not establish who operates the client or whether that operator authorized the purchase. For example, a paid API can accept an agent’s payment and return the requested data even if the agent’s owner never approved that expense. A wallet address may identify where a payment came from, but it does not by itself identify the agent’s operator or the agent’s authority.
We separate the unanswered questions into four layers. Agent identity establishes which agent is making the request. Delegated authorization establishes who gave that agent permission to act. Spending limits bound how much the agent may pay, and transaction-level authorization determines whether a particular purchase falls within that permission. Those controls can evaluate the agent and its intended purchase before payment. x402 handles the payment exchange, but successful settlement alone cannot answer those authorization questions.
The four layers a real agent payment stack needs
We separate an agent payment into four checks because payment settlement alone cannot tell an API provider which agent acted or whether the agent had permission to spend. Each check answers a different question before the provider accepts a paid request.
Agent identity answers who is calling. A credential can identify a particular agent and, where the credential supports it, link that agent to an operator. Identity is usually established before a transaction. The provider can check whether the credential remains valid on each request, but identity alone does not grant spending authority. Revoking the credential can block a pending transaction only if the provider checks it before accepting payment.
Delegated authorization answers what the agent may do for its operator. A grant might permit an agent to buy access to one API without permitting other purchases. The grant defines a scope in advance, while the provider checks that scope against each request. An operator can revoke permission for a pending transaction if the provider enforces revocation at the time of purchase.
Spending limits answer how much the agent may spend. A limit might cap each API call at $1 and total purchases at $20 per day. The cap is set in advance, but a provider or payment control must check current spending before approving each new charge. Changing the cap or disabling spending can stop a pending charge if that check occurs before payment. Neither action reverses a settled payment.
Transaction-level controls answer whether this particular purchase fits the agent’s current task. A policy might approve a $0.10 weather-data request but reject a $0.10 request to an unrelated API, even when both fit the spending cap. The provider evaluates the request when the agent makes it rather than relying only on an earlier grant. A transaction can be denied before payment when that policy check runs in the payment path.
x402 compared to identity and spend-control layers
We separate x402’s payment exchange from the checks that identify an agent and determine whether it may make a particular payment. In the last column, “yes” means a control can reject an individual transaction before payment.
| Layer | What it answers | Example mechanism | Example product or standard | Revocable at transaction level |
|---|---|---|---|---|
| Payment protocol and settlement | How does the client pay for the resource? | Payment request, proof, and settlement | x402 | No |
| Agent identity | Which agent is acting? | Verifiable agent credential | Skyfire KYA token | No, not by identity alone |
| Delegated authorization | Who gave the agent authority, and for what? | Scoped permission grant | OAuth scopes | No, if the grant is checked only when issued |
| Spending limits | Does this payment fit the permitted budget? | Limit checked before each payment | Agentic Wallet spend controls | Yes, if checked per payment |
| Transaction-level authorization | May this agent make this specific payment now? | Per-payment policy decision | Transaction authorization policy | Yes |
Where Skyfire’s KYA token and Agentic Wallet fit
At Skyfire, we position our KYA token as a portable way to identify an agent and connect that identity to transaction-scoped payment authorization. KYA addresses who the agent is and what it has authority to do. An API provider could use those answers to evaluate a purchase request, but a valid identity token does not settle a payment.
Our Agentic Wallet addresses a different question. It lets you apply wallet-based spend controls to an agent’s payments. For example, an agent may have authority to buy API access but still need a spending limit for that task. Payment authorization and spending limits remain separate checks, even when they apply to the same transaction.
A payment rail such as x402 handles the payment exchange and settlement. KYA and the Agentic Wallet address identity, authorization, and spend controls alongside that rail. No x402 integration or support is confirmed in first-party Skyfire documentation. You should not assume the products work together without verifying a specific implementation.
Concrete example: a paid API call with identity and spend controls layered on
Suppose your research agent calls a metered data API that charges $0.10 per response. You authorize the agent to buy data for one task, with a $1 daily limit. In this illustrative design, the API provider accepts a Skyfire KYA token to identify the agent, and an Agentic Wallet policy controls its spending. We are not claiming that Skyfire integrates with x402 or that any particular API accepts KYA.
The agent first presents its identity token, and the API provider checks which agent made the request and whether you delegated access for this task. If the request passes those checks, the provider returns an HTTP 402 response with payment instructions. The agent can then submit payment and retry the request with payment evidence. The payment protocol handles the pay-to-access exchange, while the provider decides whether to serve the response.
Before authorizing each payment, the wallet policy checks the proposed charge against the agent’s remaining daily allowance. After ten $0.10 calls, it rejects an eleventh charge. Separately, the provider can reject a request if you revoke the agent’s authority, even when the wallet still holds funds. Transaction-level checks make those decisions for the current call rather than relying solely on credentials issued earlier.
Without the identity and delegation checks, an unauthorized agent could settle a payment and receive data. Without the spending limit, an authorized agent could keep making paid calls beyond your intended budget.
Comparison table: payment rails vs. identity and authorization
A paid API request raises separate questions about payment, identity, and authority. Our KYA token and Agentic Wallet address identity and payment authorization, but our published documentation does not confirm x402 integration.
| Layer | Question answered | Who or what provides it | Example |
|---|---|---|---|
| x402 and payment rails | How does the client pay for the resource? | x402 payment flow and the payment rail | An API requests payment before serving a paid response. |
| Agent identity | Which agent is acting? | Skyfire’s KYA token | An accepting service checks the agent identity presented with a request. |
| Delegated authorization | Who gave the agent permission to act? | The owner’s delegated permissions, checked by the service | An owner permits an agent to purchase one API report. |
| Spending limits | How much may the agent spend? | Spend controls configured through Skyfire’s Agentic Wallet | A configured cap blocks a purchase above its limit. |
| Transaction-level controls | Is this specific purchase permitted? | A policy check against the agent, task, and transaction | A purchase outside the approved task is rejected. |
FAQs
- Does x402 require a blockchain or stablecoin? The x402 payment flow does not, by itself, require a particular currency or network. A resource server can specify the payment methods it accepts, which may include a stablecoin on a blockchain.
- Does x402 authenticate the agent? A successful x402 payment shows that the client met the resource server’s payment terms. It does not establish which autonomous agent made the request or whether a user authorized that agent to spend.
- Can x402 be combined with an identity token like KYA? An API provider could check an identity token separately from an x402 payment to establish who the agent is and what authority it holds. That approach does not establish an integration between x402 and Skyfire’s KYA token.
- Does KYA alone satisfy KYC requirements? No. KYC processes verify people or businesses, while KYA addresses an autonomous agent’s identity and authority. Agent identity records may support attribution and audit evidence, but they do not independently satisfy KYC laws.
- Is Skyfire x402-compatible? We have not verified x402 integration or support in first-party Skyfire product documentation, so we do not claim compatibility. Skyfire describes KYA and its Agentic Wallet as agent identity and payment-authorization infrastructure, which addresses different questions than payment settlement.
Conclusion
A payment rail can settle an agent’s API charge without establishing whether the agent had permission to make it. You need separate controls to identify the agent, define its delegated authority, and enforce spending limits for each transaction. Treat those controls and payment settlement as separate layers when you design an agentic-commerce workflow.
Evaluate each rail and identity or authorization product on its own documented capabilities. We position Skyfire’s KYA token and Agentic Wallet as agent identity and payment-authorization infrastructure, not as confirmed x402 integrations. Check first-party documentation before assuming any vendor supports a specific protocol or that separate products work together.