AWS WAF AI Traffic Monetization - Returning HTTP 402, and What It Puts on the Request Path

First Published: 2026-09-15
Last Updated: 2026-09-15

Once you have Bot Control in place and can see the breakdown of AI bots, the next decision has the same shape every time: block, or allow. Neither option settles the matter. Blocking also cuts off the citations. Allowing only adds to the cost of serving the traffic.

AWS WAF AI traffic monetization introduces a third option: only allowing requests that have paid. However, understanding this feature fully requires a deeper look. The crucial point is not the ability to set prices, but rather that payment verification and settlement both run synchronously inside a single request. The agent is waiting. So is the origin. A round trip to an outside payment service sits in between.

This article will explore what this single point forces upon the publisher. What appears along the way is one rule action, eight stages, three kinds of failure, and four clauses of the Service Terms that the developer guide does not carry.

About Scope. This article is about how AWS WAF implements the merchant side. The x402 and Machine Payments Protocol specifications themselves, how the paying agent is given a budget, and the responsibilities a merchant carries in general are the subject of the published Agentic Payments on AWS, and this article does not repeat them. The history of AWS WAF and the background of Bot Control are in AWS History and Timeline regarding AWS WAF. Declarative mechanisms such as robots.txt and Content Signals, and why they stop short of enforcement, are covered in Designing Websites for AI Agents. How to write AWS WAF rules that protect generative AI endpoints is covered by AWS WAF for Generative AI, and the map of the whole defensive stack by AI Agent Defense in Depth Model. Where a web ACL sits on the request path, and the fact that the console name for it is changing, belong to AWS Network and Application Protection Decision Guide. What price to set is outside the scope of this article. It touches none of the following: a specific amount, the value of a currency, a revenue projection, or the cost of using AWS WAF itself. The approval that sits in front of an agent or a tool being discovered is the subject of another article in this series, AWS Agent Registry and the Agentic Resource Discovery Specification. How far an agent running inside your own account is allowed to go is the subject of a third, AWS DevOps Agent.

Terminology. In this article, the term "web ACL" is used to refer to a single resource that bundles AWS WAF rules. The new console is beginning to refer to this as a "protection pack," but the API resource name remains unchanged. "Publisher" refers to the entity that charges, or the provider. "Merchant" is a term used in previous publications to refer to the entity that receives payments; in this article, it is used only when referring to those previous publications. "Facilitator" is an AWS term referring to a third-party service that finalizes payments on a blockchain.

About the verification date. Everything this article says about availability, default values, valid values, and the spelling of identifiers was checked against primary sources on September 14, 2026. The AWS Service Terms were read in the version current on that same date. Terms get revised. The set of payment networks on offer can grow or shrink. Anything a primary source writes in the future tense is quoted here in the future tense.

1. Between Blocking and Allowing
2. HTTP 402 Is a Rule Action
3. One Request, Two Round Trips
4. What Being Synchronous Costs
5. Where a Failure Happens, and What Comes Back
6. The Unit of Configuration
7. Classification Has to Come First
8. What AWS Does Not Take On
9. The Price Travels, the Terms Do Not
10. What Gets Recorded
11. Where the Primary Sources Disagree with Each Other
12. Failure Modes and Anti-Patterns
13. Frequently Asked Questions
14. Summary
15. References

1. Between Blocking and Allowing

1.1 The questions this article answers

Those responsible for delivering content through CloudFront who are now seeing an unignorable proportion of requests from AI crawlers have two questions.

First, once you take the option of charging rather than blocking, what gets added to your own request path? Is it one more rule, or does the character of your response times change?

Second, if the payment fails, does the content go out anyway? If this is unclear, it becomes impossible to apply these measures to live traffic.

AWS WAF answers both, not as a feature but as a structure of evaluation. Regarding the first question, because verification and settlement join the request path, the character of your response times changes. On the second, a request that does not complete the payment is blocked. Both of these are explicitly stated in the developer guide and API reference, leaving no room for speculation.

However, the implications that arise from these two answers are more complex. There are three kinds of failure, and in exactly one of them the publisher has already spent the origin's work before the failure lands. The middle of this article is about that one.

1.2 Where this article stops

This article will not address topics such as pricing design, revenue projections, or estimates of AI bot traffic ratios. It will also not cover the differences in the x402 scheme, the headers of the Machine Payments Protocol, or how the payer's budget is structured. The scope note at the top lists what this article defers to instead.

The published Agentic Payments on AWS devotes a section to what the side returning the HTTP 402 generally takes on. This article will not rewrite that list. What it looks at is how much of that AWS WAF carries on the request path, and where the line falls that leaves the rest with the publisher. Sections 8 and 9 hold what remains.

There is one more thing this article keeps apart. On this feature, the developer guide and the AWS News Blog say different things about the same subject in more than one place. Cite only one of them and the article reads naturally either way. Section 11 lays out six of those disagreements and states which side this article took, and why.

1.3 How the facts were established

This article cross-references three primary sources: the "AI traffic monetization" and "rule actions" sections of the AWS WAF Developer Guide, the AWS WAF API Reference and CloudFormation Template Reference, and announcements from the AWS News Blog and What's New. For the boundaries the developer guide does not describe, this article consulted the AWS Service Terms. Using the Service Terms as a reference is a first for this series of articles.

