AgentCore Payments: Cuando Tu Agente Tiene Su Propia Wallet 💸

Imagina esto. Construiste un agente de análisis crediticio para tu fintech. Funciona hermoso en demo: razona, llama herramientas, escribe un dictamen. Pero cuando lo llevas a producción te das cuenta del problema real — el agente necesita datos. Datos de un bureau regional que cobra USD $0.015 por consulta. Una API de mercados que cobra fracciones de centavo por tick. Un proveedor de noticias financieras que pone paywall por artículo.

Y tu equipo termina haciendo lo que hacen todos los equipos: integrar billing manualmente con cada proveedor. Cuentas separadas, llaves rotadas a mano, presupuestos en hojas de cálculo, alertas que llegan tarde, un PR cada vez que aparece un proveedor nuevo. Meses de ingeniería que no agrega valor a tu producto — solo plomería.

El 7 de mayo de 2026, AWS anunció en preview Amazon Bedrock AgentCore Payments, construido en sociedad con Coinbase y Stripe. Y por primera vez tu agente puede tener algo que suena absurdo cuando lo dices en voz alta: su propia wallet.

Vamos a ver por qué esto no es una curiosidad cripto, sino un cambio arquitectónico real para cualquiera que esté construyendo agentes en producción.

Una aclaración antes de empezar, porque importa: todo el código de este artículo fue ejecutado contra una cuenta AWS real en us-east-1, con bedrock-agentcore>=1.9.1 y strands-agents>=1.40.0. El flujo completo — agente → HTTP 402 → firma → settlement — terminó en una transacción real de 0.15 USDC en Base Sepolia que puedes verificar on-chain (tx 0x40bc...26e4). Al final del artículo hay una sección de notas de trinchera con todo lo que se rompió en el camino, que es donde está la mitad del valor.

🎯 ProTip #1: El problema que resuelve AgentCore Payments no es “agentes pagando con cripto”. Es la fricción económica de los micropagos máquina-a-máquina. Las tarjetas tradicionales tienen comisiones mínimas de 30 centavos por transacción — pagar 1.5 centavos por una consulta es matemáticamente imposible: la comisión mínima se come la transacción entera. Stablecoins sobre el protocolo x402 hacen el costo unitario viable.

El Desafío: La Economía Imposible del Pay-per-Call

Hay una verdad incómoda en cómo se está moviendo el ecosistema de APIs en 2026. Cada vez más proveedores están cambiando de modelo de suscripción a pay-per-use. Datos de mercado, scraping de contenido, MCP servers especializados, hasta tiempo de ejecución de modelos. La razón es directa: los agentes consumen cantidades impredecibles y a veces enormes, y los proveedores quieren cobrar por valor entregado, no por asientos.

Pero pay-per-use rompe en el caso de los micropagos. El dinero se mueve sobre lo que en el mundo financiero se llama un payment rail: la infraestructura concreta que transporta cada pago — la red de tarjetas, las transferencias bancarias, los procesadores. Y cada rail tradicional cobra una comisión mínima por transacción, de alrededor de 30 centavos. Cuando lo que quieres mover son 1.5 centavos, esa comisión mínima no es un detalle: supera al monto entero. El proveedor pierde dinero en cada llamada y la economía simplemente no cierra. x402 existe precisamente porque introduce un rail nuevo, nativo de internet, donde el costo unitario de mover fracciones de centavo sí es viable.

Hay además otro problema más sutil: la multiplicación de cuentas. Si tu agente puede llegar a necesitar datos de 50 proveedores distintos, ¿realmente vas a abrir 50 cuentas de billing, manejar 50 sets de credenciales, monitorear 50 dashboards y rotar 50 llaves API? Tu equipo de plataforma se va a quemar antes de llegar a 10.

El blog de lanzamiento de AWS lo dice bastante claro: tradicionalmente esto eran “meses de esfuerzo de ingeniería”, y las consecuencias de equivocarse son altas — un flujo de pago mal configurado no produce una mala respuesta, mueve dinero real.

🔍 ProTip #2: Cuando evalúes si tu organización necesita esto, no preguntes “¿tengo agentes que paguen?”. Pregunta “¿cuántos proveedores externos consumiría mi agente si la fricción de integración fuera cero?”. Esa segunda lista suele ser 5x más grande que la primera. Ese delta es la oportunidad real.

La Solución: El Protocolo x402 Revivido

Antes de entrar al servicio AWS, hay que entender el protocolo que lo hace posible — porque sin x402, AgentCore Payments sería solo otra capa de billing.

