Protocols and agents
HTTP 402 can organise programmable payments in the conversation between a client and an API. It is only useful when identity, pricing, security, failures and responsibility are designed alongside the protocol.
Full article
x402 proposes using HTTP 402 Payment Required so an API can state payment requirements and a client can respond with a verifiable payment authorisation. The idea may reduce per-call billing friction, but it does not eliminate architecture, security or business decisions.
In broad terms, a client requests a resource; the server states the payment requirement; the client creates a payment payload; and a facilitator verifies and settles it according to the configured network and asset. The protocol organises the HTTP conversation — it does not replace authentication, access control or observability.
Usage-billed APIs, paid digital content, service-to-service tools and agents needing specific capabilities are possible scenarios. The choice depends on price, risk, network, token, custody, operational reversibility and user experience.
A 402 response does not make a service trustworthy by itself. Define party identity, price policy, limits, idempotency, failure handling, reconciliation, logs, abuse protection and responsibility for data and keys.
Programmable payments can reduce integration steps, but they do not automatically resolve commercial disputes, taxation, privacy, support or compliance. Start a prototype small, in a controlled environment and with clear shutdown criteria.
References
Next step