Statements describing limitations are considered the most precise, while those conveying functionality are the least precise. That order held in this article's own cross-referencing. This article took numbers and valid values from the API reference, procedures from the developer guide, and announcements of availability from the AWS News Blog and What's New.

2. HTTP 402 Is a Rule Action

2.1 Where it sits in web ACL evaluation

When a request arrives, AWS WAF evaluates the rules in the web ACL in priority order. Evaluation stops at the first rule that matches and carries a terminating action. This is not something AI traffic monetization changed. It is the evaluation order AWS WAF has always had.

What AI traffic monetization added is one more action to choose from inside that evaluation. This new action, called "Monetize," returns an HTTP 402 Payment Required response to matched requests. The developer guide's page on rule actions lists Allow, Block, Count, CAPTCHA, and Challenge, followed by a separate section dedicated to "Monetize." The pricing configuration page, in contrast, lists these six options as a single, unified list.

2.2 What terminating means here

Monetize is a terminating action. The API reference states the conclusion outright.

This is a terminating action-if the client does not complete the 402 payment flow, the request is blocked.

This single sentence serves as the starting point for this article. An HTTP 402 is an invitation to pay, but in the sense that evaluation ends there, it stands on the same side as Block. The request will not proceed unless the payment transaction is completed. The pricing configuration page of the developer guide also states the same concept, albeit in different words.

Monetize – A terminating action. When a rule with the Monetize action matches, AWS WAF stops evaluating
subsequent rules. If the request does not include a valid payment authorization, AWS WAF returns an HTTP 402
response directly and the request is blocked.

Being a terminating action has two design implications. First, any rules placed after the Monetize rule will not be evaluated for requests that match. Second, if a terminating rule is placed before the Monetize rule, the evaluation will conclude there. Section 7 takes up the second one. The first is visible in the order of the rules you wrote. The second surfaces only as a monetization rule that never fires, which makes it easy to miss.

2.3 The places it can be used are fixed

Monetize carries three constraints on where and how it can be used. The API reference states the following:

This action is available only for web ACLs associated with Amazon CloudFront distributions.
You must configure a MonetizationConfig on the web ACL or rule group before adding rules that use this action.
You cannot use the Monetize action for rate-based rules.

First, it can only be used with web ACLs associated with CloudFront. The AWS News Blog describes this same limitation by stating that it does not support adding Monetize rules to regional web ACLs. Since Application Load Balancers and Amazon API Gateway are regional resources, you cannot select it within web ACLs that protect these resources.

Second, the settings that say where payments go have to exist before you add a rule that uses Monetize. A rule without that configuration is not valid.

Third, Monetize cannot be the action of a rate-based rule. A setting that charges clients once they exceed a given rate is not available in that form. Limiting by rate and charging are written as separate rules.

2.4 Not a payment entry point, but an access control branch

In summary, Monetize is not an entry point for payment; rather, it is a branch inside web ACL evaluation. Whether a request passes or not falls out of that branch. Payment is a condition for passing through this branching point, not the branching point itself.

Taking this perspective, the behavior described in the subsequent sections becomes clear. A request that fails verification receives a 402 response because it did not meet the required conditions. Similarly, a request that fails payment also receives a 402 response for the same reason. In both cases, it's not a monetization failure, but rather the result of the access control assessment failing.

3. One Request, Two Round Trips

3.1 Eight stages

The developer guide sets out the request lifecycle for a monetized resource in eight stages. What follows is a summary of what each stage does, not a verbatim quotation.

Stage	Name	What Happens
1	Request	The client sends a request to a protected resource on CloudFront.
2	Rule evaluation	AWS WAF evaluates the rules in priority order. If a Monetize rule matches and no valid payment authorization is present, it returns an HTTP 402 response.
3	Payment Required Challenge	AWS WAF returns an HTTP 402 response carrying the payment instructions.
4	Payment authorization	The client signs, and resends the original request with the signature attached.
5	Verification	AWS WAF verifies the payment credentials.
6	Content fetch	On successful verification, fetching the content is allowed.
7	Settlement	If the origin succeeded, the payment is settled on the blockchain.
8	Response	The content is returned to the client with a response header attached.

What matters here is that these eight stages are two round trips, not one request. Stages 1 through 3 constitute the first round trip, and at this point, no content is returned. Stages 4 through 8 represent the second round trip, where the client resends the same request with a signature.

3.2 The same path as a diagram

Where Verification and Settlement Sit on the Request Path

The band drawn around stages 5 through 7 is the center of this article. All three run while the client is waiting for a response. Nothing reaches the origin until verification is complete. Nothing is returned to the client until settlement is confirmed.

3.3 What rides on the HTTP 402

The developer guide lists five items included in the HTTP 402 response returned in stage 3: the price per request, the accepted payment networks, the publisher wallet address, the maximum timeout, and the payment scheme. The developer guide collectively refers to these as "payment instructions."

The assumption underlying this system is that the response is machine-readable. The client is not a person, but rather an agent's execution environment, which reads the response, creates a signature, and resends it. Conversely, for a client that cannot read this, an HTTP 402 response simply indicates that the request was unsuccessful. The failures discussed in Section 7 stem from this limitation.

3.4 What the resubmission carries, and what success returns

The client includes the signed authorization in the payment-signature request header and resends the original request as is. AWS WAF examines this header and moves on to the verification in stage 5.