x402 reutiliza un status code HTTP que llevaba casi tres décadas durmiente: el famoso HTTP 402 Payment Required. Estaba en el estándar HTTP/1.1 desde fines de los 90, etiquetado como “reserved for future use”. Coinbase decidió que el futuro era ahora.

El flujo es elegantemente simple (describo x402 v2, la versión vigente del protocolo desde diciembre de 2025; v1 sigue soportada como legacy, y es la razón por la que vas a encontrar tutoriales viejos con nombres de header distintos):

1. Tu agente llama un endpoint pagado: GET /premium-data
2. El servidor responde HTTP 402 Payment Required con un header PAYMENT-REQUIRED (JSON en base64) que indica esquema de pago, red en formato CAIP-2 (eip155:84532 para Base Sepolia), contrato del activo, destinatario, monto y timeout
3. El agente firma una autorización de transferencia transferWithAuthorization (EIP-3009) con su wallet y la incluye en un header PAYMENT-SIGNATURE (en v1 legacy el header era X-PAYMENT)
4. El servidor le pasa esa firma a un facilitator (Coinbase hostea uno en https://x402.org/facilitator, gratis en testnet, pero la spec es abierta), que la verifica y la presenta on-chain — la mayoría de implementaciones corren sobre Base usando USDC
5. El servidor recibe la confirmación con el hash de la transacción, libera el contenido y responde 200 con los datos y un header PAYMENT-RESPONSE

Un detalle que sorprende la primera vez: la wallet del agente no necesita ETH para gas. La firma EIP-3009 es off-chain; quien paga el gas de presentar la transacción es el facilitator. El agente solo necesita el stablecoin que va a gastar.

Lo brillante es que todo esto ocurre en el mismo loop de razonamiento del agente. No hay redirección a un checkout, no hay confirmación humana, no hay sleep esperando aprobación. Para el agente, llamar un endpoint pagado se siente igual que llamar uno gratuito — solo que con un par de pasos extra que AgentCore maneja en background.

⚠️ ProTip #3: x402 no es un estándar AWS. Es un protocolo abierto gobernado por la x402 Foundation, donde AWS y Coinbase son miembros. Esto importa para tu decisión arquitectónica: el protocolo no te encadena a AgentCore. Si mañana migras a otro proveedor que soporte x402, los endpoints que ya consumes siguen funcionando. AWS está apostando a que su capa de gestión (gobernanza, identidad, observabilidad) sea suficiente diferenciador.

Anatomía del Servicio: Los Cinco Recursos que Necesitas

AgentCore Payments expone cinco conceptos que vas a manejar. Vale la pena mapearlos antes del código porque la separación es deliberada — cada uno corresponde a un nivel distinto de gobernanza.

PaymentCredentialProvider: vive en AgentCore Identity, no en Payments. Es donde guardas tus credenciales del proveedor de wallet (API keys de Coinbase CDP o credenciales de Privy para Stripe). Se almacena en Secrets Manager por debajo, y AgentCore lo referencia por ARN. Ningún componente que toca runtime ve directamente las credenciales.

PaymentManager: el recurso top-level en tu cuenta AWS. Define cómo los agentes se autentican al data plane (IAM o JWT personalizado) y el rol IAM que el servicio asume en runtime. Cuando lo creas, AgentCore provisiona automáticamente una workload identity en AgentCore Identity para ese manager. Una organización típicamente tiene varios PaymentManagers — por aplicación, por ambiente (dev/staging/prod) o por equipo.

PaymentConnector: la conexión entre tu PaymentManager y un proveedor de pagos externo. Cada connector apunta a un PaymentCredentialProvider y especifica si va contra Coinbase CDP o Stripe Privy. Un PaymentManager puede tener varios connectors (por ejemplo, uno para Coinbase y otro para Stripe). El mapeo connector → credential provider es 1:1.

PaymentInstrument: la wallet embebida de cada usuario final. Se crea vía API con el email del usuario como cuenta vinculada, y el proveedor (Privy en mi caso) aprovisiona la wallet por debajo. La respuesta incluye un redirectUrl al wallet hub hosted donde el usuario fondea la wallet y le otorga al agente el permiso de firmar. Sin ese grant explícito del usuario, el agente no puede mover un centavo — y vas a ver en las notas de trinchera que ese detalle no es decorativo.

PaymentSession: el contexto de gasto para una interacción individual del agente con un usuario final. Aquí vive el guardrail más crítico — el maxSpendAmount con su currency y el expiry. Cuando la sesión expira o el límite se alcanza, los siguientes intentos de pago son denegados deterministicamente en la capa de infraestructura. El agente no puede negociar consigo mismo para saltarse este límite.

🎓 ProTip #4: La distinción PaymentManager vs PaymentSession es la separación clásica de control plane vs data plane que ya conoces de otros servicios AgentCore. Los managers y connectors son setup de infraestructura — los creas una vez con Terraform o CDK. Las sessions son runtime — las creas y destruyes por cada interacción de usuario.

Implementación Paso a Paso

Voy a mostrar la integración mínima con Strands Agents — el SDK con el que AWS empuja más fuerte últimamente y el que mejor integra con AgentCore Payments. Todos los snippets que siguen fueron ejecutados contra la cuenta real; donde la documentación oficial y la API discrepan, gana lo que la API aceptó de verdad.

Paso 1: Configurar el PaymentCredentialProvider

Esto es operación de control plane. Lo haces una vez con tus credenciales del proveedor — yo elegí Stripe Privy para este experimento, y es el camino que validé de punta a punta hasta el settlement on-chain.

Primero necesitas las credenciales del lado Privy:

1. Crea una app dedicada en dashboard.privy.io (no reutilices apps que sirvan otros propósitos) y copia el App ID y el App Secret.
2. En Wallet Infrastructure → Authorization, genera un par de llaves P-256. Eso te da el Authorization ID y la Authorization Private Key.
3. La private key viene con el prefijo wallet-auth: — quítaselo antes de pasarla a AWS. La regex del API no acepta el : y el error que devuelve no te dice nada de esto.

import boto3

ctrl = boto3.client("bedrock-agentcore-control", region_name="us-east-1")

# Setup en control plane - corre una sola vez
provider = ctrl.create_payment_credential_provider(
    name="creditBureauResearchCreds",
    credentialProviderVendor="StripePrivy",
    providerConfigurationInput={
        "stripePrivyConfiguration": {
            "appId": "<PRIVY_APP_ID>",
            "appSecret": "<PRIVY_APP_SECRET>",
            "authorizationId": "<PRIVY_AUTH_ID>",
            # base64 puro, SIN el prefijo "wallet-auth:"
            "authorizationPrivateKey": "<PRIVY_AUTH_PRIVATE_KEY>",
        }
    },
)
CREDENTIAL_PROVIDER_ARN = provider["credentialProviderArn"]

Los secretos terminan en Secrets Manager (bajo el namespace bedrock-agentcore-identity!), y todo lo demás los referencia por ARN. Si prefieres Coinbase CDP, el vendor es CoinbaseCDP con coinbaseCdpConfiguration (campos apiKeyId, apiKeySecret, walletSecret) — ojo que no es un solo apiKey como sugieren algunos ejemplos tempranos.

Paso 2: Crear el PaymentManager y el Connector

Esto también es control plane. El PaymentManager define el authorizer (IAM en mi caso porque el agente corre dentro de AWS) y el rol IAM que el servicio asume en runtime para leer las credenciales.

Dos detalles que la documentación no destaca lo suficiente: el nombre del PaymentManager debe ser [a-zA-Z][a-zA-Z0-9]{0,47} — solo alfanumérico, sin guiones. Y la primera vez conviene crear el PaymentManager desde la consola, que genera el service role por ti con la trust policy y los permisos correctos (bedrock-agentcore:CreateWorkloadIdentity, GetWorkloadAccessToken, GetResourcePaymentToken). Si prefieres tu propio rol, la doc de IAM roles para payments tiene las policies exactas.

# Crear el PaymentManager (el tipo va en --authorizer-type, no en un JSON)
aws bedrock-agentcore-control create-payment-manager \
    --region us-east-1 \
    --name "researchAgentPayments" \
    --authorizer-type "AWS_IAM" \
    --role-arn "arn:aws:iam::123456789012:role/service-role/AgentCorePaymentsServiceRole"

# Crear el Connector que apunta al credential provider
aws bedrock-agentcore-control create-payment-connector \
    --region us-east-1 \
    --payment-manager-id "paymentmanager-a1b2c3d4e5" \
    --name "pocPrivyConnector" \
    --type "StripePrivy" \
    --credential-provider-configurations '[{
      "stripePrivy": {"credentialProviderArn": "<CREDENTIAL_PROVIDER_ARN>"}
    }]'

