Technical deep dive: AgentCore payments and innovation in agentic commerce

TL;DR · AI Summary
Amazon Bedrock AgentCore payments introduces a managed service for AI agents to handle microtransactions efficiently, addressing complex issues like billing and security.
Key Takeaways
- Amazon Bedrock AgentCore payments enables AI agents to perform microtransactions
- It supports stablecoins for cost-effective microtransactions and includes config
- Built on the security foundation of AgentCore, this fully managed service accele
Outline
Jump quickly between sections.
Amazon Bedrock AgentCore payments is the first managed service within Amazon Bedrock AgentCore that helps AI agents autonomously execute microtransaction payments for paid APIs, MCPs, and content with
AgentCore payments provides a straightforward API that abstracts the complexity of payments processing.
The team identified and addressed the key challenges in building a payment capability for agent developers.
AgentCore payments solves these challenges through intelligent payment orchestration, real-time budget enforcement, and end-to-end observability.
This fully managed service reduces developer effort from months to days by providing a secure and efficient solution.
Mindmap
See how the topics connect at a glance.
查看大纲文本(无障碍 / 无 JS 友好)
- Amazon Bedrock AgentCore payments
- 核心机制
- 简单 API
- 稳定币支持
- 挑战
- 支付处理复杂性
- 预算强制
- 可观测性
- 解决方案
- 智能支付编排
- 实时预算强制
- 端到端可观测性
- 优势
- 减少开发者工作量
- 加速时间到市场
Highlights
Key sentences worth saving and sharing.
AgentCore payments provides a simple API that makes it easy for AI agents to perform microtransactions.
Supports stablecoins for cost-effective microtransactions, allowing sub-cent transactions.
Solves complex issues through intelligent payment orchestration, real-time budget enforcement, and end-to-end observability.
URL 源: https://aws.amazon.com/blogs/machine-learning/technical-deep-dive-agentcore-payments-and-innovation-in-agentic-commerce/
发布时间: 2026-05-26T09:57:18-08:00
Markdown 内容: 行业正在进入一个由数十亿个生成式人工智能代理自主运行的世界,这些代理代表人类行动,做出决策并完成任务,无需人工干预。为了支持这种转变,Amazon Bedrock AgentCore 提供了一个模块化、完全托管的平台,帮助开发者大规模构建、部署和运营生成式人工智能代理。通过抽象服务器管理、安全性和集成的复杂性,AgentCore 作为基础基础设施层发挥作用,使开发者能够专注于最重要的事情:代理的逻辑。
这个代理世界已经重塑了内容、API 和软件即服务(SaaS)提供商的运作方式。自动化流量越来越多地超越了网页上的人工流量,而代理人工智能是一个快速增长的领域。商业模式正在重写,使得出版商和 API 提供者转向针对代理访问量身定制的按需付费模式。出版商和内容交付网络(CDN)已经开始阻止并商业化代理流量。API 正朝着针对代理流量的按需付费模式转变。这一趋势表明,未来会有数十亿个代理自主访问数十亿个端点,动态选择服务并在实时中交易以完成任务。
尽管 AI 代理可以通过 API、MCP 和 Web 浏览实现复杂的任务,但在访问付费服务和内容时会遇到障碍。访问外部服务需要为每个提供商订阅和管理单独的账单账户,这会产生显著的开销。更进一步的是,大多数 API 调用和内容访问价值只有几分钱,但传统的支付方法如信用卡包括每次交易的固定费用(例如,USD $0.30),使其对高频微交易经济上不可行。将第三方钱包、支付编排、代理协议支持(如 x402,一种流行的机器到机器支付协议)、边缘情况处理以及端到端可观测性整合在一起可能需要数月的工作。除了集成复杂性外,开发者必须从头开始构建治理和预算护栏,以防止过度支出,并满足支付流所需的严格安全和合规要求。
Amazon Bedrock AgentCore 支付 是专门设计来解决这些问题的。现在处于预览阶段,它提供了即时支付给付费外部服务的功能,无需为每个提供商手动设置账单,稳定币支持成本效益高的微交易,使亚美金交易经济上可行,并且可配置的支出护栏让您对代理预算和交易限制有细粒度的控制。在这篇文章中,我们将带您深入了解 AgentCore 支付。
介绍 Amazon Bedrock AgentCore 支付
Amazon Bedrock AgentCore 支付是 Amazon Bedrock AgentCore 中的第一个托管服务,帮助 AI 代理通过几行代码自主执行针对付费 API、MCP 和内容的微交易支付。它提供稳定币支持,使低成本微交易经济上可行,并且可配置的护栏可以控制代理支出,将开发者的努力从数月减少到几天。基于 AgentCore 的安全基础,这个完全托管的服务加速了代理支付流程的上市时间。下图展示了 AgentCore 支付的预览功能及其如何与其他相关 AgentCore 服务交互。

