构建可通过 Amazon Bedrock AgentCore payments 进行交易的 OpenClaw Agent

本文由 AWS 与 OpenClaw Foundation 合作发布。

能够浏览网页、调用 API 并查询 Model Context Protocol（MCP）服务器的自主 Agent，可能会遇到要求先完成 HTTP 402 Payment Required 响应结算才能继续访问的服务。为了在无需每笔交易都暂停等待人工操作的情况下使用这些服务，Agent 需要一条可在预先批准限制内运行的支付路径。一种安全的设计会将钱包提供商凭证，以及创建或扩展支付会话的权限，置于面向模型的运行时之外。运行时仍可在这些限制内发起已批准的支付。

AgentCore payments 是 Amazon Bedrock AgentCore 的一项功能；随着 Agent 支付协议不断演进，它提供钱包集成、支出限额和一致的支付层。x402 和 Machine Payments Protocol（MPP） 等协议支持 Agent 与服务之间的程序化支付流程。本文将 OpenClaw 连接至由人工通过可信管理路径配置的钱包和受限支付会话，随后使用适用于 OpenClaw 的 aws-agents-pay 插件发起已批准的测试网支付。

为什么 Agent 需要支付能力

自主 Agent 可以跨越多个步骤和服务采取行动，无需人工逐项审查每个操作。一个长时间运行的研究或工作流 Agent，可能在没有操作人员在场时遇到付费 API 或内容端点。受限支付层可使 Agent 在人工预先设定的收款方、资产、网络、单笔支付金额、累计预算和到期时间限制内继续执行。

一些 API、内容服务、计算服务和 MCP 工具采用按使用量计费。单笔交易金额可能低于 1 美元，甚至仅为几分之一美分。信用卡处理的最低费用会使这一规模的交易成本高得难以承受，而稳定币支付可支持小额交易和近实时结算。因此，x402 等 HTTP 原生协议适合用于由 Agent 发起的程序化支付。

直接实现这一能力需要钱包提供商集成、受保护的凭证处理、支付授权、确定性的限制以及支付可观测性。你还需要考虑模型可能受到不可信输入操控的情况。该设计并不能防止提示词注入。相反，它假设不可信输入可能操控模型，并通过收款方、资产、网络、单笔支付金额、会话预算和到期时间来限制运行时权限。

解决方案概述

随着 Agent 支付协议演进，AgentCore payments 提供一致的支付层。此 OpenClaw 集成使用 x402 v2 演示了该模式。它通过已配置的钱包提供商处理商家的 HTTP 402 挑战，并返回一份签名授权，供客户端用于重放请求。AgentCore Identity（Amazon Bedrock AgentCore 的一项功能）存储钱包提供商凭证。配置遥测数据传输后，AgentCore Observability（Amazon Bedrock AgentCore 的一项功能）可通过 Amazon CloudWatch 和 AWS X-Ray 提供日志、指标和追踪。

AgentCore payments 支持将 Coinbase 钱包或 Stripe Privy 钱包作为支付连接。两者均提供嵌入式稳定币钱包。视提供商和地区的可用性而定，你或你的最终用户可以通过稳定币或借记卡支付的法币为钱包充值。两个提供商均使用 AgentCore Identity 凭证存储和每会话支出限额。

本演练使用 OpenClaw，这是一款运行在你的设备上、通过本地 Gateway 连接模型、工具和消息渠道的 AI 助手。OpenClaw Foundation 维护该项目，插件则可扩展该助手的功能。本演练将人工执行的支付管理与面向模型的运行时分离。人工通过可信终端配置钱包、创建支付会话、批准收款方并设定预算。aws-agents-pay 插件向模型暴露两项工具：用于检查已配置支付会话的 get_payment_session_status，以及用于请求获准付费 URL 并在配置策略内完成支付的 get_paid_content。运行时可以在已批准的会话中发起支付，但无法创建、延长或替换会话。

图 1：该演示在 OpenClaw Gateway 应用中展示了与名为“Bob”的 AI 助手进行的聊天。用户询问“西雅图现在的天气怎么样？”，随后 Bob 针对一个付费天气 API 在 Base Sepolia 上执行了 0.001 USDC 的测试支付。

典型支付流程如下：