Al crear el connector, el servicio le agrega al service role los permisos para leer los secretos de ese credential provider específico. Guárdate ese dato: en las notas de trinchera vas a ver por qué importa.

El PaymentManager del POC en la consola, con su conector Stripe (Privy) en Ready. El “transaction error rate 82.9%” del panel de observabilidad es la cicatriz honesta del debugging — cada uno de esos errores está documentado en las notas de trinchera.

Paso 3: Crear el Payment Instrument

Aquí AgentCore aprovisiona la wallet embebida para tu agente. Cada usuario final tiene su propia wallet, identificada por userId. Esto se hace una vez por usuario, no por sesión.

Nota la forma real de los parámetros: el manager va por ARN (no por ID), el tipo es EMBEDDED_CRYPTO_WALLET, y la red a nivel de instrumento es ETHEREUM o SOLANA — Base no es una red separada aquí; a nivel x402 aparece como eip155:8453 (mainnet) o eip155:84532 (Sepolia).

import boto3, uuid

agentcore = boto3.client('bedrock-agentcore', region_name='us-east-1')

# Provisionar wallet embebida para el usuario final
instrument = agentcore.create_payment_instrument(
    paymentManagerArn='arn:aws:bedrock-agentcore:us-east-1:123456789012:payment-manager/paymentmanager-a1b2c3d4e5',
    paymentConnectorId='privy-x1y2z3w4v5',
    paymentInstrumentType='EMBEDDED_CRYPTO_WALLET',
    paymentInstrumentDetails={
        'embeddedCryptoWallet': {
            'network': 'ETHEREUM',
            'linkedAccounts': [
                {'email': {'emailAddress': 'cliente@fintech.com'}}
            ]
        }
    },
    userId='cliente-fintech-001',
    clientToken=str(uuid.uuid4()),
)