If every stage succeeds, AWS WAF returns the content with a response header called payment-response attached. This header contains confirmation that the payment has been finalized. From the publisher's side, those two header names are what the arrangement shows on the request path. The AWS News Blog states that this requires neither a change to the origin infrastructure nor application code. AWS WAF attaches and reads the headers.

4. What Being Synchronous Costs

4.1 Verification and settlement both sit on the request path

The developer guide explicitly states that stages 5 and 7 are synchronous.

Verification – AWS WAF verifies the payment credentials, confirming transfer of sufficient funds and valid
authorization. This occurs synchronously in the request path. If the verification fails, the client is served
a 402 and the content is not served.

Settlement – If content fetch is successful (2xx status code), the payment is settled on the blockchain via
Coinbase Developer Platform's x402 facilitator service. Settlement occurs synchronously – content is served
after confirmed payment. If the payment settlement fails, the client is served a 402 and the content is not
served.

The description for stage 7 clarifies that settlement is not an asynchronous follow-up process. Content is returned only after the settlement is confirmed. It means that an on-chain confirmation now sits inside the time it takes to serve the response.

4.2 Only requests that attempt a payment pay the latency

The developer guide gives both the size of the delay and its scope in the same paragraph.

AI traffic monetization adds several seconds of additional latency to requests that require payment processing.
This overhead covers payment authorization verification and on-chain settlement. The additional latency applies
only to requests where a transaction is being attempted – requests that do not match the Monetize action or
requests without a payment signature attached are unaffected.

The latter limitation is crucial. This delay does not apply to requests that do not match the Monetize rule, nor does it apply to requests that are not associated with a payment signature. It does not apply to a request without a signature because that round trip ends at stages 2 and 3. This means the first round trip is fast, while the second round trip is slower.

For the publisher running the service, this turns the response-time distribution of a monetized path into two peaks. One peak is the round trip that only returns a 402. The other is the round trip that runs all the way through settlement. If existing dashboards only display averages, this bimodality will appear as an increase in the average response time.

4.3 An outside facilitator becomes part of your response time

The same page also states that how large the delay gets is not decided by anything on your side.

The exact latency depends on blockchain network conditions at the time of settlement.

Settlement runs through the x402 facilitator of the Coinbase Developer Platform. Therefore, the response time for a monetized path includes factors outside of your control, such as a service you do not operate and the state of a network you do not manage. This also creates a dependency on availability. The developer guide lists potential reasons for settlement failures, including temporary unavailability of the facilitator, blockchain congestion, and transient errors during confirmation.

The payment instructions returned in stage 3 carry a maximum timeout. The developer guide does not explain what that value bounds. It does not state that the value guarantees how long settlement itself takes.

5. Where a Failure Happens, and What Comes Back

5.1 Three kinds of failure

Failures fall into three kinds: verification, origin, and settlement. The developer guide writes about these three in separate sentences.

When a verification failure occurs, the client receives a 402 response and no content is returned. Similarly, when a settlement failure occurs, the client receives a 402 response and no content is returned. Up to this point, the behavior is the same.

The handling of origin failures differs.

No payment for failed origins – If origin returns 4xx or 5xx, settlement is skipped and the client is not charged.

That sentence states that settlement is skipped. It does not state what the client receives. It does not state that the failure response from the origin is directly returned. This article does not go beyond what AWS has stated regarding this particular point.

5.2 The same split as a diagram

Where a Failure Lands, and How Far the Request Already Got

The second column of the diagram carries the real difference among the three. In all three, the content is not served and the client is not charged. The difference lies in how far the request had progressed before the failure occurred.

The diagram carries a fourth row as well, for the case where AWS throttles payment traffic. That runs down a different route from the three above, and Section 5.5 takes it up.

5.3 Only a settlement failure has already spent the origin fetch

Recalling the sequence, settlement happens at stage 7, while retrieval from the origin occurs at stage 6. Therefore, at the moment settlement fails, the origin has already been contacted and returned a 2xx status code.

This combination is the most disadvantageous for the publisher. If verification fails, the request never reaches the origin, so there's no unnecessary load. If the origin fails, the origin never succeeded to begin with. Settlement failure is the only one of the three where the origin's work finishes, the content still does not go out, and the client is still not charged.

This outcome is not documented in any primary source material. It is derived from two statements: the sequence of stages and the behavior in case of failure. The basis for this interpretation lies in the conditional statements within stages 6 and 7; AWS does not explicitly state this.

5.4 Retries and double payment

When a client resends the same request, there's a potential issue of being charged twice. The developer guide outlines two mechanisms to address this.

One is idempotency. The payment-identifier extension of the x402 protocol lets clients retry payments for up to 15 minutes without the risk of double charging. However, the developer guide specifies a condition: this functionality only works when the client utilizes this extension. It is not something the publisher can configure or enable.

The second mechanism is preventing resends. Payment authorizations are only valid once. Reuse the same payment header without a valid payment-identifier, and AWS WAF returns a new 402.

From the publisher's perspective, these two mechanisms are complementary. While header reuse is prevented, whether a legitimate retry ends in double charging depends on the client's implementation.

5.5 Throttling on the AWS side

The developer guide also states that payment traffic can be throttled on the AWS side.