_图 1:AgentCore 支付功能_
在核心层面,AgentCore 支付提供了一个简单的 API,抽象了支付处理的复杂性。无论代理使用哪种支付提供商、网络或底层协议,都可以通过单一 API 调用来与受支持的商家进行交易。AgentCore 支付还提供了智能支付编排、实时预算强制执行和端到端可观测性。下一节将深入探讨为什么代理支付具有独特挑战性,以及 AgentCore 支付如何解决这些问题。
挑战
为了构建一个适用于代理开发者的支付能力,团队绘制了开发者在启用其代理支付付费 API、MCP 和内容时面临的关键挑战和问题。
我如何资助我的代理?
对于开发者来说,第一个关键障碍是如何资助驱动其代理交易的代理。由于涉及真实资金,这不仅是一个管道问题,也是一个安全问题。与第三方支付钱包集成显然是一个显而易见的选择,但开发者必须验证认证密钥不会被泄露。他们必须确认已实施适当的身份验证控制,以确定谁可以对钱包执行操作,身份验证机制是否强大且防篡改,并在整个系统中存在额外的安全层,以防止未经授权的访问和欺诈。
For secure authentication of payment wallets, AgentCore payments uses [AgentCore Identity](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-overview.html). Developers create a payment connector, which is a payment provider-specific integration resource. This automatically provisions a payment credential provider in AgentCore Identity, which stores payment credentials in a secure token vault and mints tokenized access tokens without exposing raw credentials. This credential provider is specifically designed for high-performance, secure digital signatures. It supports `EdDSA`, `ECDSA`, and `ES256` for wallet operations with payment providers. The cryptographic material lives in AWS Secrets Manager and isn’t returned from APIs. Each payment connector is associated with a unique AgentCore workload identity. The workload identity is used to obtain a workload-scoped, one-time-use access token from the AgentCore credential provider system. The cryptographic binding between workload identity and user context provides multi-tenant isolation.
On the inbound side, the service enforces dual authentication, OAuth and AWS SigV4, within the same request pipeline for accessing AgentCore payments APIs, providing a flexible security layer. For OAuth invocations, the inbound bearer token is validated against AgentCore Identity, and JWT claims are extracted to derive user identity for downstream operations. For SigV4, the request signature is validated using AWS Identity and Access Management (IAM).