print(f"Wallet creada: {instrument['paymentInstrumentId']}")
print(f"Wallet hub:    {instrument['paymentInstrumentDetails']['redirectUrl']}")

Ese redirectUrl es el wallet hub del proveedor (al momento de escribir esto, el servicio aún no devuelve la URL para el conector StripePrivy — el camino real hoy es desplegar el template oficial de Privy, un Next.js que corre con tu App ID en minutos). Ahí el usuario final hace dos cosas: fondear la wallet (transferencia cripto, tarjeta, Apple Pay o ACH — en testnet, USDC gratis del faucet de Circle) y conectar el agente vía “Connect agent”, que agrega la authorization key de tu credential provider como signer autorizado de la wallet.

El wallet hub: crear wallets, conectar el agente y fondear. La wallet de $19.70 es la del agente del POC — empezó con $20.00 y ya pagó dos consultas de $0.15 al bureau. Este paso no es opcional ni saltable — es una decisión consciente de AWS: el agente nunca tiene acceso a los fondos sin consentimiento explícito del usuario. Si te lo saltas, ProcessPayment falla con un AccessDeniedException: "Privy credentials are invalid" que no menciona permisos por ningún lado. Me costó una noche entera entender eso.

Paso 4: Crear la PaymentSession con Límites

Aquí es donde la mayoría de los CTOs respiran tranquilos. Cada sesión tiene un límite de gasto que se enforza en la capa de infraestructura — no en el código del agente, donde un prompt injection podría intentar bypasearlo.

Detalle importante: la sesión no está atada a un instrumento — se crea por usuario, y el instrumento se especifica solo al procesar el pago. El expiry va en minutos, no segundos:

# Crear una sesión con presupuesto definido
resp = agentcore.create_payment_session(
    paymentManagerArn='arn:aws:bedrock-agentcore:us-east-1:123456789012:payment-manager/paymentmanager-a1b2c3d4e5',
    userId='cliente-fintech-001',
    expiryTimeInMinutes=30,
    limits={
        'maxSpendAmount': {
            'value': '5.00',     # objeto Amount, no string plano
            'currency': 'USD'
        }
    },
)
session = resp['paymentSession']

print(f"Sesión: {session['paymentSessionId']}")
print(f"Presupuesto: USD {session['limits']['maxSpendAmount']['value']}")

Después de cada pago, get_payment_session te devuelve availableLimits.availableSpendAmount — el presupuesto restante. En mi prueba: $2.00 → $1.85 después de una consulta de $0.15, decrementado por el servicio, no por mi código.

Paso 5: Integración con el Agente Strands

Esto es lo bonito. Una vez configurado todo lo anterior, agregar pagos automáticos al agente son seis líneas:

