All guides

How to Protect a WordPress REST API With x402

A step-by-step guide to adding x402 payment protection to an existing WordPress REST API route with Access402.

Jonathan Royere
Written byJonathan Royere
Direct answer

Install and connect the Access402 WordPress adapter, create a REST protection rule for the exact existing route, set its USDC price and access type, test the x402 v2 challenge and paid retry in Sandbox, then switch the same installation to Live when the result is correct.

Key takeaways

  • Access402 protects an existing REST route; it does not create the underlying API endpoint.
  • Route matching must normalize duplicate slashes and other harmless path variations before evaluating the rule.
  • A WordPress administrator can bypass payment when the configured role permissions allow it.
  • Sandbox and Live use the same installation credential but different networks and token contracts.

Before you create a rule

Confirm that the REST endpoint already works and that its response is safe to sell. Access402 adds payment protection around a route registered by WordPress, your theme, or another plugin; it does not generate the endpoint or decide what data it should return.

Use a stable route rather than a URL with temporary query parameters. Decide whether the price applies to every request or whether a successful payer should receive reusable access for that rule. Also decide which logged-in WordPress roles should bypass the gate for administration and editorial work.

1. Connect the WordPress installation

The API key is scoped to the installation. You do not need separate “test” and “live” keys: the WordPress mode toggle controls whether the challenge uses Base Sepolia or Base while the connection identity remains the same.

  1. Create an Access402 project and attach its receiving wallet.
  2. Create a WordPress installation inside that project.
  3. Download and activate the Access402 adapter in WordPress.
  4. Paste the installation ID and generated API key into the Connection tab.
  5. Save and verify the connection. Keep Sandbox selected for the first test.

2. Add the exact REST resource

Open the Rules tab, select the REST resource type, and enter the route beginning with /wp-json/. Add a clear display name and description, set the USDC price, choose the access type, and enable protection.

The adapter should reject a duplicate normalized rule for the same resource. It should also normalize the incoming path before matching, so adding an extra slash—such as //wp-json/...—cannot bypass protection. Query handling should be intentional: a harmless tracking parameter should not create an unpaid copy of a protected endpoint.

3. Inspect the unpaid response

Request the endpoint without payment. An unauthenticated external request should receive HTTP 402 with the x402 v2 payment requirements. A logged-in WordPress administrator may receive the original resource instead if administrator bypass is enabled; test in a private browser or command-line client to see the payer path.

  • The resource must correspond to the normalized protected route.
  • The network must be Base Sepolia in Sandbox.
  • The asset must be the configured test USDC contract.
  • The amount must equal the server-side rule price.
  • The payTo address must equal the project receiving wallet.

4. Complete a Sandbox payment and retry

Use an x402-compatible client with test funds to authorize the challenge and repeat the request with the payment payload. A successful flow returns the original endpoint response, creates one successful settlement record, and increments successful plan usage once.

Also test the failure cases: alter the amount, network, recipient, or signature; reuse an expired authorization; retry the same idempotency key; and simulate unavailable settlement. Each must fail closed without unlocking the response or consuming permanent quota on a failed settlement.

5. Switch the installation to Live

After the challenge and delivery behavior are correct, confirm the project’s production receiving address and switch the WordPress adapter to Live. The route will now challenge for real USDC on Base. Make a small payment and verify the resulting transaction hash independently before sending production traffic.

Monitor Access402 activity for the installation, resource, amount, environment, payment status, access result, and transaction hash. A production launch should also include API response monitoring on the WordPress site so a payment success cannot be hidden by a later application error.

Put this into practice

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

Jonathan Royere
Builder of Access402Jonathan Royere

Jonathan Royere builds Access402, a managed x402 payment platform for websites and APIs.

Keep reading

Related guides