How AI Agents Pay for WordPress Content

Key takeaways

• The agent needs both the protected URL and an x402-capable payment client.
• The 402 response carries the exact amount, network, asset, recipient, and resource terms.
• Access402 validates the payment against its server-side rule before settlement.
• Automatic protocol payment does not automatically make a resource publicly discoverable.

1. The agent reaches a known resource

The flow begins with ordinary discovery. The agent may find a URL in a website, API document, search result, feed, tool description, or a direct instruction from its user. It then makes the same HTTP request it would make for an unprotected resource.

Access402’s WordPress adapter can protect a page, post, Media Library file, or existing REST route. The URL continues to belong to the WordPress site. That is important because links, publishing tools, and existing integrations do not have to move to a separate payment domain.

2. WordPress returns a payment challenge

If the request has no valid payment or reusable access grant, the adapter matches it to a synchronized rule and returns HTTP 402. The response describes an x402 version 2 payment requirement rather than sending an agent through a visual checkout.

• The protected resource identifier and request context.
• The exact USDC amount in token units.
• Base for Live or Base Sepolia for Sandbox.
• The expected USDC contract and project receiving wallet.
• The scheme and timing constraints the payment authorization must satisfy.

3. The agent authorizes—without giving the site its key

The agent’s wallet signs the payment authorization locally or through its wallet infrastructure. Neither WordPress nor Access402 needs the payer’s private key. The authorization is narrowly scoped to the payment terms in the challenge.

A capable agent should verify the domain, resource, amount, asset, network, and recipient before signing. This is the machine equivalent of a person checking the merchant and total before approving a card payment.

4. Access402 verifies and settles

The retry reaches WordPress with the payment payload. WordPress forwards the required settlement context through its authenticated installation. Access402 does not accept the browser or agent’s claims at face value: it reloads the authoritative project and rule, confirms every important field, applies account and platform limits, and reserves usage before contacting the facilitator.

The hosted facilitator verifies the authorization and settles the transfer. If authentication, verification, or settlement fails, the service fails closed. A repeated idempotency key cannot cause the same logical purchase to settle twice.

5. WordPress serves the result

Only a successful settlement produces a transaction record and permits delivery. Depending on the rule, the payment may unlock one request or produce a reusable grant associated with the payer and resource. Access402 records payment and access activity so the publisher can reconcile usage.

For API routes, the agent receives the original JSON or other endpoint response. For a page or file, WordPress returns the protected content through the adapter’s delivery path.

Payment and discovery are different problems

x402 gives an agent a standard way to understand and satisfy a payment request. It does not guarantee that the agent knows a paid resource exists. Publishers should still make useful descriptions, prices, URLs, content types, and intended uses easy to find in human-readable pages and machine-readable documentation.

Access402 keeps discovery as an explicit rule setting. When enabled, WordPress advertises x402 v2 Bazaar metadata and CDP can catalog the route after a successful settlement. Removing discovery stops advertising the metadata without disabling the underlying payment rule.

Put this into practice

Continue from the problem to the implementation path that fits your resource.