Edge x402 monetization: AWS CloudFront vs Cloudflare
Both clouds now enforce x402 payment at the edge. One is generally available and one is a waitlist. A provider-side comparison with the availability stated plainly.
DIRECT ANSWER
AWS ships x402 enforcement in CloudFront through a Monetize action in WAF Bot Control, generally available since late June 2026 and settling in USDC on Base and Solana. Cloudflare announced its Monetization Gateway on 1 July 2026 and it remains waitlist-only, with the buyer-side Cloudflare Wallets announced 4 August and not yet usable for payment.
Key takeaways
- AWS reached general availability roughly two weeks before Cloudflare announced, which is the reverse of how the two are usually ordered.
- Both enforce payment at the edge before a request reaches origin, so neither requires origin changes.
- Announcement and availability are different things; plan against what you can deploy today.
The same idea arrived twice in three weeks
Edge monetization puts the payment wall in front of the origin. The content delivery network inspects an incoming request, decides whether it needs to pay, returns an HTTP 402 with machine-readable requirements when it does, and only forwards the request once payment is presented. The origin never sees an unpaid request and needs no x402 code.
AWS and Cloudflare both shipped that shape within about three weeks of each other in mid-2026. The designs differ less than the delivery status does, which is the part most coverage gets wrong.
What AWS actually shipped
AWS added x402 support to CloudFront through AWS WAF Bot Control. Publishers configure a Monetize action inside a Bot Control rule attached to a CloudFront distribution, and payment is enforced at the edge before requests reach origin servers. Settlement is in USDC on Base and Solana.
It is generally available, and carries no additional charge beyond standard WAF pricing. For a team already running CloudFront with WAF, this is a rule change rather than a new dependency, which is a meaningfully lower barrier than adopting a new product.
What Cloudflare announced
Cloudflare announced the Monetization Gateway on 1 July 2026: sellers write payment rules using expressions similar to existing WAF and rate-limiting rules, enforced across Cloudflare's global network. The model is familiar to anyone who has written a Cloudflare firewall expression.
It has not shipped. Cloudflare's own post directs customers to a waitlist, and pricing, release timing, supported networks and production limits have not been published. Treat the design as informative and the timeline as unknown.
Cloudflare Wallets is the buy side, and it is also not ready
On 4 August 2026 Cloudflare announced Wallets, which addresses the other half of the market. Account Wallets belong to the human who owns the Cloudflare account and can be funded, delegated and drawn back. Virtual Wallets belong to agents, are driven by API keys, and spend only within the limits the Account Wallet owner sets. Cloudflare's worked example is a weekly inference budget per employee.
The same caution applies. An account holder can claim a wallet handle now, but Cloudflare states that the ability to set up and use the wallet to pay for APIs and content is still to come. Cloudflare frames the spending caps as letting people allow agents to act autonomously inside safe limits, which is a budgeting control rather than a security boundary, and it is worth quoting them accurately on that point rather than the stronger claims that appeared in secondary coverage.
Choosing between them today
If the question is where to put a paywall this quarter, the comparison is short: one option is deployable and one is a waitlist. That is not a permanent judgement about either platform, and it will likely be wrong within months, which is exactly why an article on this subject has to date its claims.
If you are already on Cloudflare and unwilling to move, joining the waitlist and building against the protocol directly is reasonable. x402 enforcement does not require either vendor; an origin can return its own 402 and verify payment through a facilitator.
| Dimension | AWS CloudFront | Cloudflare |
|---|---|---|
| Status | Generally available | Monetization Gateway waitlist |
| Announced | Late June 2026 | 1 July 2026 |
| Configuration | Monetize action in WAF Bot Control rules | Payment rules as firewall-style expressions |
| Enforcement point | Edge, before origin | Edge, before origin |
| Settlement | USDC on Base and Solana | Not published |
| Buyer-side product | None announced | Wallets, announced, not yet payable |
| Incremental cost | Standard WAF pricing | Not published |
What edge enforcement does not solve
Putting the wall at the edge answers who may pass. It does not answer what a caller should be charged for a partial result, whether a retried request should be charged twice, or what happens when a paid call returns an error. Those are application questions and they stay at the origin.
Edge enforcement also does not make a price correct. A route can be flawlessly gated and still publish a requirement that disagrees with whatever a catalogue says about it, which is measurable and common.
- Retry semantics: whether a repeated call is a second charge
- Failure semantics: whether an error response is chargeable
- Partial results: how a truncated or empty response is priced
- Refunds and disputes: neither platform defines these
Preparing an endpoint either way
The work that pays off regardless of vendor is protocol hygiene. A requirement must be machine-readable, internally consistent with its protocol version, bound to the requested resource, and carry a usable destination, asset, network and timeout. A tolerant client hiding a malformed requirement today becomes a failed integration when a stricter buyer arrives.
Publishing discoverable metadata is the other half. An endpoint that gates correctly but appears in no catalogue is only reachable by buyers who already knew about it, which defeats the purpose of an open payment standard.
How to read announcements in this space
Announcements in agent payments have been running ahead of availability across the board, and coverage rarely distinguishes the two. The useful discipline is to check the vendor's own words for a shipping verb before planning around a capability.
Claims here reflect first-party sources as of 5 August 2026: the AWS availability status from reporting on the CloudFront and WAF Bot Control release, and the Cloudflare statuses from Cloudflare's own Monetization Gateway and Wallets posts. Any of these could change without this article changing, so re-check before committing a roadmap.
Related directory entries
Sources and methodology
TOLL·402 distinguishes public claims, registry discovery, unpaid quote checks and settled paid-call verification. Sources below support the visible claims; presence in a registry is not treated as verification.
- Cloudflare: Monetization Gateway — First-party announcement; states the waitlist is open.
- Cloudflare: Announcing Cloudflare Wallets — First-party buyer-side announcement, 4 August 2026.
- InfoQ: Cloudflare and AWS embed x402 at the edge — Reports the AWS CloudFront and WAF Bot Control availability and ordering.
- x402 protocol documentation — Network and asset support relevant to either enforcement point.