Additionally, AWS might throttle excessively high volumes of payment traffic to protect the integrity of the
payment processing infrastructure and prevent abuse. If throttled, payment requests receive an error response
and should be retried after a brief backoff. Normal request volumes are not affected by throttling.

It states that normal request volumes are not affected. It does not state where normal ends. The Service Terms put the same idea more broadly, and Section 8 takes that up.

6. The Unit of Configuration

6.1 The configuration unit is the web ACL

The settings that decide how you receive payments are called MonetizationConfig, and they live on the web ACL. The API reference describes it as follows:

The monetization configuration for a web ACL or rule group. Specifies the cryptocurrency payment networks and
currency mode for AI bot monetization. You must provide this configuration when any rule in the web ACL or
rule group uses the Monetize action.

The new AWS WAF console has begun referring to web ACLs as "protection packs," and many pages in the developer guide now use language that combines both terms. However, the resource names in the API have not changed. While the published AWS Network and Application Protection Decision Guide addresses this terminology change, this article will use the term "web ACL" to align with the API. There are places in the AWS News Blog that treat the two as different things, and Section 11 takes those up.

6.2 The shape of MonetizationConfig

This configuration consists of two items: currency mode and cryptocurrency receiving settings. The receiving settings further include an array of payment networks.

Level	Field	Required	Description
MonetizationConfig	CurrencyMode	Optional	Selects whether to use production currency or test currency.
MonetizationConfig	CryptoConfig	Optional	Contains the receiving settings.
CryptoConfig	PaymentNetworks	Required	An array of payment networks. Must contain between one and two entries.
PaymentNetwork	Chain	Required	Specifies the blockchain.
PaymentNetwork	WalletAddress	Required	The address to receive payments.
PaymentNetwork	Prices	Required	Price settings. The array must contain exactly one entry.

The valid values for Chain are four in total: two for production networks and two for test networks. The API reference requires every network in the array to sit in the same environment, either all production or all test. It is not possible to create a configuration that mixes production and test networks.

Prices is an array, but the number of elements is fixed at one. This means that for each network, there is only one price. This article does not deal with the price amount itself, so it stops at that level of detail.

The WalletAddress field includes a validation check. For EVM addresses, AWS WAF runs a checksum validation when the address mixes uppercase and lowercase letters. It catches typos. Write the address entirely in lowercase or entirely in uppercase and AWS WAF skips the check.

6.3 The only parameter the Monetize action takes

The only parameter the Monetize action accepts is PriceMultiplier, a multiplier against the baseline price held on the web ACL.

Valid values are integers between 1 and 100, and must be provided as a string. If omitted, the default value is 1. The multiplier is therefore the only value a rule changes. The baseline price does not live in the rules. It lives in the payment network settings. If you want to apply different prices based on the path or bot type, you will need to create separate rules and adjust the multiplier for each.

This structure splits price configuration into two tiers: the payment network settings hold the baseline price, and the rule holds the multiplier. Because the smallest valid multiplier is 1, a rule cannot produce a price below the baseline.

6.4 REAL, TEST, and the default

CurrencyMode has two valid values: REAL, which settles on the production networks, and TEST, which settles on the test networks. Tokens on the test network do not have any monetary value.

This field carries a default that is easy to step on. The API reference states the following:

Specifies whether the configuration uses real or test currency. Set to REAL to settle payments in USDC on
production blockchain networks (Base, Solana). Set to TEST to settle on testnet networks (Base Sepolia,
Solana Devnet) with tokens that have no monetary value. If not specified, defaults to REAL.

If not specified, the production environment is the default. If you want to start with the test environment, you must explicitly set it to TEST. Leaving it out is not a way of not choosing test. It is a way of choosing production.

In test mode, the payment flow is executed in the same way as it is in the production environment. The developer guide states that verification, the origin fetch, and settlement all run on the test blockchain in exactly the same way as they do in the production environment. This is not a mode where payments are waived. A client with no funds on the test network does not get through.

This setting takes effect on a web ACL basis. It is not possible to configure only certain rules to use the test environment within a single web ACL.

7. Classification Has to Come First

7.1 The Monetize action does not decide what is a bot

Monetize is simply an action that returns a 402 response to a matching request. The rules themselves determine what constitutes a match. Both examples provided in the developer guide are based on matching labels assigned by Bot Control. One label indicates unverified bots, while the other applies to bots in general.

The action itself therefore does not know whether the caller is a bot. Something upstream decides that, and the monetization rule then acts on the result. Two steps, in that order.

7.2 When it hits a human client, it is a block

What happens when that two-step structure is broken? The developer guide warns about it by name.

The Monetize action is designed for automated AI agent traffic. When a request matches a Monetize rule, AWS WAF
returns an HTTP 402 Payment Required response containing machine-readable payment instructions in the x402
protocol format. Standard web browsers and human users cannot interpret or complete this payment flow – the 402
response will effectively block access for non-automated clients.

An ordinary browser cannot interpret the x402 payment flow. So the moment a Monetize rule matches a human client, it is not a charge. It is a block. And because Monetize is a terminating action, as Section 2 showed, a rule placed after it as a fallback is never evaluated.

The developer guide's remedy is to combine the rule with Bot Control labels so that only bot traffic receives the 402. A request that carries no label does not match that rule and moves on to the rules after it.

7.3 If Bot Control blocks first, the Monetize rule is never reached