from strands import Agent
from strands_tools import http_request
from bedrock_agentcore.payments.integrations.config import (
    AgentCorePaymentsPluginConfig
)
from bedrock_agentcore.payments.integrations.strands.plugin import (
    AgentCorePaymentsPlugin
)

# Configurar el plugin con los recursos creados arriba
config = AgentCorePaymentsPluginConfig(
    payment_manager_arn="arn:aws:bedrock-agentcore:us-east-1:123456789012:payment-manager/paymentmanager-a1b2c3d4e5",
    user_id="cliente-fintech-001",
    payment_instrument_id=instrument["paymentInstrumentId"],
    payment_session_id=session["paymentSessionId"],
    region="us-east-1",
)

# El plugin intercepta automáticamente las respuestas HTTP 402
plugin = AgentCorePaymentsPlugin(config=config)

# Agente de análisis crediticio para fintech LATAM
agent = Agent(
    system_prompt="""Eres un analista de riesgo crediticio. Cuando te piden 
    evaluar a un solicitante, consultas el bureau regional para obtener score 
    actualizado y noticias relevantes. Justifica tu dictamen con datos 
    específicos del bureau.""",
    tools=[http_request],
    plugins=[plugin],
)

# Caso de uso real: análisis de un solicitante
respuesta = agent("""
    Analiza el perfil crediticio del solicitante con ID 12345678.
    Necesito score actualizado del bureau y cualquier flag reciente.
    Usa el endpoint: https://api.mi-bureau.com/v2/credit-report
""")

Lo que pasa cuando el agente llama el endpoint (lo verifiqué transacción por transacción):

1. La herramienta http_request hace GET al endpoint del bureau
2. El bureau responde HTTP 402 con el header PAYMENT-REQUIRED pidiendo USD 0.15 en USDC
3. El plugin de AgentCore Payments intercepta la respuesta antes de que llegue al loop del agente, parsea los accepts y selecciona la red compatible con el instrumento
4. Llama ProcessPayment: el servicio valida la request, verifica el presupuesto (USD 0.15 < USD 5.00 disponibles, sigue), y firma la autorización EIP-3009 con la wallet Privy del usuario — la respuesta vuelve con status: PROOF_GENERATED
5. El plugin reintenta la llamada con el header PAYMENT-SIGNATURE adjunto
6. El bureau valida la prueba con el facilitator, la liquida on-chain, y devuelve los datos con el txHash en PAYMENT-RESPONSE
7. El agente recibe los datos como si la llamada hubiera sido directa

El agente no sabe que pagó — solo sabe que obtuvo los datos. En mi corrida, el dictamen crediticio del agente cerraba con una línea que me sigue gustando: “Costo de consulta bureau: USD $0.15 (liquidado on-chain en Base Sepolia)”.

🔧 ProTip #5: El expiryTimeInMinutes de la PaymentSession es tu mejor amigo en producción. Va en minutos (15 es el mínimo que acepta el API, 480 el máximo). Para un agente síncrono de research, el mínimo de 15 minutos sobra. Para un agente de análisis de larga duración, puedes extender hasta las 8 horas. No uses sesiones eternas — el blast radius si una sesión se compromete escala linealmente con su duración.

Qué Vas a Ver en Runtime

Tres comportamientos que vas a observar cuando lleves esto a un PoC, y que verifiqué en la corrida real:

El overhead por pago es de pocos segundos por transacción. El blog oficial de AWS para Financial Services menciona “sub-2-second settlement” para una transacción x402; en mi prueba real, el ciclo completo 402 → ProcessPayment → retry → settlement on-chain en Base Sepolia tomó del orden de 3-5 segundos (la firma vía ProcessPayment es rápida; la confirmación on-chain depende de la red). Para un agente que hace 5-6 llamadas pagadas en una sesión, el overhead acumulado no es despreciable cuando tu UX es interactiva — diseña pensando en async cuando sea posible, o muestra un indicador de progreso explícito al usuario final.

Los límites se enforzan deterministicamente en la capa de infraestructura. Cuando configuras maxSpendAmount en la PaymentSession, AgentCore Payments verifica el presupuesto en cada ProcessPayment antes de firmar la transacción. Si la operación excedería el presupuesto, el API devuelve un ValidationException indicando presupuesto insuficiente (el SDK de Strands lo convierte en una excepción InsufficientBudget y levanta un interrupt que tu aplicación puede manejar). Esto vive fuera del alcance del LLM — no hay prompt injection que pueda bypasear un límite que está enforzado del lado del servicio. Si vas a probar esto, vale la pena hacer el experimento explícito: configura un límite bajo, instruye al agente a “ignorar restricciones de presupuesto” y observa que el bloqueo es absoluto.