_Figure 2: Secure credential storage for AgentCore payments and AgentCore Identity._
### Which payment protocol should I pick, and what do I need to build on top of it?
The agentic payments landscape is fragmented across numerous competing protocols, leaving developers overwhelmed and unclear on which one fits their specific use case. Ramping up on a single protocol demands significant time and effort because each comes with its own nuances (versioning, authentication flows, transaction models) that developers must understand before building anything production-ready. Beyond protocol selection, developers must also construct their own abstraction layer to handle these complexities. The effort compounds as the permutations grow: building across multiple wallet providers (each with different auth and wallet APIs), payment networks, and protocols turns what seems like a single integration into a sprawling matrix of combinations.
To address this, AgentCore payments supports payment orchestration, a core engine purpose-built to power the complexities of agentic payments. It sits between your AI agent and payment providers, exposing a single `processPayment` interface that takes a payment request and returns a payment proof that an agent can present to access paid services. AgentCore payments abstracts protocol complexity by automatically managing multi-step payment flows, retries, and edge cases across popular agentic payment protocols like x402. It handles variations across protocol versions (for example, x402 v1 and v2 differ in how payment requirements are structured and what fields are expected), transforming those into crypto-network-specific transaction data, implementing payment proof generation algorithms, and signing transactions securely through provider APIs while enforcing the spend limits you configured. The orchestrator is architected around a pluggable model where each payment protocol and provider is implemented as an independent interface. This means adding support for a new protocol doesn’t require changes to the core orchestration logic or the developer-facing API. Developers continue calling the same `processPayment` interface, and the orchestrator routes to the right connector and protocol handler based on the payment requirements.

_Figure 3: AgentCore payments payment orchestration engine._
### How do I verify that my agent doesn’t go off the rails in spending?
Agents are autonomous by nature, which means unconstrained spending is a real possibility. Developers need mechanisms to enforce spending limits in real time, deterministically, so an agent operating on behalf of a user or business can’t exceed predefined budgets, whether at the session level or user level. Without these guardrails, a single runaway agent interaction could result in significant unintended costs.当代理处理用户请求,例如预订旅行时,可能会并行发起多个支付(航班、酒店、租车),同时从同一个预算中扣除资金。如果一个操作在另一个操作完成写入之前读取可用余额,结果将是过期状态和超支。在实际的并发负载下,这不是边缘情况,而是预期行为,错误地处理会导致客户信任度迅速下降。AgentCore 支付提供了在基础设施级别内置的支出限制强制执行功能,旨在大规模运行。支出限制作为支付会话的一部分配置,是一个具有内置支出限制强制执行的范围有限、时间限定的上下文,在事务处理之前。从那时起,每个 processPayment 调用都会通过三个阶段的事务工作流:首先,通过原子性扣减请求金额来预留可用支出限额。然后,通过提供商处理支付。最后,如果成功,则提交事务;如果失败,则回滚事务,恢复预留金额到可用余额。无论是单个代理还是成千上万的代理同时对同一预算进行交易,都没有过期读取、覆盖或超支。开发者可以在不构建自定义并发或锁定逻辑的情况下,以规模化的形式获得支出控制。

_Figure 4: Three-phase protocol for atomic budget check._
如何审计代理的支出并衡量成功?
对于自主交易的代理,开发人员需要对其支付行为有完全的可见性。这意味着能够审查和审计代理所做的每笔交易,追溯支出回到特定会话或任务,并访问支付操作的高级指标,如总支出、交易成功率和每项任务的成本。没有强大的可观测性,开发人员就无法优化成本、检测异常或展示投资回报率。
AgentCore 支付消除了这一负担。它提供了一个三层供应商提供的可观测性系统(指标、日志和跟踪),直接发布到您的 AWS 账户,无需任何仪器化代码。每个 API 操作都会自动发出 Amazon CloudWatch 指标,用于成功计数、失败计数和延迟,按操作和支付资源进行维度划分。processPayment 还会根据令牌类型发出支出金额,以便您可以精确跟踪代理使用每种令牌类型的支出。结构化日志通过异步批量管道交付,每个管道都携带支付资源上下文和请求 ID 以实现端到端的相关性。分布式跟踪基于 W3C 跟踪上下文传播与 OpenTelemetry 兼容的跨度。这些跨度会丰富支付特定属性,包括支出金额、剩余预算和凭证提供程序遥测,该遥测显示多步骤签名链在顶层跨度上的性能。总体而言,这为开发者和企业提供对整个执行堆栈中每个支付事件的全面可见性,并提供透明度和对代理如何使用资金的控制权。

