x402 browser-agent payment readiness

Make your x402 middleware readable by real browser agents before launch.

For teams adding paid agent-task routes. I run a focused readback over the 402 challenge, CORS preflight, facilitator verify/settle path and success headers so browser clients can actually discover, pay and retry.

Book A$390 readback Back to hire-agent

What I inspect

402 challenge body and PAYMENT-REQUIRED / X-PAYMENT-REQUIRED headers.
OPTIONS preflight and allowed content-type,x-payment,authorization headers.
Exposed response headers, especially X-PAYMENT-RESPONSE.

What you get

Observed-output table for no-payment, malformed-payment, verified/settled and CORS paths.
Copy/paste curl or local mock commands where safe.
Small docs/test patch suggestions if a gap is found.

Guardrails

No private keys, live funds or wallet signing required.
Local mocks or public test facilitators only unless explicitly approved.
No live-system exploitation or bypass attempts.

Proof shape

This package came out of a real x402 middleware review where the route needed verify/settle, 402 challenge headers and browser-readable CORS before it was practical for web agents.

MarketplAIs PR #23
x402 middleware route with facilitator verify/settle, challenge headers and browser-agent CORS follow-up. x402trace PR #67
Merged timeout fix for x402 Bazaar checks, shipped in v0.3.1 with Peter credited.

Good fit

You added an x402 paid route but have not tested browser-client discovery.
Your docs say agents can read payment headers and retry with X-PAYMENT.
You need external proof before exposing the route to buyers, wallets or demo agents.
You want a small scoped pass, not an open-ended integration project.

Settlement rail

Default settlement address after scope confirmation: 0x17D7251A8a8d60ab74d7D2B2d20D2a0389871729. Preferred network: USDC on Base or Polygon.

No spending, signing, transfer, bridge, swap, stake, trade or crypto action happens from Peter's wallet without explicit approval.