There is a failure that runs the other way. The Bot Control managed rule group contains category-specific rules, and its action is to Block any unverified bots. The rule listing in the developer guide repeats the same single line for each category, among them advertising, archiving, content fetching, scraping frameworks, and search engines.

Rule action, applied only to unverified bots: Block

The same page notes that this listing describes the most recent static version of the managed rule group. Since versions are updated, the list itself may change.

Block is a terminating action. AWS WAF evaluates the managed rule group as a rule inside the web ACL, so when a rule inside it returns a terminating action, web ACL evaluation ends there. Even if you place a Monetize rule behind it, if Bot Control intercepts the request first, that rule will not be reached.

This conflict is limited to unverified bots. The same listing states that for verified bots the rules do not match and take no action, and that the rule group only adds a label. However, the monetization examples provided in the developer guide specifically target unverified bots. The most natural starting point is therefore the combination that collides.

AWS WAF provides a mechanism to override the actions of individual rules within a rule group. The developer guide states that AWS WAF handles a request matching an overridden rule exactly as if the configured action had been the rule's own. Overriding a rule to Count is not terminating, so the evaluation continues to subsequent rules.

This combination is precisely the type explicitly described on the developer guide's label explanation page.

Many managed rule group rules add labels to matching web requests, to indicate the rules that matched and
possibly to provide additional information about the match. When you use a rule group that adds labels to
requests, you can override the rule group rules to count matches, and then run a rule after the rule group
that handles the web request based on the rule group labels.

In other words, the configuration where you override a rule to Count and then place a rule that uses labels to make a decision is a pattern demonstrated by AWS itself. The monetization rule is the rule you place afterward.

7.4 AWS states that the classification is probabilistic

There is one more property of this two-step structure. The developer guide places the same note on two separate pages.

To implement your AI traffic monetization policies, we use multiple detection techniques such as behavioral
signals and risk-based systems to inspect and categorize inbound traffic. While these methods are designed to
provide high-confidence classification, they are probabilistic and might not correctly identify or categorize
all bot traffic in all cases.

The guide states that the classification is probabilistic. And a classification error cuts both ways. If a bot is missed, it will pass without being charged. Classify something that is not a bot as one, and the previous section applies: it is blocked. Immediately after that note, the developer guide recommends confirming the results in test mode before turning monetization on in production.

7.5 Recommended, or required

Here, the primary sources diverge. The introduction page of the developer guide lists Bot Control as the third of its prerequisites, and marks that one item in parentheses as recommended.

(Recommended) AWS WAF Bot Control enabled to classify AI bot traffic by identity

In contrast, the AWS News Blog states the same thing as a confirmation requirement.

Before configuring monetization, confirm that AWS WAF Bot Control is enabled at Common or Targeted level on the
web ACL associated with your CloudFront distribution. Bot Control provides the agent classification that
monetization rules depend on.

One reading fits both: recommended in form, required in practice. Bot Control is not a strict requirement as an API constraint, so it's possible to create Monetize rules that match other conditions besides the label. However, as seen in the previous sections, returning a 402 without classification will block human clients. Bot Control has two protection levels: Common and Targeted, and the blog asks for one of the two.

8. What AWS Does Not Take On

8.1 Three negations, three different statements

The developer guide explains how settlement works. What position AWS holds inside it, the AWS Service Terms define. Section 109 of the Service Terms covers AI traffic monetization, and its first clause reads:

AWS WAF AI traffic monetization helps you charge buyers (“Buyers”) for access to the Content you serve via AWS
Services (such as Amazon CloudFront), by transmitting messages between you, Buyers, your respective wallet and
payment providers (“Payment Providers”), and third-party facilitation services (“Facilitators”). AWS does not
provide regulated financial services as part of AWS WAF AI traffic monetization. AWS is not a party to, or in
the flow of funds for any payment you receive.

The second clause continues:

AWS does not have custody or control over, and is not responsible for any wallets, funds, or digital assets
used in connection with AWS WAF AI traffic monetization.

Here, three distinct negations about AWS's position in the payment are present. They state that AWS is not a party to the payment, is not in the flow of funds, and has neither custody nor control over any wallets, funds, or digital assets. A fourth negation, stating that AWS is not responsible, is also layered on top. They look like one statement folded up. They are not.

What AWS does, in the wording of the clause, is relay messages. It transmits pricing, payment, and configuration information to the buyer, the payment provider, and the facilitator. Separate agreements between the publisher and those parties govern the publisher's relationship with the payment provider and the facilitator. The payment networks and settlement page of the developer guide puts the same point briefly, stating outright that you agree to Coinbase's terms of service.

8.2 The facilitator can change

The fourth clause carries two statements. The first reads:

AWS may change or discontinue support for any Payment Provider or Facilitator at any time. We will provide you
with prior notice if we discontinue support of a Payment Provider or Facilitator where practicable under the
circumstances.

The notice is conditional. It arrives where the circumstances make it practicable. Settlement today runs through a single facilitator, the x402 facilitator of the Coinbase Developer Platform, and the developer guide names it.

None of this is in the developer guide. The guide describes the arrangement as it stands, and does not say that the arrangement can change.

8.3 Limits can be placed on the volume processed

The second statement in the same clause reads:

AWS may impose limits on the amount of traffic processed by AWS WAF AI traffic monetization at any time.

