Building agents that transact with Anchor Browser and AgentCore payments

AI agents increasingly need to access web resources that are priced per request. For example, premium datasets charge by the query, research APIs meter by the call, and paywalled publishers gate content behind payment. When an AI agent encounters one of these resources, the server returns HTTP 402 Payment Required. The agent has no built-in payment mechanism, no budget attached to the session, and no programmatic way to satisfy the request. The task stalls and requires manual intervention.

Anchor Browser with Agentic Payments handles machine-to-machine payment workflows on behalf of the agent. Developed in collaboration with the AWS Generative AI Innovation Center Partner Agent Factory, it’s now available on AWS Marketplace. This post covers how Anchor Browser integrates with Amazon Bedrock AgentCore payments so that AI agents can pay for x402-protected pages and APIs autonomously. The x402 protocol is an open standard for HTTP-based machine-to-machine payments. A server responds with 402 Payment Required along with the amount, accepted payment methods, and payment address that the agent uses to complete the transaction.

Anchor Browser is a cloud-based browser automation solution purpose-built for AI agents. Each agent session runs inside a managed browser environment that maintains authentication state, handles navigation, captures network requests, and provides a live view of page interactions.

Amazon Bedrock AgentCore provides capabilities to build, connect, and optimize agents at scale. Amazon Bedrock AgentCore payments is a fully managed capability within AgentCore that AI agents can use to discover, access, and pay for APIs, Model Context Protocol (MCP) servers, and web content autonomously. AgentCore payments manages wallet connectivity, enforces configurable spending limits at the infrastructure layer, and processes payments through the x402 protocol. It also provides observability into payment attempts, approvals, denials, and settlements through Amazon CloudWatch.

When an agent running in Anchor Browser encounters a 402 response, AgentCore payments authorizes and completes the transaction within the configured budget. The workflow continues without interruption.

Challenges

When an autonomous agent encounters an x402-protected resource, the workflow stalls. The agent makes a request, such as fetching a premium research report or calling a paid data enrichment API, and the server responds with HTTP 402 Payment Required. Without a mechanism to pay, the task that was supposed to run autonomously now requires human intervention.

Today, developers must build the entire payment stack. This effort spans four categories of complexity:

Payment protocol handling

• Detecting and parsing the 402 challenge from the HTTP response, and distinguishing payment-required responses from other 4xx errors.
• Constructing the correct payment header with the cryptographic proof in the exact format the merchant expects.
• Supporting multiple payment schemes (exact, upto, and protocol variants) without hardcoding vendor-specific logic into the agent.
• Maintaining compatibility across x402 merchant implementations that might vary in challenge format, supported stablecoins, or settlement timing.

Security and key management

• Storing a private key to sign payments, requiring secure key storage within an environment exposed to untrusted inputs.
• Managing wallet lifecycle operations, including key rotation, credential refresh, and provider failover.

Operational resilience

• Resubmitting the original request with the payment header while preserving session state, cookies, and request context.
• Providing idempotency, which is essential for wallet operations.
• Enforcing per-session and per-transaction spend limits with real-time budget tracking across concurrent agent executions.

Observability and compliance

• Capturing every payment attempt, approval, denial, and settlement in audit logs for compliance and reconciliation.

Without a managed payment service, the agent must internalize the entire payment stack. On every x402-protected call that returns a 402 response, the agent must orchestrate the full payment flow internally, including:

• Signing the proof.
• Attaching the correct header.
• Retrying the request.
• Settling the transaction.
• Logging the result.

Each of these steps requires custom code that developers must build, secure, and maintain. Figure 1 illustrates this architecture. The agent contains eight tightly coupled components (Wallet, Private Keys, Budget Controls, Sign Proof, Attach Header, Retry Logic, Settle Payment, and Logging). The agent connects to an x402 API with a 402 challenge flowing back and a retry flowing forward.

The security considerations extend beyond the engineering effort.

Uncontrolled spending. Without hard spending limits enforced at the infrastructure level, a bug, retry loop, prompt injection, or inadvertent access can trigger unintended payments. An agent retrying a paid endpoint in a loop continues to authorize payments until manual intervention occurs.

Key exposure. When private keys reside inside the agent runtime, they share an execution environment with untrusted web pages, third-party tools, and external dependencies. These vectors might inadvertently disclose the credentials that control real funds.

Signing flow exposure. If the signing infrastructure is accessible from the runtime, a threat actor can attempt to access the key or redirect payments to an address under unauthorized control. Effective mitigation requires that the key doesn’t enter the runtime in the first place.

Browser-based agents introduce an additional constraint: the payment must occur within the same browser session. Otherwise, session recordings and live view no longer match what actually executed.

Solution

Anchor Browser and AgentCore payments address this complexity by moving the entire payment stack into managed infrastructure.

Unlike a stateless tool call, Anchor Browser provides a real cloud browser with persistent identity, repeatable and deterministic workflows, and the session context needed to log in, navigate, and finish tasks reliably. Authentication, navigation, network requests, recordings, and live view happen inside the same browser session. When a payment is required, the transaction happens within that session. The recording captures the full sequence from request to 402 to payment to content delivery. Anchor agents include a built-in x402 tool that handles paid API calls natively within the browser context. The built-in tool requires no changes to existing Playwright, Puppeteer, or Chrome DevTools Protocol-based workflows.

AgentCore payments serves as the payment layer. At the center of the service is the Payment Manager, the top-level resource that coordinates payment operations for the AWS account. Creating a Payment Manager requires specifying an authorizer type and an IAM role. AgentCore then provisions a corresponding workload identity in Amazon Bedrock AgentCore Identity.

The remaining components connect the Payment Manager to external wallet infrastructure:

• A PaymentConnector integrates the Payment Manager with an external wallet provider, either Coinbase Developer Platform (Coinbase CDP) or Stripe Privy.
• A PaymentCredentialProvider stores wallet provider credentials securely in AgentCore Identity.
• A PaymentInstrument identifies the specific wallet address from which funds are drawn.

Anchor Browser sets up wallets through AgentCore payments using a supported wallet provider, without placing wallet secrets or private keys inside the agent runtime. AgentCore payments handles wallet operations through the configured provider. For endpoint discovery, AgentCore provides a curated Coinbase x402 Bazaar MCP server through Amazon Bedrock AgentCore Gateway, so agents can discover available pay-per-use x402 endpoints programmatically.

AgentCore payments restructures the payment architecture. Sensitive operations move out of the agent runtime and into a managed service layer. The Anchor Agent holds only two payment-related components: a budget session and the x402 tool. The infrastructure, including authentication, wallet secrets, payment limits, observability, and payment proof signing, resides in the AgentCore payments layer. Figure 2 shows the Anchor Agent connecting to the AgentCore payments managed layer, which handles wallet provider integration with Coinbase CDP or Stripe Privy.

How the payment flow works

The following steps describe what happens end to end, from the moment a browser session encounters an x402-protected resource to the moment the agent receives the response and continues the task.

1. Anchor Browser creates a dedicated AgentCore PaymentSession for the browser session. When the session starts with x402 turned on, Anchor Browser provisions a PaymentSession through AgentCore payments, linking the browser session to a configured payment instrument and budget.
2. The browser receives an HTTP 402 Payment Required response. The agent navigates to a URL or makes a fetch or XMLHttpRequest (XHR) request. The merchant responds with a 402 challenge specifying the amount, accepted payment methods, and payment address.
3. The browser selects a compatible payment method. Anchor Browser reads the 402 challenge payload and matches the requested payment method against the instrument linked to the PaymentSession.
4. AgentCore verifies the session budget and generates the cryptographic payment proof. AgentCore payments validates that the payment amount falls within the session spending limit. The service then signs the transaction using the configured wallet provider (Coinbase CDP or Stripe Privy) and returns the cryptographic proof. No key material enters the browser or agent runtime.
5. The browser retries the original request with the payment header. The browser attaches the signed proof as PAYMENT-SIGNATURE for x402 v2 or X-PAYMENT for x402 v1, then retries the original request exactly once.
6. The merchant verifies and settles the payment, then returns the protected resource. The merchant validates the cryptographic proof, settles the transaction on-chain, and serves the content. The agent continues the task.

Wallet credentials remain with AgentCore and the configured wallet provider throughout this flow.

Prerequisites

Before you begin, make sure that you have a valid Anchor Browser API key (ANCHOR_API_KEY). To create one, see the Anchor Browser Quick Start guide.

Setting up automatic x402 payments

Setting up agentic payments for Anchor Browser requires one session property. Set session.x402 to true. The property defaults to false. When enabled, the browser session can automatically access x402-protected websites with payments signed by AgentCore payments and retried inside the same browser session. Enabling session.x402 authorizes the browser to make real payments from the configured payment instrument.

The following examples show how to create a payment-enabled session for Anchor Browser using cURL and JavaScript:

cURL

curl --request POST
--url https://api.anchorbrowser.io/v1/sessions
--header "anchor-api-key: $ANCHOR_API_KEY"
--header "content-type: application/json"
--data '{"session":{"x402":true}}'

JavaScript

const response = await fetch('https://api.anchorbrowser.io/v1/sessions', {
  method: 'POST',
  headers: {
    'anchor-api-key': process.env.ANCHOR_API_KEY,
    'content-type': 'application/json',
  },
  body: JSON.stringify({ session: { x402: true } }),
});
const { data: session } = await response.json();
console.log(session.cdp_url);

After connected through Chrome DevTools Protocol, the agent navigates normally. You don’t need to include a wallet key or payment header in your automation code. The browser handles 402 challenges, payment signing, and retries transparently for document navigation, fetch, and XHR requests.

Payment session limits and behavior

Anchor Browser enforces the following guardrails at the session level through AgentCore payments integration. Each payment-ready browser session operates within configured spending and time constraints. For specific limits, refer to the Anchor Browser technical documentation.

If the merchant response is malformed, no compatible network is offered, the budget is exhausted, or AgentCore payments rejects the payment, the browser returns the original 402 response to the page unchanged. Your automation code can then handle the 402 as a standard HTTP error.

The x402 session property controls payments to third-party resources only. The property doesn’t replace Anchor credits and doesn’t pay for the browser session.

Automation code for Anchor Browser

Your automation code for Anchor Browser remains unchanged. The following example demonstrates that no payment-specific code is required:

const { chromium } = require('playwright');
// Connect to the x402-enabled session via CDP
const browser = await chromium.connectOverCDP(session.cdp_url);
const page = await browser.newPage();
// Navigate to an x402-protected resource exactly as with a free page
await page.goto('https://premium-research.example.com/market-report');
// The page loaded, the payment was handled automatically
// Extract content as normal
const content = await page.textContent('article');

No wallet logic, no payment header construction, and no retry code. The agent navigates to the URL. If the server returns 402, Anchor Browser coordinates with AgentCore payments to sign the payment proof, retries the request with the appropriate payment header, and delivers the content to the page. Your automation code receives the final rendered page with no indication that a payment occurred.

This pattern applies uniformly to paywalled journalism, licensed financial data, gated API documentation, metered research databases, and other resources that gate content behind a 402 challenge.

Using the built-in x402 tool for API calls

Paid resources aren’t limited to web pages. Many are APIs that expect POST, PUT, or other HTTP methods. Common examples include data enrichment services, premium inference endpoints, and licensed content APIs. For these use cases, Anchor Browser agents include a built-in x402 tool that you call like a standard HTTPS API within the browser context.

Your agent makes the API call through fetch or XHR. If the server returns a 402 challenge, the browser coordinates payment signing through AgentCore payments and retries the request with the signed payment header. Your code receives the response as though the endpoint were free. The tool isn’t tied to a specific vendor, model, or framework. Payment operates as a session-level capability beneath your existing tooling, and no changes to agent code are required.

// Fetch call to a paid API endpoint within the x402-enabled session
const response = await page.evaluate(async () => {
  const res = await fetch('https://data-enrichment.example.com/api/v1/enrich', {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({ company_domain: 'example.com' }),
  });
  return res.json();
});
// If the API returned 402, AgentCore handled payment automatically
// The response contains the enriched data
console.log(response);

Your automation code doesn’t receive wallet credentials. Automatic payments are available only when session.x402 is set to true and remain subject to the spending and expiration limits described in the previous section.

Key benefits

This integration moves payment from application code to the infrastructure layer:

No payment infrastructure to build. No wallet SDK to integrate, no 402 response parser to write, no retry loop to implement, no header construction logic to maintain, and no custom audit logging to build. AgentCore payments manages the entire payment stack.

No changes to existing tooling. Playwright scripts, Puppeteer automations, Chrome DevTools Protocol commands, and agent flows in Anchor Browser continue to function exactly as before. Payment is a session capability attached to the browser, not a modification to agent logic, prompts, or tool definitions.

Private keys don’t enter the runtime. Signing and settlement happen inside AgentCore payments. The service communicates with Coinbase CDP or Stripe Privy through secure credential storage in AgentCore Identity. The agent runtime doesn’t have access to key material that can move funds.

Budgets are enforced at the infrastructure level. Every session operates within defined spend limits that AgentCore enforces before authorizing a payment. Amazon Bedrock AgentCore Observability provides full payment audit trails through Amazon CloudWatch. When a session reaches the spending limit, AgentCore payments denies the payment.

Paid tasks complete successfully. Paid GET pages load. Paid API calls return responses. The agent completes the workflow rather than stopping at a 402 response and requiring manual intervention.

Billing is consolidated. Anchor Browser settles third-party x402 charges in credits on the same invoice as browser session time. There’s no separate crypto custody to manage, no USDC balance to monitor, and no on-chain settlement for the finance team to reconcile.

Conclusion

Anchor Browser, integrated with AgentCore payments, equips AI agents to handle x402 payment challenges autonomously for paywalled web pages and paid API endpoints. Wallet credentials stay out of agent code, and no custom payment infrastructure is required.

As more of the web moves to per-request pricing, agents that lack a payment mechanism can’t complete tasks involving paid resources. This integration addresses that gap: agents complete paid workflows end to end, operating within defined budgets, with full observability through AgentCore Observability, and without cryptographic key material in the runtime.

To get started, explore the following resources:

• Automatic x402 payments in Anchor Browser
• AgentCore payments developer guide
• AgentCore payments with browser integration
• Anchor Browser on AWS Marketplace

About the authors