Cloudflare: role and evidence
Edge and application infrastructure with documented HTTP payment integrations. A specific SDK feature is stronger evidence than a general AI partnership.
Evidence, not endorsement
A research and planning tool, not a vendor certification. Sources describe specific products, not every service offered by a company. Unknown means not established by the sources reviewed, not unsupported. grug402 sandbox tests do not test these vendors. Operational owners are suggested team contacts, not legal liability assignments.
Editorial review: 2026-10-08. Evidence older than 90 days needs rechecking; source check dates are not release dates.
Product and roles
Operator: Cloudflare. Product scope: Workers and Agents SDK payments.
Edge networks: What may reach the origin? Handoff: Bot policy, headers and cache rules → protected origin. Suggested owner: Network, CDN and security teams.
App platforms: Where does the application run? Handoff: Application code → authenticated tools and payment middleware. Suggested owner: Application engineering.
Prerequisites to confirm
Select x402 or MPP, SDK version, wallet and supported payment method.
Set cache, WAF and retry policies for challenges and paid responses.
Discovery
Unknown: not established by the reviewed sources. Ask the provider; this is not a failed test.
Delegated authorization
Unknown: not established by the reviewed sources. Ask the provider; this is not a failed test.
Retail checkout
Not applicable: not assessed for this participant's listed role.
Paid API / tool
Documented: The docs describe server and client payment handling using x402 and MPP for HTTP resources and MCP tools.
Settlement
Unknown: not established by the reviewed sources. Ask the provider; this is not a failed test.
Deployment
Documented: Documented examples use Workers proxies and Agents SDK integrations.
Operational controls
Documented: The x402 MCP client wrapper offers optional human approval.
Relevant sandbox tests — not vendor results
These are controlled grug402 scenarios. A passing sandbox request does not certify a company, integration, checkout or refund process.
- P1: A payment that completes — Establish a baseline before diagnosing failure cases. Suggested owner: Payments engineering.
- P1: Bind approval to the right service — A payment must not be redirected to an unexpected resource host. Suggested owner: Agent product and security.
- P1: Retry without a duplicate charge — Lost responses should not cause the same purchase intent to be paid again. Suggested owner: Application engineering.
- P1: Handle paid-but-not-delivered — Settlement can succeed while the application fails to deliver. Suggested owner: Payments and customer operations.
- P2: Resolve an uncertain settlement — A server error does not establish whether money moved. Reconcile before retrying. Suggested owner: Payments operations and facilitator operator.
- P1: Establish safe edge behavior — Challenges and personalized paid responses need deliberate cache controls. Suggested owner: CDN and application engineering.
- P2: Avoid stale payment instructions — A cached challenge can advertise an expired quote or outdated payment terms. Suggested owner: CDN and payments engineering.
- P1: Prevent paid content leaking from cache — A shared cache can serve one payer's content to another visitor. Suggested owner: CDN and security.
- P2: Allow valid payment credentials through — Security policy may reject a legitimate payment retry. Suggested owner: Network and security.
- P2: Coordinate edge and settlement timeouts — A timeout can leave the buyer unsure whether the service was paid. Suggested owner: Network and payments operations.