As Section 5.5 showed, the throttling passage carried both a purpose, protecting the integrity of the payment processing infrastructure, and a caveat that normal volumes are not affected. The Service Terms carry no such caveat. They state only that the volume processed may be limited.

The sound design on the publisher's side treats a monetized path as one that carries no service-quality guarantee. What you return when monetization stops is yours to decide in advance.

8.4 The obligations left with the publisher

The third clause lists three things the publisher does. They are testing, monitoring, and implementing safeguards as the use case warrants. The clause offers human-in-the-loop as the example of a safeguard. The clause then names two ways of doing that: managing and securing the wallet, and making sure the access, pricing, licensing, and payment configurations are accurate and authorized.

You will test, monitor, and implement safeguards (such as human-in-the-loop) for your use of AWS WAF AI traffic
monetization as may be appropriate for your use case, including by managing and securing your wallet, and
ensuring your access, pricing, licensing and payment configurations are accurate and authorized.

The last item in that list is licensing. Alongside the access, pricing, and payment configurations, the publisher owns getting the licensing configuration right. The following section will address where these licensing settings are actually located.

9. The Price Travels, the Terms Do Not

9.1 What the HTTP 402 does not say

The developer guide includes a single page at the end of the chapter on AI traffic monetization, setting out what this feature does not convey.

AI traffic monetization tells agents how much to pay but not what they're allowed to do with the content.

Payment instructions indicate how much should be paid. They do not say whether the buyer may use what it fetched for training, whether it may summarize and redistribute it, or whether it may store it. A successful HTTP 402 exchange signifies an agreement on price, not an agreement on terms of use.

This is directly related to the obligations outlined in Section 8. While it is the publisher's responsibility to ensure that the license terms are correctly set, the monetization mechanism itself does not transmit those terms.

9.2 RSL, a separate channel

The developer guide proposes RSL as a method. It stands for "Really Simple Licensing" and is a publicly available standard for machine-readable licenses. The developer guide lists four potential paths for agents to find these conditions.

Path	Location	Notes
robots.txt	Add RSL directives to an existing robots.txt.	Discovered during the crawl preflight.
HTTP Link header	Inject a header in the response that references the license URL.	Can be configured with a CloudFront response header policy.
HTML link element	Embed an element in the page that carries the license relation.	Not applicable to API or non-HTML responses.
RSS and Atom modules	Attach license information to each item in the feed.	Suited to delivery through feeds.

The published Designing Websites for AI Agents already covers why the robots.txt route is a request rather than enforcement. This article will not reiterate that discussion. The key distinction to remember is this: pricing is enforced at the edge, while conditions are only declared.

9.3 The 402 response does not carry that Link header

The developer guide attaches a note to the route that uses a CloudFront response header policy.

CloudFront Response Header Policies apply to responses served from origin. The 402 Payment Required Challenge
served by the Monetize action will not include this header.

Response header policies only apply to responses originating from the origin server; they do not affect 402 responses directly returned by AWS WAF. Consequently, agents are unable to receive license references before completing payment. They only receive these references after a successful payment and content delivery.

In order, then, the payment comes before the agent learns the terms. Put together with Section 9.1, what this feature conveys is the price and nothing else, and every route that shows the terms first sits outside the monetization flow.

10. What Gets Recorded

10.1 Verification resolves into five outcomes

With AWS WAF logging turned on, monetization events carry extra fields. The table in the developer guide lists eleven fields, one of which is the WAF action taken on the request. The remaining ten fields are specific to monetization and carry the verification result, reasons for failure, the chain used, network identifiers, amount, currency, asset, payer address, idempotency key, and currency mode.

The values recorded as verification results fall into five categories: a successful verification, insufficient funds, invalid payload, invalid payment requirements, and service-side error.

These five distinctions have different operational implications. Insufficient funds indicate a client-side issue, while an invalid payload points to a problem with the client's implementation. A service-side error belongs to neither the client nor the publisher. Counting only the total number of failures collapses those three into one number.

10.2 Settlement resolves into five outcomes as well

Each settlement is available as an individual record. The developer guide lists ListSettlementRecords as the operation that returns this list. The records have five possible statuses: settled, pending, failed, service error, and skipped due to an origin error.

The last of those values is the branch from Section 5 showing up directly in the record. When a transaction is not processed due to an origin failure, it is recorded as "skipped" rather than "failed." The meaning of the failure rate figures can change depending on whether this "skipped" status is included in the calculation.

The records carry a currency mode filter. By default, only transactions using the production currency are displayed. When testing, you will need to explicitly specify the filter criteria to view the results.

10.3 There are two metrics

CloudWatch carries two metrics. AWS WAF emits the first when the terminating rule's action was Monetize. It emits the second when that holds and the verification result was not a success.

These two count matches and verification failures. They do not count success or failure through settlement. Success or failure through settlement lives in the settlement records from the previous section. Monitoring built on these metrics alone never shows the request that reached the origin and then failed at settlement.

Monetize is counted as a metric separate from Block and Allow. If existing dashboards are built around Block and Allow, monetized requests will not be included in either of them.

11. Where the Primary Sources Disagree with Each Other

What follows is the list of disagreements found during cross-referencing, including the ones raised in individual sections above. Of the six discrepancies found, two could not be confirmed based solely on the primary sources and remain unverified. These are detailed in sections 11.3 and 11.5.

11.1 Do the license terms ride on the 402

