Amazon Bedrock AgentCore names five official use cases for Payments: research, financial analysis, pay-per-inference, on-demand storage, and — quoted with a named customer — browser agents. Anchor Browser, a cloud browser-automation platform, integrated AgentCore Payments specifically to unlock paywalled web content for its customers' agentic workflows.
That combination — a real, isolated Browser Tool session driving through an actual 402 paywall — surfaces a protocol detail most payment paths never hit: a browser doesn't see what a script does.
The flow
sequenceDiagram
participant B as AgentCore Browser (Playwright/CDP)
participant S as Paywalled site
participant AC as AgentCore Payments
B->>S: navigate
S-->>B: 402 + @x402/paywall HTML widget
B->>B: read data-requirements DOM attribute
B->>AC: ProcessPayment(challenge)
AC-->>B: signed proof
B->>S: re-navigate, proof injected via route interception
S-->>B: 200 OK
The documented pattern uses Playwright connected to a managed Browser Tool session over Chrome DevTools Protocol, with Playwright's response interception catching a 402 mid-navigation:
from bedrock_agentcore.tools.browser_client import browser_session
from playwright.sync_api import sync_playwright
with browser_session(REGION) as client:
ws_url, ws_headers = client.generate_ws_headers()
with sync_playwright() as p:
browser = p.chromium.connect_over_cdp(ws_url, headers=ws_headers)
page = browser.contexts[0].new_page()
response = page.goto(paid_url) # 402 on first navigation
The wrinkle: two different 402s
Here's the part that isn't written down anywhere. A script's 402 comes back as JSON with a PAYMENT-REQUIRED header holding the base64-encoded challenge. Point a real browser (Chromium's Accept: text/html) at the same URL, and the server returns something else entirely: a human-facing @x402/paywall HTML page, no PAYMENT-REQUIRED header at all, with the identical challenge JSON embedded in a widget instead:
<div id="payment-widget"
data-requirements='{"x402Version":2,"accepts":[{"scheme":"exact",
"network":"eip155:84532","amount":"2000","payTo":"0x...","asset":"0x..."}]}'>
<!-- Install @x402/paywall for full wallet integration -->
</div>
That's the standard @x402/paywall convention — the same challenge, rendered for a human wallet-connect UI, but just as readable by an automated browser:
raw = page.eval_on_selector(
"#payment-widget", "el => el.getAttribute('data-requirements')",
)
requirement = json.loads(raw)
Once the challenge is read from the DOM instead of a header, everything downstream is identical: ProcessPayment generates a real proof, Playwright's route interception injects it into the retry, and the re-navigation settles to 200:
def add_payment_header(route, request):
route.continue_(headers={**request.headers, **payment_headers})
page.route(paid_url, add_payment_header)
retry = page.goto(paid_url) # 200
Why this matters
Every other payment path in AgentCore — a script, a Lambda, a backend service — talks to a merchant as a machine. Browser agents talk to the same merchant the way a human would. The target site was built for human traffic and gates agent access the same way it gates a browser without an active subscription. The paywall doesn't know or care that a script is driving the Chromium under the hood. It serves the human-facing challenge either way, and the agent has to be able to read it.
That's the actual shape of the "browser agents" use case: not a new payment mechanism, but the same ProcessPayment primitive plugged into a client that has to speak the paywall's native language — HTML and DOM, not headers and JSON — before it can pay at all.
For anyone building this: the gap isn't in AgentCore Payments. It's in knowing that the same endpoint returns different response shapes based on what User-Agent and Accept headers the request carries. A script gets the header-based challenge. A browser gets the widget. If you're working with the managed Browser Tool through a paywall, you need to handle both, or at minimum understand that the browser path requires DOM extraction instead of header parsing.
What's missing
Browsers drive the unscripted web — portals, JavaScript-rendered content, interaction-gated resources — but they're only half the story. Most of these paywalled portals still have API endpoints that prefer a script path, and the cleaner play, where available, is usually to find the native API. The real complexity emerges when a portal only surfaces data through the browser UI, forcing the agent to navigate like a user. Paywalls add another layer: they're not guarding the browser itself; they're guarding specific resources behind the browser. Understanding when a paywall applies to the browser path vs. the API path, and whether the managed Browser Tool or a native API fetch is the right reach, is the decision tree most projects face first.
The one thing AgentCore Payments doesn't clarify in the docs (and that teams building this pattern hit immediately) is exactly this: how to detect which challenge shape you're getting, and how the managed browser's isolation plays with credential caching across sessions. That's the open thread for the next builder who runs this live.
