What Is x402 and How Does It Work With WordPress?
A practical explanation of HTTP 402, x402 payment challenges, USDC settlement, and how Access402 adds the flow to WordPress content and APIs.
x402 is an open payment protocol built around HTTP 402 Payment Required. A protected server describes a payment in a machine-readable challenge; a compatible client authorizes it and retries the request with payment proof. Access402 brings that flow to WordPress through a plugin and a managed verification and settlement service.
Key takeaways
- HTTP 402 becomes a structured payment negotiation rather than a dead-end error page.
- WordPress remains the content host and enforcement point; Access402 manages payment verification, settlement, rules, and activity.
- Live payments use USDC on Base and settle to the wallet configured on the Access402 project.
- Humans can pay through MetaMask, while compatible agents can respond to the protocol directly.
Start with the HTTP request
The useful way to understand x402 is as a request-response loop. A client asks for a protected URL. Instead of returning the resource, the server responds with HTTP 402 and structured payment requirements. Those requirements identify what is being purchased and the exact terms the server will accept.
The client then authorizes the stated payment and retries the request with its payment payload. The server verifies that payload, settles it through a facilitator, and returns the resource only after settlement succeeds. This works especially well for software because the price and payment instructions travel with the request.
What Access402 adds to WordPress
WordPress does not natively know how to create an x402 challenge, validate a wallet authorization, or decide when a blockchain settlement is final. The Access402 adapter adds that enforcement layer without replacing the theme, database, hosting provider, authors, or normal publishing workflow.
A site owner connects the plugin to an Access402 installation, chooses Sandbox or Live, and creates protection rules. A rule can target a post, page, Media Library file, or an existing WordPress REST API route. The rule includes the resource identity, display information, USDC price, access model, and status.
- Posts and pages receive a browser payment screen for unpaid visitors.
- REST endpoints return the machine-readable x402 response an automated client expects.
- Protected media stays associated with its WordPress attachment while WordPress controls delivery after payment.
- Selected logged-in WordPress roles can bypass payment when the rule permits it.
What happens outside WordPress
The sensitive part of payment processing stays on Access402 servers. The plugin authenticates using an installation-scoped API key. Access402 loads the server-side project and rule, validates the requested resource, amount, network, USDC asset, and receiving wallet, then calls the hosted facilitator to verify and settle.
This separation matters. Coinbase facilitator credentials do not belong in a WordPress option, browser bundle, Cloudflare variable, database response, or log. WordPress receives only the result it needs to enforce access.
Where the payment goes
Access402 is not a custodial payout account. In Live mode, USDC settles on Base to the payTo wallet configured for the authenticated project. In Sandbox, test USDC moves on Base Sepolia. The same installation ID and API key work in both modes; the WordPress toggle selects the environment.
Access402 creates a dedicated Coinbase wallet for the project and automatically uses it as the payment destination. The publisher does not paste a wallet address into WordPress or manage a seed phrase. Funds are currently received and managed through Coinbase; integrated cash offboarding is planned for a later release.
Can AI agents use it?
Yes, if the agent supports x402 and knows the protected URL. It can interpret the challenge, authorize the required amount, retry, and consume the response without a human checkout flow. This makes x402 suitable for reports, datasets, API results, files, and other resources bought per request.
Discovery and payment remain separate capabilities, but Access402 can now advertise an opted-in WordPress rule using the x402 v2 Bazaar extension. CDP validates the public endpoint and catalogs it after its first successful settlement. A publisher can remove the discovery metadata later without disabling the payment rule.
Put this into practice
Continue from the problem to the implementation path that fits your resource.