The developer guide states that monetization conveys the price but not the terms of use. Conversely, both "What's New" and the AWS News Blog indicate that license terms are included in the 402 response.

The response contains your prices to access the content, accepted payment methods, and license terms.

License terms do not appear in the developer guide's own list of what the response carries. That list holds five items: the price, the payment networks, the wallet address, the maximum timeout, and the payment scheme. And the same developer guide states that a license reference injected by a response header policy does not ride on the 402.

This article sides with the developer guide's perspective. The reasoning is that descriptions of limitations are more accurate than descriptions of functionality. However, this is the judgment of this article, and not a correction from AWS.

11.2 Where MonetizationConfig belongs

The API reference, CloudFormation template reference, and SDKs for each language all state that this configuration should be placed within either a web ACL or a rule group. Only the developer guide's page on rule actions specifies that it should be placed within a web ACL.

This action is available only for web ACLs associated with Amazon CloudFront distributions and requires a
MonetizationConfig on the web ACL.

The API side is the broader statement. This article takes the API side, and reads the developer guide's sentence as the narrower wording of the same thing.

11.3 The scoped access token

What's New states that AWS WAF issues a token after verification.

The agent presents proof of payment, AWS WAF verifies it at the edge, issues a scoped access token, and serves
the response within a single request cycle.

The developer guide's eight-stage lifecycle does not include a stage for issuing tokens. Following stage five, verification, comes stage six, content retrieval. Neither the API reference nor the log fields carry anything that corresponds to a token.

This article does not carry that statement into its own prose. AWS WAF has a separate token system used by CAPTCHA and Challenge features, so it's possible that the term refers to something else entirely. The primary sources do not settle it, so it stays on the record as unconfirmed.

11.4 What to call the thing on the 402

The developer guide calls it payment instructions. The AWS News Blog and the language SDKs call it a price manifest. Both names point at the same thing. The prose of this article uses the developer guide's name.

11.5 Is a protection pack the same thing as a web ACL

The developer guide consistently uses both terms together, suggesting they refer to the same thing. However, the AWS News Blog uses different wording. It describes creating a protection pack and then associating it with a web ACL, and also states that you can create multiple protection packs for a single distribution.

These two interpretations are incompatible. If they were the same thing, associating one with the other would make no sense. This article adopts the perspective of the developer guide and the API reference, referring to it as a web ACL. Whether the blog is describing a console experience that has not landed yet, or whether a separate component really exists, cannot be settled from the available sources. That stays on the record as unconfirmed.

11.6 Is Bot Control required or recommended

As Section 7.5 set out, the developer guide writes recommended and the blog says to confirm that it is enabled. This article quotes both.

11.7 The rule running through all six

The six break down like this. Four of them are places where the AWS News Blog or What's New claims more than the developer guide does. One is a page in the developer guide that describes a feature more narrowly than the API reference does. The last one is the same content under a different name, with no contradiction in the content itself.

Those two directions are opposite, and one rule runs through all of them. Text written to describe a constraint is the most accurate. Text written to convey a feature is the coarsest. Take numbers and valid values to the API reference, procedures and limits to the developer guide, and announcements of availability to the blog.

12. Failure Modes and Anti-Patterns

12.1 Design failures

Designing monetization as a revenue mechanism rather than as access control. Monetize is a terminating action, and a request that does not complete the payment is blocked. Adding this one rule changes the conditions under which the matching traffic gets through at all. First, verify that the blocking rule is correct, and then consider pricing.

Applying Monetize on a rule that carries no classification. If the rule matches on a path alone, a human client reaching that path receives a 402 response. An ordinary browser cannot interpret the payment flow, so the result is a block. Furthermore, because it's a terminating action, any later rule meant to catch it never runs. Ensure that the rule includes a condition to identify bots.

Holding a monetized path to the response-time target you already had. Because verification and settlement sit on the request path, the developer guide notes that payment transactions will add a few seconds to the round trip time. The extent of this delay depends on the status of the blockchain. Give a monetized path its own response-time target.

Leaving the dependency on an outside service out of the design. The payment process relies on a third-party facilitator. The Service Terms state that AWS may change or discontinue support for any payment provider or facilitator at any time. AWS gives prior notice only where the circumstances make that practicable. Decide in advance what you return when monetization stops working.

12.2 Implementation failures

Leaving Bot Control enabled and retaining that block. The per-category rules in Bot Control return Block for unverified bots. Because Block is a terminating action, a Monetize rule placed after it is never reached. A design that matches on labels comes as a pair with overriding the action of the rule that applies them.

Forgetting to set the CurrencyMode. If unspecified, it defaults to the production setting. The configuration, intended to start with a test environment, will instead operate using production currency.

Mistaking the test mode for a mode where payments are waived. Even in test mode, the payment flow operates identically to the production environment. The only differences are which network it runs on and whether the tokens carry monetary value. A client with no funds on the test network does not get through.

Attempting to create prices lower than the baseline using the multiplier. The valid range for PriceMultiplier is an integer between 1 and 100. A rule cannot produce a price below the baseline. A tier you want to let through for free takes Allow, not Monetize.

Reaching for Monetize as the action of a rate-based rule. The API reference prohibits it outright. Limiting by rate and charging are written as separate rules.

Testing with a regional web ACL. Monetize works only on a web ACL associated with CloudFront. It cannot be selected in front of an Application Load Balancer or Amazon API Gateway.