• Agent 调用 get_payment_session_status，确认由操作人员配置的会话可用。
• Agent 针对获准 URL 调用 get_paid_content。插件首先执行受限网络探测，并收到包含 x402 v2 挑战的 HTTP 402 响应。
• 收到挑战后，插件会验证挑战资源与请求 URL 具有相同的源和路径。然后，它会根据操作人员的策略验证网络、资产、收款方和金额，之后才调用 ProcessPayment。
• 对同一支付请求进行重试时，插件会复用相同的幂等性令牌，而不会创建第二笔支付。并发的重复请求仍可能产生竞态，因此应避免同时发起同一笔支付。
• 插件等待签名授权的 validAfter 时间到达，然后携带支付签名重放原始请求。
• 在本演练中启用 returnBody 后，插件会返回付费响应正文，将其上限设为 10 KiB，并将其标记为 untrusted: true。插件不会将签名支付凭证返回给模型。

当前 Agent Toolkit for AWS 中的 OpenClaw 设置流程提供了 Base Sepolia 用于测试、Base 用于生产的示例，并支持为其他链进行自定义，包括 Ethereum、其他 EVM 兼容链和 Solana。

与 OpenClaw 的合作

AWS 一直与 OpenClaw Foundation 合作开发此集成，包括支持 ClawCon 等社区活动，并与 Foundation 的工程团队直接合作，将 AgentCore payments 引入插件框架。

“支付是对 OpenClaw 中插件既有功能的自然延伸：通过定义清晰的工具为 Agent 赋予一项新能力，而不是事后附加的特殊功能。我们感谢 AWS 对 OpenClaw 生态系统的支持，从 ClawCon 等活动到与我们团队直接合作开发这项集成。如今，Agent 获得了为其所使用服务付费的生产级路径，而开发者仍能保有他们期待从任意 OpenClaw 插件中获得的相同对话式设置体验。随着 Agent 支付逐渐成为 Agent 自主运行方式中更重要的组成部分，我们期待与 AWS AgentCore 展开更深入的合作。”

— Patrick Erichsen，OpenClaw Foundation 技术人员

实施步骤：配置 OpenClaw 以进行受限支付

以下章节将带你完成前提条件、在 Agent 循环之外配置钱包和支付会话、设置明确的支付策略以及进行一次受限支付。

前提条件

确保你具备以下前提条件。

• OpenClaw 版本 2026.3.24 或更高版本：npm install -g openclaw。
• Node.js 和 npm。
• 一个可访问 AgentCore payments 的 AWS 账户。
• 分别用于管理和运行时的 AWS Identity and Access Management（IAM）角色，并遵循 AgentCore payments IAM 角色指南。OpenClaw 运行时角色只需要状态查询所需的读取操作以及 ProcessPayment。该角色不得拥有会话写入权限。
• Coinbase CDP 或 Stripe with Privy 凭证，仅可在交互式 AgentCore CLI 中输入。
• 一个由你控制或经过独立批准的 Base Sepolia x402 v2 端点。你可以使用 Coinbase x402 Bazaar发现候选服务，但在将端点、收款方、网络、资产和价格加入支付策略前，必须进行验证。
• 从商家文档或其他已知可靠来源独立验证的商家收款地址和 USDC 资产合约，而非仅依据 HTTP 402 响应。

免责声明： 此解决方案的安全性遵循 AWS 共同责任模型。AWS 负责云的安全，而你负责云中环境的安全。对于此解决方案，你的责任包括配置 IAM 权限、保护钱包提供商凭证以及定义支付策略。请遵循 AgentCore payments IAM 角色指南，分离管理、运营、Agent 执行和服务运维职责。

以下步骤将带你从安装插件到观察 Agent 为其第一份付费内容完成支付。

1. 从 ClawHub 安装插件

继续前，请确认 @aws/aws-agents-pay 软件包可在 ClawHub 上获取。然后安装它：

软件包名称为 @aws/aws-agents-pay，安装后的插件 ID 为 aws-agents-pay，随附的技能名称为 agents-pay。

要检查随附的设置指南，请运行：

检查已安装的插件：

面向模型的运行时只能暴露 get_payment_session_status 和 get_paid_content。如果出现设置、会话创建、shell 或其他面向模型的工具，请停止操作。意外出现的工具可能表明软件包不同、已过期或被修改。

2. 完成受人工监督的支付设置

安装插件不会创建支付管理器、连接器、支付工具或支付会话。请选择以下配置选项之一。两种选项都使用在你的 AWS 凭证下运行的可信终端，并且创建会话时要求你在交互式 TTY 中输入 approve。

选项 A – OpenClaw 辅助设置。 向 OpenClaw 提问：Help me set up the agents-pay skill. OpenClaw 可以解释每个步骤，但你必须自行运行管理命令并批准会话创建。OpenClaw 的指引不会取消交互式审批关卡。

选项 B – 完全手动设置。 直接遵循 OpenClaw 设置指南，不使用 OpenClaw。

无论选择哪种方式，都请在可信且由人工监督的终端中遵循 OpenClaw 设置指南。该指南涵盖创建 AgentCore 项目、配置支付资源、运行设置向导以及将生成的配置添加至 OpenClaw。你必须亲自输入凭证并键入 approve。

3. 使用明确策略配置插件

启用插件前，请审核生成的配置。其中必须包括支付管理器 ARN、支付工具 ID、会话 ID、用户 ID、网络、精确的资产合约、获准收款方以及一个大于零的单笔支付上限。

对于沙盒演练，请使用配套代码示例第 3 步中的支付策略。该策略包含与下一步使用的测试端点相匹配的 Base Sepolia 网络、源、收款方、USDC 资产、支付限额和 returnBody 设置。

该沙盒端点列在 Coinbase x402 Bazaar 中，但本演练会直接调用一个已知 URL。对于基于发现的工作流，请参阅使用 Coinbase Bazaar 的教程。

对于固定的商家集合，请通过商家文档或其他已知可靠来源在带外验证 allowedRecipients 中的每个地址。不要仅因为某个收款方出现在 HTTP 402 响应中就予以批准。对于更广泛的服务发现情景，请设置 allowAnyRecipient: true，以允许发布商选择受益人。该选项以收款方白名单换取灵活性；源、网络、资产、单笔支付和会话预算控制仍然适用。在本演练中，请将 networkPreferences 保持为 Base Sepolia（eip155:84532），并使用设置向导所选的精确 Base Sepolia USDC 合约。

maxPaymentAmountAtomic 以资产的最小单位限制单笔支付。对于小数位数为六位的 USDC 资产，100000 表示 0.10 USDC。支付会话预算则单独限制会话到期或额度耗尽前的累计支出。在本演练中，将 returnBody 设为 true，使 Agent 可以使用付费响应。插件会将响应上限限制为 10 KiB，并标记为 untrusted: true。发布商控制的内容可能包含提示词注入指令，因此当 Agent 只需要响应元数据和摘要时，请不要设置 returnBody，或将其设为 false。该设置不会暴露签名支付凭证。

钱包提供商密钥不应存在于 OpenClaw 配置中。请将支付会话 ID、资源标识符、收款方策略和其他配置值视为敏感运营数据，因为它们描述并授权了运行时的支付路径。

This post is a collaboration between AWS and theOpenClaw Foundation.

Autonomous agents that browse the web, call APIs, and query Model Context Protocol (MCP) servers can encounter services that require an HTTP 402 Payment Required response to be settled before access continues. To use those services without pausing for a human at every transaction, an agent needs a payment path that operates within limits approved in advance. A safe design keeps wallet-provider credentials and the authority to create or expand payment sessions outside the model-facing runtime. The runtime can still initiate approved payments within those limits.

AgentCore payments, a capability of Amazon Bedrock AgentCore, provides wallet integration, spending limits, and a consistent payment layer as agent payment protocols evolve. Protocols such as x402 and Machine Payments Protocol (MPP) support programmatic payment flows between agents and services. In this post, you connect OpenClaw to a wallet and bounded payment session that a human provisions through a trusted administrative path, then use the aws-agents-pay plugin for OpenClaw to initiate approved testnet payments.

Why agents need payment capabilities

Autonomous agents can act across multiple steps and services without a human reviewing each action. A long-running research or workflow agent might encounter a paid API or content endpoint while no operator is present. A bounded payment layer lets the agent continue within recipient, asset, network, per-payment, cumulative budget, and expiry limits that a human sets in advance.

Some APIs, content services, compute services, and MCP tools use pay-per-use pricing. Individual transactions can be less than one dollar or fractions of a cent. Minimum card-processing fees can make transactions at that scale cost-prohibitive, while stablecoin payments can support small amounts and near-real-time settlement. This makes HTTP-native protocols such as x402 suitable for programmatic, agent-initiated payments.

Implementing this directly requires wallet-provider integration, protected credential handling, payment authorization, deterministic limits, and payment observability. You also need to account for a model that can be manipulated by untrusted input. The design does not prevent prompt injection. Instead, it assumes untrusted input can manipulate the model and bounds the runtime’s authority by recipient, asset, network, per-payment amount, session budget, and expiry.

Solution overview

AgentCore payments provides a consistent payment layer as agent payment protocols evolve. This OpenClaw integration demonstrates the pattern using x402 v2. It processes a merchant’s HTTP 402 challenge through a configured wallet provider and returns a signed authorization that the client uses to replay the request. AgentCore Identity, a capability of Amazon Bedrock AgentCore, stores wallet-provider credentials. AgentCore Observability, a capability of Amazon Bedrock AgentCore, can provide logs, metrics, and traces through Amazon CloudWatch and AWS X-Ray when telemetry delivery is configured.

AgentCore payments supports a Coinbase wallet or a Stripe Privy wallet as the payment connection. Both provide an embedded stablecoin wallet. Subject to provider and geographic availability, you or your end users can fund the wallet through stablecoin or fiat using a debit card. Both providers use AgentCore Identity credential storage and per-session spending limits.

This walkthrough uses OpenClaw, an AI assistant that runs on your devices and connects models, tools, and messaging channels through a local Gateway. The OpenClaw Foundation maintains the project, and plugins extend what the assistant can do. The walkthrough separates human-run payment administration from the model-facing runtime. A human provisions the wallet, creates the payment session, approves recipients, and sets the budget in a trusted terminal. The aws-agents-pay plugin exposes two model-visible tools: get_payment_session_status, which checks the configured payment session, and get_paid_content, which requests an approved paid URL and completes the payment within the configured policy. The runtime can initiate a payment within the approved session, but it cannot create, extend, or replace a session.

Figure 1: The demo shows a chat with an AI assistant named “Bob” in the OpenClaw gateway application. The user asks “What’s the weather in Seattle right now?” then Bob executes a test payment of 0.001 USDC on Base Sepolia for a paid weather API

A typical payment flow is:

• The agent calls get_payment_session_status to confirm that an operator-provisioned session is usable.
• The agent calls get_paid_content for an approved URL. The plugin first performs a bounded network probe and receives an HTTP 402 response containing an x402 v2 challenge.
• After receiving the challenge, the plugin verifies that the challenge resource has the same origin and path as the requested URL. It then validates the network, asset, recipient, and amount against the operator’s policy before it calls ProcessPayment.
• For a retry of the same payment request, the plugin reuses the same idempotency token rather than creating a second payment. Concurrent duplicate requests can still present a race, so avoid issuing the same payment concurrently.
• The plugin waits until the signed authorization’s validAfter time, then replays the original request with the payment signature.
• With returnBody enabled for this walkthrough, the plugin returns the paid response body, caps it at 10 KiB, and marks it as untrusted: true. The plugin does not return the signed payment proof to the model.

The current OpenClaw setup flow in the Agent Toolkit for AWS provides an example for Base Sepolia for testing and Base for production, and supports customization for other chains, including Ethereum, other EVM-compatible chains, and Solana.

Collaboration with OpenClaw

AWS has been collaborating with the OpenClaw Foundation on this integration, including support for community events like ClawCon, and worked directly with the Foundation’s engineering team to bring AgentCore payments into the plugin framework.

“Payments are a natural extension of what plugins already do in OpenClaw: give an agent a new capability through a well-defined tool, not a special case bolted on afterward. We’re grateful for AWS’s support of the OpenClaw ecosystem, from events like ClawCon to working directly with our team on this integration. Agents now get a production-grade path to pay for what they use, while builders keep the same conversational setup they expect from any other OpenClaw plugin. We’re looking forward to going deeper with AWS AgentCore as agentic payments become a bigger part of how agents operate on their own.”

— Patrick Erichsen, Member of Technical Staff, OpenClaw Foundation

Implementation steps: Configure OpenClaw to make bounded payments

The following sections walk you through the prerequisites, provisioning the wallet and payment session outside the agent loop, configuring an explicit payment policy, and making a bounded payment.

Prerequisites

Make sure that you have the following prerequisites.

• OpenClaw version 2026.3.24 or later: npm install -g openclaw.
• Node.js and npm.
• An AWS account with access to AgentCore payments.
• Separate AWS Identity and Access Management (IAM) roles for administration and runtime, following the AgentCore payments IAM roles guide. The OpenClaw runtime role needs only the read operations required for status plus ProcessPayment. It must not have session-write permissions.
• Coinbase CDP or Stripe with Privy credentials, entered only in the interactive AgentCore CLI.
• A Base Sepolia x402 v2 endpoint that you control or have independently approved. You can use the Coinbase x402 Bazaar to discover candidate services, but verify the endpoint, recipient, network, asset, and price before adding them to the payment policy.
• The merchant recipient address and USDC asset contract verified from merchant documentation or another known-good source, independently of the HTTP 402 response.

Disclaimer: Security for this solution follows the AWS shared responsibility model. AWS is responsible for security of the cloud, while you’re responsible for security in the cloud. For this solution, your responsibilities include configuring IAM permissions, protecting wallet-provider credentials, and defining payment policies. Follow the AgentCore payments IAM roles guidance to separate administrative, management, agent execution, and service operations.

The following steps take you from installing the plugin to watching an agent pay for its first piece of paywalled content.

1. Install the plugin from ClawHub

Before continuing, confirm that the @aws/aws-agents-pay package is available on ClawHub. Then install it:

The package name is @aws/aws-agents-pay, the installed plugin ID is aws-agents-pay, and the bundled skill name is agents-pay.

To inspect the bundled setup guidance, run:

Inspect the installed plugin:

The model-visible runtime must expose only get_payment_session_status and get_paid_content. Stop if a setup, session-creation, shell, or other model-visible tool appears. An unexpected tool can indicate a different, outdated, or modified package.

2. Complete the human-supervised payment setup

Installing the plugin does not create the payment manager, connector, instrument, or payment session. Choose one of the following provisioning options. Both options use a trusted terminal under your AWS credentials, and session creation requires you to type approve at an interactive TTY.

Option A – OpenClaw-assisted setup. Ask OpenClaw: Help me set up the agents-pay skill. OpenClaw can explain each step, but you must run the administrative commands and approve session creation yourself. OpenClaw guidance does not remove the interactive approval gate.

Option B – Fully manual setup. Follow the OpenClaw setup guide directly, without involving OpenClaw.

For either option, follow the OpenClaw setup guide in a trusted, human-supervised terminal. The guide covers creating the AgentCore project, provisioning payment resources, running the setup wizard, and adding the generated configuration to OpenClaw. You must enter credentials and type approve yourself.

3. Configure the plugin with an explicit policy

Review the generated configuration before enabling the plugin. It must include the payment manager ARN, instrument ID, session ID, user ID, network, exact asset contract, approved recipients, and a positive per-payment ceiling.

For the sandbox walkthrough, use the payment policy in Step 3 of the companion code sample. It contains the Base Sepolia network, origin, recipient, USDC asset, payment limit, and returnBody setting that match the test endpoint used in the next step.

This sandbox endpoint is listed in the Coinbase x402 Bazaar, but this walkthrough calls a known URL directly. For a discovery-driven workflow, see the Tutorial with Coinbase Bazaar.

For a fixed merchant set, verify every address in allowedRecipients out of band using merchant documentation or another known-good source. Don’t approve a recipient only because it appeared in an HTTP 402 response. For broader discovery scenarios, set allowAnyRecipient: true to let the publisher select the beneficiary. This option trades recipient allowlisting for flexibility; origin, network, asset, per-payment, and session-budget controls still apply. For this walkthrough, keep networkPreferences on Base Sepolia (eip155:84532) and use the exact Base Sepolia USDC contract selected by the setup wizard.