_Figure 5: AgentCore payments service-emitted observability._
使用 Amazon Bedrock AgentCore 支付入门
要开始使用,请参阅 先决条件 中的 AgentCore 支付文档。您可以通过多种接口设置和使用 AgentCore 支付:
- AWS Python SDK (Boto3)。
- AWS 管理控制台。
- Amazon Bedrock AgentCore SDK。
- Strands Agents 和代理本地集成的插件,带有内置的 x402 钩子。
以下部分突出显示了演示如何设置和使用 Amazon Bedrock AgentCore 支付的代码片段。
一次性配置
在注册到 AgentCore 支付之前,您需要从您的支付提供商获取 API 凭证。对于 Stripe,从 Stripe 控制台的“开发者”→“API 密钥”下检索您的秘密 API 密钥。对于 Coinbase,从 Coinbase 开发者平台创建一个 CDP API 密钥,该平台会颁发一个密钥名称和私钥对。
AgentCore 支付使用这些凭据创建一个支付连接器,这是一个特定于提供商的集成,充当 AgentCore 支付和您选择的提供商之间的桥梁。支付连接器在支付管理器下注册,这是顶级实体,用于将您的连接器组合在一起并提供统一的执行引擎,管理支付流程,从钱包配额分配到支付处理。
您只需在此设置过程中提供一次这些凭据。AgentCore Identity 然后负责凭据存储,使用安全令牌金库,因此凭据不会在运行时暴露。代理本身没有任何访问原始凭据的权限。凭据轮换由基础设施透明处理,而您则完全控制凭证提供者的访问权限。只有授权角色可以使用 AgentCore Identity 生成一次性、短期有效的令牌。以下代码在一个调用中执行一次性设置 使用 AgentCore SDK。
from bedrock_agentcore.payments import PaymentClient# 创建 PaymentClient
payment_client = PaymentClient(region_name="us-west-2")
# 使用连接器和凭证提供程序创建支付管理器
response = payment_client.create_payment_manager_with_connector(
payment_manager_name="myPaymentManager",
payment_manager_description="myPaymentManager description",
authorizer_type="AWS_IAM",
role_arn=ROLE_ARN,
payment_connector_config={
"name": "myPaymentConnector",
"description": "myPaymentConnector description",
"payment_credential_provider_config": {
"name": "myCoinbasePaymentCredential",
"credential_provider_vendor": "<PROVIDER>",
"credentials": {
"api_key_id": API_KEY,
"api_key_secret": API_KEY_SECRET,
"wallet_secret": WALLET_SECRET,
},
},
}
)
# 从响应中提取详细信息
payment_manager_arn = response["paymentManager"]["paymentManagerArn"]
payment_connector_id = response["paymentManager"]["paymentConnectorId"]Python
设置支付工具
在设置好支付管理器后,您通过引用支付管理和支付连接器来创建一个 _支付工具_。支付工具是您的代理用于自主交易的工具。支付工具本质上是一个嵌入式钱包,由支付提供商托管但由最终用户管理的自我托管钱包地址。
在创建后,该工具必须被资金化,并且在代理可以交易之前需要授予签名授权。这些是最终用户的操作,应该在使用支付工具之前完成。流程特定于支付提供商:
- Coinbase – 您会在支付工具响应中收到一个
redirectUrl,指向 Coinbase 托管的 WalletHub。将您的用户重定向到那里以授予签名权限并转移资金。 - Stripe – 您使用提供的 URL 模板来托管一个前端页面,其中最终用户可以执行相同的操作。
两家提供商都支持三种流程:
- 加密到加密 – 从现有的加密钱包转账。
- 法定货币到加密 – 从信用卡或借记卡,或者通过托管 UI 从第三方钱包如 Apple Pay 转账。
- 委托签名 – 代理使用委托密钥代表用户签名。
from bedrock_agentcore.payments import PaymentManager
# 初始化管理器
manager = PaymentManager(
payment_manager_arn=payment_manager_arn,
region_name="us-west-2"
)
instrument = manager.create_payment_instrument(
user_id="test-user-123",
payment_connector_id="codeverifymycoinbaseconnector-sfp0lynfjc",
payment_instrument_type="EMBEDDED_CRYPTO_WALLET",
payment_instrument_details={
"embeddedCryptoWallet": {
"network": "ETHEREUM",
"linkedAccounts": [{
"email": {
"emailAddress": "test@example.com"
}
}]
}
},
)Python
创建支付会话
您创建一个与资金化的工具和最终用户相关的支付会话,并可选地指定明确的支付限制和超时时间。这个会话是代理的财务边界;它定义了确切的支出上限以及持续时间。当代理的任务开始时,会话 ID 和工具 ID 将传递给代理。代理不能延长其会话,也不能超出会话支付限制。
# 创建一个支付会话
session_response = manager.create_payment_session(
user_id="test-user-123",
limits={
"maxSpendAmount": {
"value": "100.00",
"currency": "USD"
}
},
expiry_time_in_minutes=60
)Python
自主处理支付
当代理接收到用户任务时,它可能会调用付费端点来服务、API 或内容。那些付费端点以 402 Payment Required 状态响应给代理。AgentCore 支付理解 x402 支付协议,包括 x402 版本 1 和版本 2,并知道如何生成代理所需的支付证明以解锁服务。
代理调用 ProcessPayment,传入会话 ID、工具 ID 和 x402 支付负载。背后,AgentCore 支付协调支付处理。它提取执行加密交易所需属性,应用支付限制的保护措施,并对交易进行签名以生成支付证明。这种精心编排有助于验证即使多个代理在同一会话中同时交易,预算也不会超支。
payment_response = manager.process_payment(
user_id="user-123",
payment_session_id=PAYMENT_SESSION_ID,
payment_instrument_id=PAYMENT_INSTRUMENT_ID,
payment_input={
"cryptoX402": {
"version": "1",
"payload": {
"scheme": "exact",
"network": "base-sepolia",
"maxAmountRequired": "5000",
"resource": "https://premiousEndpoint",
"description": "Premium AI joke generation",
"mimeType": "application/json",
"payTo": PAY_TO_ADDRESS,
"maxTimeoutSeconds": 300,
"asset": "0xxxxxxxxxxxxxxxxxxxxxxxx",
"extra": {"name": "USDC", "version": "2"},
},
}
}
)Python
AgentCore 支付的使用案例
有了支付堆栈,您的代理可以通过单个 ProcessPayment 调用来处理 x402 支付。相同的构建块(第三方钱包、会话范围的预算和 x402 协议)支持各种代理工作负载。
负载 | 代理执行的操作 | 支付方式 研究代理 | 在预算内查询多个保险数据源以编译分析。通过HTTP或MCP调用付费API。支付插件处理每个来源的402检测、签名和重试。 财务分析代理 | 访问受付费墙保护的市场数据、交易服务和专有数据库。在同一支付堆栈中通过一个支付堆栈使用相同的支付模式,无论不同的商家如何。 浏览器代理 | 导航受付费墙保护的网站以从多个站点提取内容。在无头浏览器会话中拦截402,支付,并在重试时注入证明头。 按情报付费代理 | 将任务路由到最适合的AI模型,并按标记付费。每次调用时向模型提供商支付,而不是维护模型订阅。 按需存储代理 | 使用按用量定价提供临时存储。根据请求时间支付计算和存储资源,无需预先分配容量。
每个负载都使用相同的开发者面向的API。不同之处在于代理如何处理它所支付的内容,而不是如何支付。以下示例展示了可以为付费内容付款的研究代理。
深入了解:基于AI的研究助手
一位金融分析师问他们的AI代理:“分析亚马逊的股票并将其与行业基准进行比较。”
该代理需要三个付费来源:一个金融数据API(每查询一次$0.50)、一个供应链分析供应商(每份报告$1.20)和一个基准数据库(每组数据集$0.80)。应用程序后端创建一个带有$10.00预算的会话,并将会话ID和资产ID传递给代理。

_图6:展示从头到尾支付流程的研究助手架构。_
代理调用每个商家服务。每个服务返回HTTP 402。AgentCore支付原子地检查会话预算,通过配置的钱包提供商签名交易,并返回加密证明。代理使用证明重试并接收付费内容。三家商家,三次支付,每次调用一个API。总支出为$10.00预算中的$2.50,剩余$7.50。分析师在无需手动干预的情况下收到完整的分析。
开发者的整个支付流程贡献仅是一些插件配置行。代理的逻辑完全专注于研究质量:查询哪些来源、如何综合发现以及何时停止。
适用于任何框架和任何模型。 这个流程与您构建代理的方式无关。使用Strands代理,内置的AgentCorePaymentsPlugin自动处理支付处理。对于其他框架,ProcessPayment是一个标准的REST调用。模型选择也是如此。无论代理是否使用Anthropic Claude、OpenAI GPT、Google Gemini或Meta Llama,支付流程都是相同的。
与其他Amazon Bedrock AgentCore组件集成。 由于支付操作在工具调用层上运行,它们自然与其他AgentCore服务一起工作。首先参考前面的研究代理示例,然后叠加以下内容:
- AgentCore网关 – 在Coinbase x402 Bazaar上发现付费MCP工具,无需每个提供商注册。单个支付堆栈提供了超过10,000个端点的访问权限。
- AgentCore内存 – 在会话间存储研究结果。如果代理昨天已经购买了供应链报告,内存将检索结果。
- AgentCore工具 – 在同一工作流中使用托管工具,如浏览器和代码解释器。浏览器工具导航受付费墙保护的网站并在内容内进行支付。代码解释器处理付费数据:运行分析、生成图表和转换数据集。
ProcessPaymentAPI无论哪个工具触发支付都是相同的。 - AgentCore运行时 – 使用
agentcore deploy部署代理。ProcessPaymentRole在基础设施级别强制执行。
添加更多AgentCore功能不需要更改支付配置。有了支付基础设施管理,您可以专注于改进代理本身:增加新的数据源、优化合成逻辑并扩展到新领域。这里列出的AgentCore服务并不全面。随着服务的增长,相同的支付原语将扩展到新能力。
清理
使用完毕后清理资源,并参阅AgentCore定价获取更多关于成本的详细信息。
结论
在这篇文章中,我们介绍了AgentCore支付如何处理支付基础设施,以便您可以投资于真正重要的地方:构建能够大规模交易的代理。同一个支付堆栈不仅支持单个研究助手,还支持在AgentCore上部署的多代理系统,具有每个代理的预算、多提供商钱包和完整可观测性。
要开始实验,请参阅AgentCore支付样本仓库,它将您带过整个开发者旅程。样本还包括诸如代理为数据付费、为API付费和为内容付费等端到端用例模式,作为您自己的代理支付工作流的起点。
使用这些资源开始:
* [AgentCore 支付文档](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments.html)
* [AgentCore 支付 FSI 参会者大会主旨演讲](https://www.youtube.com/watch?v=uQpTC2PcWbI&t=3421s)
* [AgentCore 支付示例:教程和端到端用例模式](https://github.com/awslabs/agentcore-samples/tree/main/06-workshops/13-AgentCore-payments)
* [Amazon Bedrock AgentCore 文档](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html),探索网关、内存、工具和运行时,并扩展您的代理功能。
[AgentCore 支付](https://aws.amazon.com/blogs/machine-learning/agents-that-transact-introducing-amazon-bedrock-agentcore-payments-built-with-coinbase-and-stripe/) 现正处于预览阶段。开始构建能够进行交易的代理。
* * *
## 关于作者