La observabilidad llega gratis a CloudWatch. Cada transacción genera vended logs y traces de X-Ray. Vas a poder ver, transacción por transacción, el monto exacto, el endpoint pagado, la latencia de firma, la latencia de settlement y el balance restante de la sesión. Para auditoría financiera esto es no-negociable, y AgentCore lo da sin que tengas que escribir una línea de código adicional.

El dashboard del PaymentManager del POC: invocaciones, transacciones, sesiones con presupuesto, errores por tipo, throttles y latencia de invocación (~286ms). Todo esto sin escribir una línea de instrumentación.

💡 ProTip #6: Cuando vayas a probarlo, agenda explícitamente un experimento de “presupuesto excedido”. No es paranoia — es la forma más rápida de validar que tu integración respeta los límites antes de conectarla a un endpoint real con dinero real. Hazlo con un mock endpoint que devuelva 402 con un monto fijo, y observa el comportamiento cuando tu sesión se queda sin presupuesto. Esa prueba te ahorra el día que un agente en producción intente vaciar una wallet por un bug en el prompt.

Notas de Trinchera: Lo Que Se Rompió Antes de Funcionar

Esta sección no existe en el blog de lanzamiento de AWS, y es exactamente por eso que la escribo. Entre el “hello world” de la documentación y la primera transacción real on-chain hubo varias horas de debugging repartidas en varias sesiones. Estos son los cuatro hallazgos que te van a ahorrar ese tiempo.

1. La dirección del token importa, carácter por carácter

Mi mock server publicaba como asset la dirección de USDC en Base Sepolia… con un typo en el último carácter (...f3dCF71 en lugar de la canónica ...f3dCF7e). El error nació de un “fix” anterior: una dirección que había quedado con 39 caracteres hex, a la que le agregué el dígito que faltaba — el equivocado.

La buena noticia: el servicio hoy valida esto y el error te da la respuesta completa:

ValidationException: Payment asset is not a supported USDC token address
for network 'eip155:84532'.
Received: 0x036cbD53842c5426634e7929541eC2318F3DCF71.
Expected: 0x036CbD53842c5426634e7929541eC2318f3dCF7e

Lección: no tipees direcciones de contratos a mano. Tómalas del registro oficial de Circle y verifica el checksum.

2. Un checksum EIP-55 inválido te da un 500 sin pistas

El payTo de mi servidor de prueba era una dirección escrita a mano con las mayúsculas “a ojo” — checksum EIP-55 inválido. ¿El resultado? No un error de validación: un InternalServerException: Something went wrong in processing your request, con reintentos automáticos del SDK incluidos. Cuatro variantes del payload después, la única diferencia entre mi llamada que funcionaba y la que explotaba era el casing de la dirección destino.

Lección: si ProcessPayment te tira 500 genéricos, valida el checksum de todas las direcciones del payload (con eth_utils.to_checksum_address o equivalente) antes de sospechar del servicio.

3. La trampa IAM: recrear el CredentialProvider rompe el service role

Esta es la más sutil y la más valiosa. Cuando creas un PaymentConnector, el servicio le agrega al service role del PaymentManager una policy con permisos sobre los secretos específicos de ese credential provider (secretsmanager:GetSecretValue sobre ARNs concretos, más bedrock-agentcore:GetResourcePaymentToken).

Durante el debugging roté credenciales: borré y recreé el credential provider con el mismo nombre. Los secretos backing en Secrets Manager se recrearon con ARNs nuevos… pero la policy del rol siguió apuntando a los viejos. Resultado en runtime:

AccessDeniedException: Failed to obtain resource payment token.

Un error que no menciona ni IAM, ni secretos, ni el credential provider. El fix es actualizar a mano la policy AmazonBedrockAgentCorePaymentConnectorPolicyProd_* con los ARNs nuevos — o recrear el connector para que el servicio re-aprovisione los permisos.

Lección: el aprovisionamiento de permisos por-conector ocurre solo al crear el conector. Si rotas o recreas el credential provider, el rol queda huérfano y nada te lo advierte.

4. La prueba final: settlement real verificable on-chain

Con todo lo anterior resuelto, el ciclo completo quedó así: el agente Strands recibió el 402, el plugin llamó ProcessPayment (respuesta: PROOF_GENERATED con la autorización EIP-3009 firmada por la wallet Privy), reintentó con PAYMENT-SIGNATURE, y mi servidor liquidó el pago con el facilitator hosted de x402 — que presentó la transferWithAuthorization on-chain pagando él el gas.

La evidencia es pública y verificable:

• Transacción: 0x40bc34959ec85efbb4a0afa61c3735e17beadc2a6967d288a6149e89138526e4 (Base Sepolia, status success)
• Transfer: wallet del agente → merchant, 0.15 USDC
• Saldos: agente 20.00 → 19.85 USDC; merchant 0.00 → 0.15 USDC
• Presupuesto de sesión: $2.00 → $1.85, decrementado por AgentCore

Y como un solo punto de datos no es evidencia, lo corrí de nuevo: segunda liquidación, mismo flujo, saldo del agente ahora en 19.70 USDC.

La liquidación vista en Basescan: transfer de 0.15 USDC desde la wallet del agente al merchant. Fíjate en el “Value: 0 ETH” y el “From” que no es la wallet del agente — quien presenta la transacción (y paga el gas) es el facilitator; la wallet del agente solo firmó la autorización EIP-3009.

Del lado merchant usé el paquete oficial x402 de PyPI (de la x402 Foundation): los schemas v2 y el cliente del facilitator vienen listos, y el header PAYMENT-SIGNATURE que genera el plugin de AgentCore valida directo contra el schema PaymentPayload del paquete. AWS y el ecosistema x402 abierto son interoperables de verdad, no solo en el slide.

Dos sutilezas más que descubrí en esta etapa: el facilitator hosted soporta x402 v2 con identificadores CAIP-2 (eip155:84532), pero para v1 legacy solo acepta el naming viejo (base-sepolia) — si tu merchant sirve v1 con CAIP-2, el settle falla. Y ProcessPayment genera la prueba firmada aunque la wallet tenga saldo cero (la firma es off-chain); el saldo solo importa cuando el facilitator intenta liquidar. No asumas que PROOF_GENERATED implica fondos.

🧪 ProTip #7: Si desarrollas en Windows, corre los demos con PYTHONUTF8=1. La consola en cp1252 crashea con el primer emoji que el modelo decida poner en su respuesta — y los modelos aman los emojis.

Lecciones a Tener en Cuenta Antes de Producción

El modelo de wallet por usuario genera fricción de onboarding. Cada usuario final tiene que pasar por el wallet hub para fondear y autorizar al agente. Eso es UX adicional que tienes que diseñar en tu producto. Para una fintech con miles de usuarios, vale la pena evaluar si el modelo embebido (donde tu app abstrae completamente la wallet detrás de tu UI) o el modelo connect (donde el usuario trae su propia wallet) encaja mejor con tu flujo de KYC y onboarding existente.

Las regiones disponibles son limitadas en preview. us-east-1, us-west-2, eu-central-1 y ap-southeast-2. Si tu workload tiene data residency requirements en Brasil o México, hoy no puedes usar AgentCore Payments directamente desde esas regiones. Tu opción es cross-region invocation desde Lambda en LATAM hacia el agente en us-east-1, asumiendo el costo de latencia adicional.

El x402 Bazaar es interesante pero todavía angosto. Se publicita “10,000+ endpoints x402” disponibles a través del Bazaar MCP server, pero la realidad es que la mayoría son endpoints de Coinbase y proveedores cripto-nativos. Para proveedores tradicionales de datos financieros LATAM (bureaus regionales, fintechs latinoamericanas), la adopción de x402 está empezando. Esto va a cambiar rápido, pero hoy probablemente tengas que conversar con tus proveedores existentes para que implementen x402 — o levantar un adapter intermedio que traduzca tu billing actual a x402.

El costo real por transacción no es el gas — es la wallet operation fee del proveedor. Aquí hay un detalle que cambia el modelo económico y que conviene tener claro antes de prometerle números a tu CFO. El gas on-chain sobre Base es marginal: el blog oficial de AWS para Financial Services menciona ~USD $0.0001 por settlement. Pero ese no es el costo dominante. Cada ProcessPayment dispara una operación de wallet en tu proveedor, y eso se cobra aparte: al momento de escribir esto, Coinbase CDP cobra del orden de USD $0.005 por wallet operation, y Stripe Privy tiene su propia fee por ProcessPayment. Para una consulta de $0.15 eso es ~3% de overhead; pero para el caso de fracciones de centavo del ProTip #1 — pagar $0.015 por un tick de datos — esos $0.005 son un tercio del costo de la transacción. La conclusión práctica: x402 hace viable el micropago frente a la tarjeta tradicional, pero la wallet operation fee del proveedor define tu piso real. Por debajo de cierto ticket, ni x402 cierra la economía. Modela ese costo por proveedor antes de comprometerte a un volumen.

🚨 ProTip #8: Si vas a llevar esto a producción, decide desde el día uno cómo vas a reflejar las transacciones de la wallet del agente en tu contabilidad. Cada llamada pagada es un gasto real que tu sistema financiero tiene que reconciliar. Las APIs de Coinbase CDP y Stripe Privy permiten exportar el historial completo de transacciones — agenda un job de reconciliación nocturno desde el día uno o vas a estar pagando un consultor forense seis meses después para reconstruir qué pasó.

La Foto Completa: Pagos como la Cuarta Capa de un Agente

Si sigues esta serie, ya cubrimos las tres capas de estado de un agente en AgentCore:

• AgentCore Policy — Lo que el agente puede hacer
• AgentCore Memory Episódica — Lo que el agente aprendió
• AgentCore Session Storage — Lo que el agente construyó

AgentCore Payments agrega una cuarta capa que cambia cualitativamente lo que un agente puede hacer:

• AgentCore Payments — Lo que el agente puede adquirir

Y esa palabra, adquirir, es la que vuelve esto interesante. Un agente con razonamiento, herramientas, memoria y filesystem es un agente sofisticado. Un agente con razonamiento, herramientas, memoria, filesystem y la capacidad de pagar por recursos es algo cualitativamente distinto — es un actor económico autónomo dentro de límites que tú defines.

Para un CTO de fintech LATAM, eso abre un espacio de diseño nuevo. Tu agente de análisis crediticio puede consultar bureaus regionales bajo demanda en lugar de mantener suscripciones planas. Tu agente de research de mercados puede pagar por feeds de tick data solo cuando hay volatilidad real. Tu agente de KYC puede consultar listas OFAC pagadas en tiempo real sin que tu equipo de plataforma haya integrado cada proveedor a mano.

La pregunta arquitectónica importante no es “¿debería usar AgentCore Payments?”. Es “¿cuántos contratos plan-based estoy pagando hoy de los que ya pasaría a pay-per-call si la fricción técnica fuera cero?”.

Esa lista, en tu propia organización, probablemente sea más larga de lo que imaginas.

Conclusión

AgentCore Payments todavía está en preview. Las regiones son limitadas, el ecosistema de proveedores x402 está empezando, y va a haber gotchas que descubrirás solo cuando lo metas en tu propio caso de uso. Pero el cambio que representa no es cosmético.

Es la primera vez que una nube hyperscaler trata “pagar por algo” como una primitiva de plataforma con la misma calidad de gobernanza que el resto de los recursos AWS — identity, observability, IAM, audit trails. Antes era plomería que cada equipo construía. Ahora es un servicio gestionado, con todas las limitaciones y ventajas que eso implica.

Para CTOs y arquitectos cloud evaluando dónde meter la próxima inversión en agentes, mi sugerencia honesta: agenda una semana para hacer un PoC con un caso de uso concreto. No con el caso de uso final perfecto — con el más simple que puedas armar. Vas a aprender más sobre las implicaciones reales en 5 días de tener-tu-agente-pagando-cosas que en 5 meses de leer blogposts (incluido este).

Y si esa primera semana te convence — y vale la pena ver qué dices después de la primera transacción exitosa de 1.5 centavos — entonces empieza a diseñar la pregunta más interesante: qué tipo de producto puedes construir tú que hoy es imposible porque la fricción de pagos era el bloqueador.

Esa pregunta sigue sin respuesta para la mayoría de las organizaciones. Y el primero en responderla en tu vertical probablemente se quede con ese mercado.

¿Estás evaluando AgentCore Payments en tu organización? ¿Tu caso de uso son micropagos de datos, transacciones comerciales, o algo todavía más extraño? Me interesa saber qué están considerando — los comentarios están abiertos.

¡Nos vemos en el próximo artículo! 🚀

Recursos Oficiales 📚

• Blog de lanzamiento: Agents that transact
• Documentación oficial: AgentCore Payments
• Get started con AgentCore Payments
• IAM roles para AgentCore Payments — el modelo de 4 roles y los permisos por-conector
• Procesar un pago (formatos v1/v2 de ProcessPayment)
• Especificación x402 Protocol
• Paquete x402 en PyPI — schemas, middleware y cliente de facilitator
• Coinbase x402 Bazaar
• USDC contract addresses (Circle)
• Faucet de USDC testnet (Circle)