12.3 Operational failures

Counting an origin failure and a settlement failure as the same thing. When the origin fails, settlement is recorded as skipped. When settlement fails, it is recorded as failed. Adding the two together makes an origin outage look like a settlement outage.

Building the monitoring out of metrics alone. CloudWatch carries two numbers: how often Monetize was the terminating action, and how often verification did not pass. An event that got as far as settlement and then failed does not appear there. The settlement side lives in the individual records.

Leaving the dashboard built on two categories, blocked and allowed. Monetize is counted separately from both of them. Existing dashboards do not include monetized requests in either category.

Assuming the license terms are being conveyed. Monetization only communicates pricing information. Presenting the terms of use in a machine-readable form takes a separate mechanism, and even then the reference does not appear in a 402 response.

Reading verification failures as one number. The recorded verification results split into five: insufficient funds, an invalid payload, invalid payment requirements, a service-side error, and success. Adding causes of different origin together leaves nothing to act on.

Designing against payment routes that have not shipped. Integration with Stripe and support for the Machine Payments Protocol are both described as coming soon, in What's New and in the AWS News Blog alike. As of September 14, 2026, that description remains unchanged.

13. Frequently Asked Questions

If the payment fails, does the content still go out?

No. According to the developer guide, if verification fails or settlement fails, a 402 response is returned to the client, and the content is not provided. Settlement is confirmed before the content goes out, so content is never served against an unsettled payment.

If the origin fails, is the client charged?

No. According to the developer guide, if the origin returns a 4xx or 5xx status code, settlement is skipped and the client is not charged. The settlement records carry a dedicated status for a settlement skipped because of an origin error.

How much slower does a monetized path get?

The developer guide states that there may be a delay of a few seconds. The exact length of this delay depends on the state of the blockchain at the time of settlement, and no fixed value is specified. This delay only applies to the round trip involved in processing actual payments. It does not apply to requests that do not match the Monetize rules, or requests that are not signed with a payment signature.

Is Bot Control mandatory?

The primary sources disagree. Inside its list of prerequisites, the developer guide marks Bot Control alone with a parenthetical recommendation. The AWS News Blog, on the other hand, says to confirm that Bot Control is enabled at the Common or the Targeted level. The API does not require it as a constraint. However, applying the Monetize action without a classification in front of it blocks human readers, so in practice, it's reasonable to consider it a prerequisite.

Can this be used in front of an Application Load Balancer?

No. The API reference states that Monetize is only available with web ACLs associated with CloudFront distributions. Additionally, the AWS News Blog indicates that adding Monetize rules to regional web ACLs is not supported.

Can monetization be combined with a rate-based rule?

No. The API reference states outright that Monetize cannot be the action of a rate-based rule. Limiting by rate and charging are written as separate rules.

Can the price be set freely per rule?

No. The baseline price lives in the web ACL configuration, and a rule adjusts only the multiplier. The valid range for the multiplier is an integer from 1 to 100, with a default value of 1. It is not possible to set a price for a rule that is lower than the baseline price.

Does test mode remove the need to pay?

No. According to the developer guide, even in test mode, the payment flow runs exactly as it does in production. The difference is that it uses a test network, and the tokens used within that network do not have any monetary value. The setting takes effect for the whole web ACL, so it is not possible to put only certain rules in test mode.

Does paying give an agent free rein over the content?

No. Monetization states how much to pay and says nothing about what the buyer is allowed to do with the content, as the developer guide states outright. Machine-readable terms of use take a separate mechanism such as RSL. Furthermore, license references injected in the response header are not included in the 402 response returned directly by AWS WAF.

Is AWS a party to the payment?

No. The AWS Service Terms explicitly state that AWS does not provide regulated financial services, is not a party to any payment transactions, is not in the flow of funds, and has neither custody nor control over any wallets, funds, or digital assets. Separate agreements between the publisher and those parties govern that relationship.

Does resubmitting the same request mean paying twice?

It depends. The x402 protocol includes an extension that allows for retries without double charging, for up to 15 minutes, as the developer guide notes. However, this extension only applies if the client is utilizing it; it's not something the publisher configures or enables. And reusing the same payment header without a valid identifier draws a new 402.

14. Summary

At the center of AWS WAF AI traffic monetization is a structure in which payment verification and settlement both run synchronously inside one request. The agent is waiting. By the time settlement begins, the origin has already been called. A round trip to an outside payment service sits in between.

This structure can be read off the fact that Monetize is a terminating action. Requests that fail to complete payment are blocked. So this is not an entry point for payment. It is a branch inside web ACL evaluation.

There are three kinds of failure, and in every one of them the content does not go out and the client is not charged. The difference lies in how far the request progressed before reaching that point. At the moment settlement fails, the origin has already been called and has already finished responding. That one case is where the publisher spends the work up front and gets nothing back.

Two things do not travel through this mechanism. One is the terms of use. The 402 carries the price, and what the buyer is allowed to do with the content is left to a separate mechanism. The other is AWS's own involvement in the settlement. What the Service Terms place there are separate negations: not a party, not in the flow of funds, holding neither custody nor control, and bearing no responsibility.

The price is enforced at the edge. The terms are only declared. The difference between those two properties is what the publisher takes on when it reaches for a third option that is neither blocking nor allowing.

15. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi