x402 agent payments: what the protocol handles—and what your operation still owns
A plain operating guide to HTTP 402 payment requirements, signed authorization, facilitator verification, settlement, and resource delivery.
Use this guide when deciding whether x402 is suitable for a paid API, MCP tool, data resource, or agent-to-agent service and what must exist around the protocol before production use.
The core exchange is request, requirement, payment, resource
A client requests a protected resource. The resource server returns payment requirements. The client constructs a supported payment payload and retries. The server verifies and settles directly or through a facilitator, then returns the resource and settlement response.
Version and header details matter
The current x402 v2 specification separates core types, scheme logic, and transport representation. For HTTP, payment requirements and signatures use defined headers and encoded schemas. Implement against the selected specification and SDK version rather than copying an older demonstration.
The facilitator reduces infrastructure, not accountability
A facilitator can verify and settle supported scheme and network pairs. The resource server still owns accurate pricing, correct recipient configuration, authorization handling, fulfillment idempotency, error behavior, logs, and the decision to release the protected resource.
Security is larger than signature validity
Nonce and time-window controls address replay at the payment layer. Production design must also consider compromised agent credentials, prompt-driven spend, duplicate requests, vendor substitution, denial of service, stale quotes, reconciliation gaps, and unsafe retry behavior.
Readiness questions
- →The protected resource and price are explicit.
- →The client, resource server, facilitator, scheme, network, asset, and recipient are identified.
- →Retries cannot create duplicate charges or duplicate fulfillment.
- →Payment failure and settlement uncertainty fail safely.
- →Secrets and wallet signing authority remain outside prompts and browser-visible code.
What a scoped next step can deliver
- →x402 integration decision record
- →Payment and fulfillment sequence diagram
- →Error, retry, and idempotency test plan
- →Settlement evidence and operational handoff
Need help applying this to your operating context?
We begin by clarifying the decision, scope, ownership, and constraints. The appropriate next step may be a diagnostic, a workshop, a bounded implementation, or a respectful no-go decision.
Review an x402 implementation →