Charging for an API, dataset, premium page or MCP tool does not require turning every resource into a traditional checkout. With x402, the HTTP exchange can state that payment is required, describe accepted options and let a compatible client authorize access. The hard part is designing rules, verification, execution, settlement, metering and reconciliation without exposing the origin.
This guide explains an interoperable x402 Monetization Gateway using Cloudflare’s current x402 documentation (opens in a new tab ↗) y Cloudflare’s announcement and current protocol documentation as references. It does not claim that every described capability is available to every AZPay or Cloudflare account. Availability, network, asset, facilitator and commercial terms must be confirmed in the chosen environment.
What x402 solves
HTTP already has 402 Payment Required, but the status alone does not define how a server communicates price, network, asset, recipient or authorization. x402 adds objects and headers so the server can describe requirements and the client can return a signed authorization. In version 2, the response uses PAYMENT-REQUIRED and the paid request uses PAYMENT-SIGNATURE.
The basic flow is request, 402 requirements, signed retry, verification, resource execution according to the scheme, settlement and delivery. This is powerful for APIs, but it does not turn every browser into a wallet or remove identity, authorization, origin-security and support responsibilities.
A control plane, not just a paywall
A gateway must answer which resource is requested, who may access it, what it costs, how payment is verified and what happens after execution. Rules can combine domain, path, HTTP method, audience, headers, parameters and caller attributes.
The control plane should hold resources, origins, versioned rules, receiving wallets, networks, environments and audit events. The data plane evaluates rules at the edge, returns 402 when needed, protects the origin and records the lifecycle. Publishing a policy without redeploying every application requires versioned snapshots, explicit precedence and rollback.
exact and upto
With exact, the authorized amount must match the required price. With upto, the client authorizes a ceiling and the server may report actual consumption when the implementation and facilitator support that behavior. Variable pricing requires trustworthy measurement; a ceiling is not permission to charge any amount.
Do not confuse per-request pricing with subscriptions, prepaid balances or postpaid billing. Record intent, authorization, verification, execution, measured value, settlement, delivered response and failure as related facts rather than one “paid” column.
The origin remains part of security
Edge verification does not authorize bypassing the origin. Prevent direct access, preserve the required context and, when applicable, send a signed context that the origin validates. Client-facing x402 headers and gateway-to-origin trust headers are different surfaces.
Converting an origin 401 into a payment opportunity must be an explicit policy. An authenticated user should not lose a session because of a rule mistake, and an unauthenticated buyer should not gain access merely because every origin error became a 402.
Facilitators, networks and environments
A facilitator exposes verification and settlement operations for a compatible scheme and network. Its supported assets, signers, limits, expiry rules, costs and responsibilities vary. Use testnet to validate the technical contract and separate development, testnet and production.
x402 v2 uses CAIP-2 network identifiers and fields such as scheme, network, asset, amount, payTo and maxTimeoutSeconds. Use compatible libraries rather than manually copying old signing examples. Check facilitator capabilities before publishing a rule.
Where Pix fits
Pix and x402 are related but different. Pix is Brazil’s payment arrangement with its own collection, QR Code, confirmation and reconciliation lifecycle. x402 is an HTTP payment convention with schemes and networks defined by the implementation. A company may serve x402 clients and keep a separate Pix checkout for people; a QR Code is not an x402 signature, and an x402 wallet is not automatically a Pix account.
For Pix, reliable confirmation still comes from the participant and contracted integration, not from a client screen. See the AZPay guide to the Pix lifecycle.
A practical launch checklist
Start with resource ownership and ensure the origin cannot be reached around the gateway. Define precedence, choose exact or upto only after defining the calculation, and fix protocol version, network, asset, wallet, facilitator and environment.
Test unpaid access, valid authorization, expiry, amount mismatch, nonce replay, settlement failure, timeout and safe retry. Reconcile access attempt, authorization, on-chain settlement and delivered resource with stable identifiers. If one cannot be related to the others, support will struggle to explain a failed charge or access.
FAQ
Does x402 replace a human checkout? No. It is especially useful for programmatic clients, agents and applications that can interpret requirements and sign authorization. A human checkout may need accessibility, authentication and local methods such as Pix.
Does the announcement prove availability? No. The current documentation, account access, network, facilitator and applicable contracts determine what can be enabled. Treat untested capabilities as unconfirmed.
The first useful delivery is a testable rule with a protected origin, compatible client, separate environment and an auditable record of every step. The goal is a verifiable boundary between intent, payment and access.