maxPaymentAmountAtomic limits one payment in the asset’s smallest unit. For a six-decimal USDC asset, 100000 represents 0.10 USDC. The payment session budget separately limits cumulative spend until the session expires or is exhausted. For this walkthrough, set returnBody to true so the agent can use the paid response. The plugin caps the response at 10 KiB and marks it as untrusted: true. Publisher-controlled content can contain prompt-injection instructions, so leave returnBody unset or set it to false when the agent only needs response metadata and a digest. This setting doesn’t expose the signed payment proof.

Wallet-provider secrets do not belong in the OpenClaw configuration. Treat the payment session ID, resource identifiers, recipient policy, and other configuration values as sensitive operational data because they describe and authorize the runtime’s payment path.

Restart the gateway after saving ~/.openclaw/openclaw.json:

If you use the protected ~/.x402/config.json path instead of inline plugin configuration, the plugin checks ownership and permissions on the directory and file and refuses to load an unsafe configuration.

4. Check session status and pay for content

Ask your OpenClaw agent to check whether the configured session is usable:

If the session is unavailable, expired, or exhausted, stop. Use the trusted administrative path to review the situation and create a replacement session. The model-facing runtime cannot create or expand its own budget.

The companion sample pins its payment policy to the Base Sepolia endpoint used in this walkthrough. Ask the agent to fetch it:

The plugin performs a bounded probe, validates the returned challenge against the operator’s policy, calls AgentCore payments, waits until the signed authorization is valid, and replays the request. With returnBody enabled for this walkthrough, the tool returns the paid response body with content_returned: true, caps it at 10 KiB, and marks it as untrusted: true. It does not return the signed payment proof.

Treat merchant responses and all retrieved content as untrusted. This design doesn’t prevent prompt injection. It assumes the model can be manipulated and bounds payment authority through IAM separation, approved recipients and assets, a per-payment ceiling, a cumulative session budget, and an expiry. Enable returnBody only when the agent needs the paid response, and treat that response as data rather than instructions.

Ask for session status again:

Confirm that the reported remaining budget reflects the payment.

Clean up

Remove the plugin from OpenClaw and restart the gateway:

Use the same trusted administrative path to remove the payment resources on AWS. Don’t expose infrastructure deletion or session creation to the model-facing runtime, and keep the runtime IAM role without those permissions.

Conclusion

With AgentCore payments, an agent can access paywalled APIs, pay-per-use data feeds, and metered MCP tools within limits a human sets in advance. AgentCore payments handles wallet integration, spending limits, and payment orchestration. In this OpenClaw pattern, the human keeps wallet-provider credentials and authority over recipients, assets, per-payment limits, cumulative session budget, and expiry outside the model-facing runtime. The agent can initiate payments only within those approved bounds.

Install the aws-agents-pay plugin from ClawHub, then follow the OpenClaw agent with AgentCore payments sample to provision the payment resources and complete an end-to-end x402 payment.

Resources

Acknowledgements

We’d like to thank Madhu Samitha Vangara and Isaac Lin, Solutions Architects at AWS, for their contributions to this solution.

---

About the authors

Patrick Erichsen

Patrick is a Member of Technical Staff at the OpenClaw Foundation. Previously he was a founding engineer at Continue (YC W23), where he worked on coding agents. He’s interested in using AI as a tool to expand human creativity.

Daniel Wirjo

Daniel is a Solutions Architect at AWS, focused on AI startups. As a former startup CTO, he enjoys collaborating with founders and engineering leaders to drive growth and innovation on AWS. Outside of work, Daniel enjoys taking walks with a coffee in hand, appreciating nature, and learning new ideas.

Peter Jiang

Peter is a Senior Software Developer at AWS, based in Seattle, WA. He is a core member of the engineering team behind the Amazon Bedrock AgentCore payments initiative, which enables AI agents with payments capability. With over 8 years of experience in the financial and payments industry, Peter has launched multiple greenfield projects spanning banking, crypto, and agentic systems. Previously, he worked on ultra-low latency trading systems at Susquehanna International Group.

Chethan Shriyan

Chethan is a Principal Product Manager, Technical at AWS, based in Seattle, WA. He brings nearly 13 years of experience in product and business management, including over 7 years at Amazon. He is passionate about building and delivering technology products that create meaningful impact in customers’ lives.