¿El agente de IA usará tarjetas bancarias?
¿Por qué el pago agentico no puede evitar las monedas estables y la cadena de bloques?

Autor: Yokiiiya

La semana pasada en Hong Kong participé en el Web3 Festival, y una sensación muy clara fue: ahora casi en cada foro, en cada panel, no se puede evitar hablar de IA.

No importa si originalmente se trataba de pagos, stablecoins, RWA, wallets, exchanges, o regulación e infraestructura, al final casi siempre vuelven a la misma pregunta: cuando la IA deja de ser solo generadora de contenido y empieza a ejecutar tareas, llamar servicios, tomar decisiones, e incluso gestionar flujos de dinero, ¿los sistemas financieros y de pago actuales son suficientes?

En uno de los paneles en los que participé, alguien también planteó directamente una pregunta: ¿Web3 está aprovechando la IA? Creo que no. Claro, algunos proyectos que quieren aprovechar la tendencia seguramente existirán. Pero si solo entendemos IA × Web3 como un collage narrativo, podemos estar perdiendo un cambio más profundo: la IA encargada de entender, decidir y actuar, y Web3 que provee activos, cuentas, liquidaciones y entornos verificables de ejecución. No son conceptos simplemente apilados, sino que están en una redistribución de roles.

El Secretario de Finanzas de Hong Kong, Paul Chan, también mencionó en su discurso en Web3 Festival 2026 que en el futuro los agentes de IA analizarán información a velocidad de máquina y tomarán acciones, aprovechando al mismo tiempo la infraestructura blockchain en segundo plano, para mejorar la eficiencia de las transacciones y transformar escenarios como finanzas, comercio, gestión de patrimonio, cadenas de suministro y logística. Cuando la IA empieza a actuar, el problema ya no es solo la “inteligencia” en sí, sino cómo se autoriza, liquida, registra y responsabiliza esas acciones.

Entre los temas que cada vez se vuelven más relevantes está el de Agentic Payment. Pero al principio también me surgió una duda sencilla: ¿por qué cuando hablamos de Agentic Payment o Agentic Commerce, parece que damos por hecho que siempre van ligados a Crypto, Stablecoins y Blockchain?

¿No puede un agente de IA usar una tarjeta bancaria? ¿No puede usar una tarjeta de crédito? ¿No puede usar Apple Pay, Visa, Mastercard, Stripe, PayPal?

Si un agente solo ayuda a comprar un billete de avión, reservar un hotel, o renovar un SaaS, en teoría puede llamar a los sistemas de pago existentes. El usuario autoriza una vez, el agente ejecuta el pago dentro de límites y reglas, y detrás puede usar tarjetas, tarjetas virtuales, cuentas empresariales o wallets de terceros. No parece tener nada de raro.

Por lo tanto, la cuestión no es “¿puede usarse la tarjeta?”. Claro que sí. La verdadera pregunta es: ¿en qué parte del proceso de Agentic Payment la tarjeta o la tarjeta de crédito son adecuadas, y en qué parte no? ¿Realmente el agente de IA usará tarjetas? ¿Y por qué cuando el desarrollo de Agentic Payment llega a cierto punto, casi siempre termina inevitablemente ligado a stablecoins y blockchain?

Primero, la tarjeta resuelve el checkout, no la economía de agentes

Si el Agentic Payment solo ayuda a completar la última etapa de pago, como comprar un billete, reservar un hotel o renovar un SaaS, usar tarjetas, tarjetas virtuales, Apple Pay, Stripe, PayPal, no tiene un obstáculo fundamental. La tarjeta puede usarse, la tarjeta de crédito también.

El usuario autoriza una vez, el agente ejecuta el pago dentro de límites y reglas. Esto no es difícil de entender, es como un débito automático más inteligente, una tarjeta virtual empresarial, una tarjeta de viaje o un sistema de compras automatizadas.

Por eso, los actores tradicionales como Visa, Mastercard, Stripe no desaparecerán. Incluso, serán una puerta de entrada importante en las primeras etapas del comercio agentico.

El protocolo Machine Payments de Stripe y Tempo lo demuestra claramente. No se trata solo de stablecoins, sino de que los comerciantes puedan aceptar pagos directamente de agentes, soportando tanto stablecoins como métodos de pago tradicionales como tarjetas, BNPL, etc. Es decir, en las fases iniciales del Agentic Payment, la coexistencia de pagos tradicionales y stablecoins es más probable que una sustitución inmediata. Pero esto solo cubre una parte del proceso: checkout.

El checkout presupone que los productos, comerciantes, pedidos, botones de pago, reembolsos y procesos de disputa ya existen. El agente solo acompaña al usuario, ayudándole a automatizar la compra.

El verdadero escenario problemático es otro: el agente ya no solo entra en un carrito prearmado, sino que en una red abierta llama recursos, combina servicios y completa tareas de forma continua.

Por ejemplo, un agente de investigación IA que necesita hacer un informe sectorial puede tener que llamar varias bases de datos, comprar varias fuentes de pago, acceder a diferentes APIs de modelos, usar servicios de scraping, pagar herramientas de generación de gráficos, e incluso comprar análisis a otro agente. En estos casos, quizás no exista una “tienda” tradicional, ni una página de checkout completa. Lo que enfrenta puede ser API, interfaces de datos, servicios de modelos, nodos de computación, recursos de contenido, herramientas automatizadas, e incluso otro agente.

Recientemente también me encontré con un ejemplo concreto: quiero crear un asistente de análisis de tráfico que pueda, cuando sea necesario, llamar automáticamente a fuentes de datos como Semrush, para analizar tráfico, palabras clave, competidores y tendencias del mercado. Pero al empezar a planear, descubrí que el problema no era “¿puede la IA analizar?”, sino “¿cómo obtiene los datos?”. Muchas fuentes comerciales no están diseñadas para llamadas únicas, pago por uso y respuesta instantánea. Por ejemplo, Semrush tiene un sistema API más parecido a cuentas, planes y unidades de API. Cada request consume unidades, y el usuario necesita tener acceso API o comprar paquetes de unidades. Aunque se pueda comprar acceso a Trends API por separado, sigue basado en unidades.

Para un agente, este modelo no es natural. Si solo necesita llamar ocasionalmente a datos de tráfico, lo que realmente necesita no es registrarse en un SaaS ni comprar un paquete completo de unidades, sino hacer una simple petición: ¿cuánto cuesta esto? ¿Estoy autorizado a comprarlo? Si está dentro del presupuesto, pago y obtengo los datos al instante.

Aquí se evidencia la brecha entre Agentic Payment y los modelos tradicionales de API. La mayoría de las tarifas API actuales están diseñadas para “empresas humanas comprando software”, no para “máquinas comprando recursos bajo demanda”.

Por eso, el problema de Agentic Payment no es solo si se puede hacer un cargo en el último paso, sino cómo en toda la cadena de tareas la máquina obtiene autorización, inicia pagos, verifica entregas y completa liquidaciones.

Aquí radica el límite del sistema de tarjetas.

No porque sean obsoletas, sino porque están diseñadas para escenarios de consumo humano: una persona entra en un comercio, selecciona productos, confirma pedido, paga, y luego el banco, la red de tarjetas, el adquirente y el proveedor de pagos se encargan de autorizar, liquidar, gestionar riesgos y disputas.

Pero la economía de agentes enfrenta otro conjunto de problemas: ¿Por qué un agente tiene derecho a gastar ese dinero? ¿Cómo confirma el proveedor que no es un bot malicioso, sino una extensión de la intención real del usuario? ¿Puede un agente, sin confirmación humana en cada paso, hacer pagos pequeños, frecuentes, en múltiples plataformas? ¿El proveedor puede liberar recursos inmediatamente tras el pago? Si el agente compra mal, excede permisos o es atacado, ¿quién asume la responsabilidad?

Por eso, cuando Google desarrolló AP2, no se centró en “qué método de pago usar”, sino en un marco de confianza más general para pagos por agente. La definición oficial de AP2 es un marco “independiente del método de pago”, que permite a usuarios, comerciantes y proveedores de pago completar pagos liderados por agentes con mayor confianza. La especificación también establece que el agente necesita un método seguro y sencillo para obtener permisos limitados, que le permitan actuar en nombre del usuario; la seguridad del protocolo depende de firmas criptográficas del usuario y del comerciante.

Por eso, la primera pregunta en Agentic Payment no es: ¿de dónde sale el dinero? sino: ¿por qué el agente tiene derecho a gastar ese dinero?

El sistema de tarjetas puede resolver parte de esto. Por ejemplo, tarjetas virtuales, credenciales tokenizadas, gestión de límites, control de gastos empresariales, reglas de riesgo, permiten que un agente realice transacciones en los sistemas existentes.

Visa también avanza en esa dirección. Su protocolo Trusted Agent y la iniciativa Intelligent Commerce buscan que los agentes IA puedan ser reconocidos, confiables y autorizados en la red de comerciantes actual. La descripción de Visa Developer sobre Trusted Agent Protocol dice que los agentes IA ayudarán a los usuarios a navegar, descubrir productos, comparar precios y tomar decisiones, antes incluso del checkout; pero estas interacciones automáticas a menudo son bloqueadas por los sistemas anti-bot o CDN.

Esto indica que las redes de pago tradicionales también ven el mismo problema: el comercio agentico no solo sucede en el momento del botón de pago, sino en toda la cadena desde búsqueda, comparación, autorización, hasta la liquidación final. Pero las redes de tarjetas están mejor preparadas para integrar cómo un agente entra en el flujo de comercio existente y realiza una transacción autorizada. No resuelven naturalmente cómo un agente en una red abierta puede hacer pagos pequeños y continuos a través de APIs, datos, modelos, recursos computacionales, contenido, o incluso otro agente.

Por eso, las tarjetas no son inviables. Más bien, resuelven el checkout del comercio agentico, pero lo que necesita la economía de agentes es un protocolo de pago más profundo.

Este lleva la discusión a otro nivel: si el objeto de la transacción no es un comerciante tradicional, sino una API, un modelo, un recurso de datos, o incluso otro agente, ¿cómo inician y completan pagos entre máquinas? Por eso se empiezan a discutir protocolos como x402, L402, T402.

Segundo, lo que realmente necesita un agente es un protocolo de pago legible por máquinas

Si el objeto de la transacción es un comerciante tradicional, el agente puede usar los flujos existentes de checkout, con tarjetas, virtuales o wallets. Pero si el objeto es una API, un modelo, un recurso de datos, o incluso otro agente, la cosa cambia.

Aquí, lo que las máquinas necesitan no es un “botón de pago”, sino un proceso de pago que puedan entender: el agente solicita un recurso. El proveedor responde: “esto requiere pago, cuánto cuesta, cuál es la dirección de pago, qué métodos soporta”. El agente evalúa si la compra está autorizada por el usuario. Si cumple las reglas, paga. El proveedor verifica el pago y libera el recurso inmediatamente.

Este proceso, aunque simple en apariencia, llena un vacío en la infraestructura de internet: la capa nativa de pagos. Antes, internet soportaba naturalmente el flujo de información: páginas, correos, APIs, archivos. Pero “pago” no era parte del protocolo, sino algo externo: registrarse, vincular tarjeta, acceder a pasarelas, comprar planes, gestionar API keys, hacer conciliaciones.

Para los humanos, esto es tolerable. Registrarse, loguearse, vincular tarjeta, aprobar, comprar, reembolsar. Es pesado, pero funciona. Para los agentes, esto es demasiado.

Un agente no debería tener que registrarse en cada API, ni comprar un plan completo por cada llamada, ni pasar por todo el proceso de pago y compra por unos centavos. Ahí surge la necesidad de protocolos como x402.

x402 reactiva el código de estado HTTP 402 Payment Required, que ha existido mucho tiempo pero rara vez se usó en realidad. Permite que el servidor indique en la capa HTTP: “esto requiere pago previo”. El cliente puede ser humano o máquina. Tras pagar, el servidor verifica y entrega el recurso.

Coinbase define x402 como un protocolo abierto para pagos instantáneos y automáticos en stablecoins, que permite a clientes humanos y máquinas pagar y acceder a recursos sin necesidad de cuentas, sesiones o autenticaciones complejas.

Lo importante no es si se usa Coinbase o USDC, sino que x402 integra el pago en el ciclo de petición-respuesta de internet.

Antes:

• Registrarse.
• Comprar plan.
• Obtener API key.
• Solicitar servicio.
• Conciliar al final del mes.

Ahora:

• Solicitar recurso.
• Recibir 402 Payment Required.
• Pagar.
• Obtener recurso.

Esto es clave para Agentic Payment, porque los agentes no solo hacen unas pocas compras grandes, sino muchas llamadas pequeñas, en tiempo real, bajo demanda.

Por ejemplo:

• Un agente de escritura compra una consulta de datos.
• Un agente de investigación realiza un análisis en cadena.
• Un agente de viajes consulta precios en varios sitios.
• Un agente de desarrollo compra modelos, revisiones o entornos de prueba.
• Un agente de análisis de tráfico solo quiere pagar una vez por Semrush, no toda la suscripción.

Si cada servicio requiere cuentas, suscripciones, API keys, aprobaciones manuales, la ejecución del agente se atasca en pagos y compras. Por eso, x402 no busca hacer los pagos “más cripto”, sino hacer que sean más como un protocolo de internet: solicitables, verificables, automáticos.

L402 sigue una línea similar, combinando HTTP 402 con Lightning Network y macaroons, para facilitar autenticación y micropagos en APIs y recursos computacionales. Lightning Labs define L402 como un protocolo para facilitar la autorización y pago en APIs y recursos, permitiendo a los agentes IA cobrar por sus llamadas.

Esto demuestra que no es que x402 haya sido inventado ayer, sino que ya existía la idea de combinar control de acceso, micropagos y permisos digitales, solo que antes faltaba un demandante fuerte.

Los humanos no pagan unos centavos por acceder a un API, pero los agentes sí. No llaman cientos de fuentes automáticamente, pero los agentes sí. No combinan llamadas, cotizaciones y pagos en tiempo real, pero los agentes sí.

Por eso, la aparición de los agentes IA hace que la idea de pagos nativos en internet tenga sentido.

En el ecosistema Tether, también surge una línea similar. El documento x402 de Tether WDK señala que x402 es importante para los agentes IA porque necesitan pagar programáticamente por recursos; permite que los pagos sean parte del stack web, y que en un ciclo request-response puedan descubrir precios, firmar pagos y obtener recursos. T402 se presenta como un estándar abierto para pagos nativos en internet, compatible con crypto, fiat, stablecoins y tokens.

Hay que ser cautelosos: no es que ya sea un estándar oficial de Tether, sino que en torno a USDT/Tether se están explorando protocolos similares a x402.

Detrás de esto hay una tendencia importante: Agentic Payment no es solo competencia de una empresa o una cadena, sino la formación de una nueva pila de protocolos.

• AP2 responde a: ¿Por qué un agente está autorizado a pagar?
• x402, L402, T402 responden a: ¿cómo un agente solicita y realiza pagos por recursos digitales?
• Las stablecoins y blockchain responden a: ¿con qué activos se liquida, dónde se verifica, cómo se hace de forma rápida, programable y cross-platform?

Por eso, discutir Agentic Payment junto a Crypto no es solo por “querer aprovechar IA en Web3”, sino porque este tipo de pagos reabre un problema que internet no resolvió: la “naturaleza nativa del pago”.

La información puede fluir de forma nativa en internet. Pero el valor, no. La aparición de los agentes está empujando a internet a cubrir esa capa.

Por eso, protocolos como x402, L402 y T402 son relevantes. No solo para que IA pague con criptomonedas, sino para definir una nueva forma de interacción: máquina pide recurso, máquina entiende precio, máquina verifica autorización, máquina paga, máquina recibe servicio.

Si el sistema de tarjetas resuelve el checkout, estos protocolos resuelven cómo las máquinas inician y completan pagos entre ellas. Y una vez en ese nivel, las stablecoins y blockchain dejan de ser solo herramientas de pago, para convertirse en el lenguaje y entorno de liquidación de Agentic Payment.

Tercero, ¿por qué stablecoins? La IA necesita una unidad de valor estable, no activos volátiles

Si un agente realmente necesita un protocolo de pago legible por máquinas y automatizable, ¿por qué se habla tanto de stablecoins? ¿Por qué no BTC? ¿Por qué no ETH? ¿Por qué no tarjetas tradicionales?

La clave no está en “crypto assets” en sí, sino en qué tipo de activo de pago necesita un agente. Si solo mantiene activos a largo plazo, le interesarán las fluctuaciones, ganancias, riesgos. Pero si paga por tareas, lo que más necesita no es un activo especulativo, sino una unidad de valor estable.

Un agente de investigación que llama a una API puede gastar 0.1 USD. Uno de codificación, 0.03 USD. Uno de marketing, 1 USD. Un agente de compras que cotiza, ordena y paga, necesita controlar cada gasto dentro del presupuesto.

En estos escenarios, el agente no está haciendo trading ni especulando. Está cumpliendo tareas. Por eso, necesita saber: ¿cuánto cuesta ese recurso? ¿Superará el presupuesto? ¿Está autorizado a pagar? ¿Se puede registrar el costo? ¿Y si el valor del activo fluctúa, cómo se mantiene la coherencia?

Si el activo de pago fluctúa mucho día a día, la gestión del presupuesto se vuelve problemática. Hoy, una llamada API vale 0.1 USD, mañana puede ser 0.12 o 0.08 por la volatilidad. Para el mercado, no es un problema, pero para recursos bajo demanda, complica mucho.

Por eso, en Agentic Payment, las stablecoins son más naturales que los activos volátiles como BTC o ETH.

Su primer valor es ofrecer una unidad de valor más cercana a la realidad del comercio. Hoy, muchas API, SaaS, datos, modelos y servicios en la nube se cobran en dólares. Si un agente paga con stablecoins, puede mantener en una misma unidad el presupuesto, el precio y la autorización.

Parece trivial, pero es crucial. Porque el agente no solo paga, también decide: ¿vale la pena esa llamada? ¿Es dentro del presupuesto? ¿Requiere confirmación? ¿Se puede registrar el costo? ¿Y si hay errores, cómo se explica?

Por eso, un activo de pago estable, legible por máquinas, que pueda ser automatizado, es más adecuado que BTC o ETH. Además, las stablecoins son mejores para pagos pequeños, frecuentes, en tiempo real. Protocolos como x402 ya muestran esa tendencia: pagos instantáneos en stablecoins mediante HTTP, sin necesidad de cuentas o autenticaciones complejas.

El proceso sería:

• El agente solicita un recurso.
• El servidor responde con 402 Payment Required.
• El agente paga en stablecoins.
• El servidor verifica y entrega el recurso.

Este flujo es ideal para llamadas pequeñas, frecuentes, bajo demanda: consultas, modelos, desbloqueos, análisis en cadena, generación de gráficos. La documentación de Tether WDK sobre x402 lo explica claramente: los agentes IA necesitan pagar programáticamente por recursos, y x402 permite descubrir precios, firmar pagos y obtener recursos en un ciclo request-response.

No es que las tarjetas no sirvan, sino que las stablecoins son más adecuadas para pagos en tiempo real entre máquinas. Las tarjetas siguen siendo útiles para el consumo humano en checkout, pero las stablecoins son más aptas para pagos automáticos, instantáneos y en múltiples plataformas.

Por eso, la tercera razón es que las stablecoins son más aptas para interoperabilidad y pagos transfronterizos. Un agente puede llamar APIs en EE. UU., servicios en Europa, contenido en Asia, y hacer transacciones entre agentes en diferentes países. Si dependiera de bancos, cuentas y ciclos de liquidación locales, el proceso sería fragmentado. La stablecoin, como activo nativo de internet, puede fluir 24/7, en cualquier plataforma, en cualquier wallet, y ser gestionada por contratos inteligentes o protocolos de pago. Para los humanos, solo será más rápido. Para los agentes, es esencial: sus operaciones no deben detenerse por fines de semana, fronteras, ciclos bancarios o sistemas de cuentas.

Por eso, protocolos como x402, Tether WDK y exploraciones como t402 apuntan en la misma dirección: convertir los pagos en stablecoins en componentes del stack web, accesibles programáticamente, en lugar de que los agentes tengan que entrar en páginas de pago diseñadas para humanos.

Pero hay que ser cautelosos: las stablecoins no son perfectas.

La reserva, transparencia, regulación, capacidad de redención y liquidez en cadena varían mucho entre ellas. El BIS en su informe económico anual 2025 criticó que las stablecoins aún tienen deficiencias en aspectos clave como singularidad, elasticidad e integridad, y no deberían considerarse aún una sustitución completa del dinero moderno.

Más preciso sería decir que las stablecoins no son moneda perfecta, pero sí una de las más cercanas a las necesidades de Agentic Payment en internet.

Su valor no radica en la narrativa de descentralización, sino en que cumplen varias condiciones: precio relativamente estable, programable, interoperable, 24/7, compatible con pagos nativos en HTTP, wallets, contratos inteligentes y auditorías en cadena.

Por eso, cuando se habla de recursos en la red abierta, las stablecoins aparecen naturalmente. Porque lo que necesita un agente no es solo una “mano que pase la tarjeta”, sino un dinero que las máquinas puedan entender y usar directamente.

Si las tarjetas son para el consumo humano, las stablecoins son para la economía de máquinas. Y aunque aún no están maduras, necesitan mejores marcos regulatorios, mecanismos de emisión estables, controles de riesgo, gestión de permisos en wallets, y su integración con protocolos como AP2, x402, MPP, para que puedan entrar en escenarios de Agentic Payment a gran escala.

Pero la dirección está clara: los agentes necesitan unidades de valor estables, activos de liquidación instantánea, dinero programable, y capacidades de pago cross-platform y cross-border.

Por eso, las stablecoins no pueden ser ignoradas en Agentic Payment. No porque todos los pagos deban ser en cripto, sino porque cuando el objeto de la transacción pasa de “consumidor humano” a “entidad software”, las stablecoins hacen que el dinero sea más parecido a un protocolo de internet.

Pero solo responden a una pregunta: ¿con qué dinero paga el agente? Aún no responden otra: después de gastar en la red abierta, ¿quién autorizó ese gasto, dónde se gastó, hubo sobrepaso, se entregó el servicio? Esa respuesta nos lleva a blockchain.

Cuarto, ¿por qué blockchain? No para poner todo en la cadena, sino para que las acciones del agente sean verificables

Aunque un agente necesita pagar en stablecoins, ¿por qué usar blockchain? ¿No puede ser un libro mayor centralizado? ¿Stripe, Visa, bancos, o alguna plataforma que lleve la contabilidad?

Por supuesto. Si el agente solo opera en un entorno cerrado, como comprar en Amazon, usar un SaaS, o en un sistema interno, un libro mayor centralizado basta. La plataforma sabe quién es el usuario, quién el agente, qué permisos tiene, cuánto gastó, si entregó el servicio.

Pero la verdadera innovación del Agentic Payment no es que el agente solo pulse un botón en un entorno cerrado, sino que puede operar en múltiples plataformas, servicios, wallets, países, e incluso con otros agentes. En ese escenario, la cuestión no es solo “¿puede pagar?”, sino “¿por qué, quién autorizó, quién es responsable, qué se entregó, qué pasa si hay errores?”.

Estas preguntas son las que realmente justifican el uso de blockchain en el contexto de pagos de agentes. No porque todos los pagos tengan que estar en cadena, sino porque cuando un agente actúa en nombre de alguien, cada acción económica necesita dejar un rastro verificable.

Para los humanos, esto puede ser tolerable: si no recibieron un servicio, llaman a soporte; si hay un problema en compras, revisan contratos, correos, facturas; si se cargó mal, reclaman. Pero para un agente, que realiza muchas transacciones pequeñas, frecuentes, en cadenas largas, esto sería inviable. La solución es una cadena de responsabilidad clara y verificable.

Por ejemplo, un usuario da una tarea a un agente: “gasta máximo 100 USD esta semana, solo en compra de datos, modelos y gráficos”. El agente pide a una API de datos, recibe un precio de 0.2 USD. Decide pagar, realiza la transferencia en stablecoins, y el proveedor verifica y entrega los datos. Lo importante no es qué blockchain se usó, sino si podemos responder: ¿qué autorización se dio?, ¿qué se compró?, ¿se respetó el presupuesto?, ¿se entregó lo prometido?, ¿qué pasa si el agente fue manipulado o atacado? ¿Se puede rastrear?

Por eso, al revisar el white paper de Bitcoin en relación a pagos de agentes, no es solo nostalgia. Nakamoto no buscaba inventar un activo para transacciones, sino cómo en ausencia de terceros confiables, verificar, ordenar y registrar transferencias electrónicas. El paper dice claramente que la red escribe las transacciones en una cadena de prueba de trabajo, que no puede ser modificada sin rehacer todo el trabajo.

El problema de Agentic Payment no es solo doble gasto, sino autorización, sobrepaso, entrega y responsabilidad. Pero comparten un punto: en un entorno abierto, los registros verificables no son solo un complemento, sino la infraestructura misma.

Eso es lo que da sentido a blockchain. No para hacer el pago “más cripto”, sino para convertir en verificables los estados que antes estaban en bases de datos cerradas. Para que los registros de autorización, acceso, reembolsos, límites y gastos puedan ser estandarizados y validados. Para los humanos, solo será “más claro”. Para los agentes, será la base de su confianza.

Porque un agente no es una persona. No puede decir “recuerdo que pensé así” para justificar su comportamiento. Necesita una cadena de evidencia verificable externa.

Por eso, protocolos como AP2, x402, stablecoins y blockchain suelen discutirse juntos, pero no son lo mismo. AP2 no es un protocolo descentralizado ni blockchain en sí. Es un marco abierto “independent of payment method”, que permite a usuarios, comerciantes y proveedores de pago completar pagos liderados por agentes con mayor confianza. La especificación establece que el agente necesita un método seguro y sencillo para obtener permisos limitados, actuando en nombre del usuario, y que la seguridad del protocolo depende de firmas criptográficas.

Por eso, la primera pregunta en Agentic Payment no es: ¿de dónde sale el dinero? sino: ¿por qué el agente tiene derecho a gastar ese dinero?

El sistema de tarjetas puede resolver parte de esto, con tarjetas virtuales, credenciales tokenizadas, límites, control de gastos, reglas de riesgo. Visa también avanza en esa línea, con su Trusted Agent Protocol y la iniciativa de Comercio Inteligente, que busca que los agentes IA puedan ser reconocidos, confiables y autorizados en la red de comerciantes actual. La descripción de Visa Developer dice que los agentes IA ayudarán a navegar, descubrir productos, comparar precios y decidir, antes del checkout; pero estas interacciones automáticas a menudo son bloqueadas por sistemas anti-bot o CDN.

Esto muestra que las redes tradicionales también ven el mismo problema: el comercio agentico no solo sucede en el momento del pago, sino en toda la cadena desde búsqueda, comparación, autorización, hasta la liquidación final. Pero las redes de tarjetas están mejor preparadas para integrar cómo un agente entra en ese flujo y realiza una transacción autorizada. No resuelven cómo un agente en una red abierta puede hacer pagos pequeños y continuos mediante APIs, datos, modelos, recursos computacionales, contenido, o incluso otro agente.

Por eso, las tarjetas no son inviables, solo que resuelven el checkout del comercio tradicional. Lo que necesita la economía de agentes es un protocolo de pago más profundo.

Este lleva la discusión a otro nivel: si la transacción no es con un comerciante tradicional, sino con una API, un recurso, o un agente, ¿cómo inician y completan pagos entre máquinas? Por eso se discuten protocolos como x402, L402, T402.

Tercero, lo que realmente necesita un agente es un protocolo de pago legible por máquinas

Si el objeto de la transacción es un comerciante tradicional, el agente puede usar los flujos existentes: tarjetas, virtuales, wallets. Pero si el objeto es una API, un recurso de datos, o incluso otro agente, la cosa cambia.

Aquí, lo que las máquinas necesitan no es un “botón de pago”, sino un proceso de pago que puedan entender: el agente solicita un recurso. El proveedor responde: “esto requiere pago, cuánto cuesta, cuál es la dirección, qué métodos soporta”. El agente evalúa si la compra está autorizada. Si sí, paga. El proveedor verifica y entrega el recurso inmediatamente.

Este proceso, aunque simple, llena un vacío en la infraestructura de internet: la capa nativa de pagos. Antes, internet soportaba flujo de información: páginas, correos, APIs, archivos. Pero “pago” no era parte del protocolo, sino algo externo: registrarse, vincular tarjeta, acceder a pasarelas, comprar planes, gestionar API keys, hacer conciliaciones.

Para humanos, esto es tolerable. Registrarse, loguearse, vincular tarjeta, aprobar, comprar, reembolsar. Pero para agentes, esto es demasiado.

Un agente no debería tener que registrarse en cada API, ni comprar un plan completo por cada llamada, ni pasar por todo el proceso de pago por unos centavos. Ahí surge la necesidad de protocolos como x402.

x402 reactiva el código HTTP 402 Payment Required, que ha existido mucho tiempo pero rara vez se usó en realidad. Permite que el servidor indique en la capa HTTP: “esto requiere pago previo”. El cliente puede ser humano o máquina. Tras pagar, el servidor verifica y entrega el recurso.

Coinbase define x402 como un protocolo abierto para pagos instantáneos y automáticos en stablecoins, que permite a clientes humanos y máquinas pagar y acceder a recursos sin necesidad de cuentas, sesiones o autenticaciones complejas.

Lo importante no es si se usa Coinbase o USDC, sino que x402 integra el pago en el ciclo de petición-respuesta de internet.

Antes:

• Registrarse.
• Comprar plan.
• Obtener API key.
• Solicitar servicio.
• Conciliar al final del mes.

Ahora:

• Solicitar recurso.
• Recibir 402 Payment Required.
• Pagar.
• Obtener recurso.

Esto es clave para Agentic Payment, porque los agentes no solo hacen unas pocas compras grandes, sino muchas llamadas pequeñas, en tiempo real, bajo demanda.

Por ejemplo:

• Un agente de escritura compra una consulta de datos.
• Un agente de investigación realiza un análisis en cadena.
• Un agente de viajes consulta precios en varios sitios.
• Un agente de desarrollo compra modelos, revisiones o entornos de prueba.
• Un agente de análisis de tráfico solo quiere pagar una vez por Semrush, no toda la suscripción.

Si cada servicio requiere cuentas, suscripciones, API keys, aprobaciones manuales, la ejecución del agente se atasca en pagos y compras. Por eso, x402 no busca hacer los pagos “más cripto”, sino hacer que sean más como un protocolo de internet: solicitables, verificables, automáticos.

L402 sigue una línea similar, combinando HTTP 402 con Lightning Network y macaroons, para facilitar autenticación y micropagos en APIs y recursos computacionales. Lightning Labs define L402 como un protocolo para facilitar la autorización y pago en APIs y recursos, permitiendo a los agentes IA cobrar por sus llamadas.

Esto demuestra que no es que x402 haya sido inventado ayer, sino que ya existía la idea de combinar control de acceso, micropagos y permisos digitales, solo que antes faltaba un demandante fuerte.

Los humanos no pagan unos centavos por acceder a un API, pero los agentes sí. No llaman cientos de fuentes automáticamente, pero los agentes sí. No combinan llamadas, cotizaciones y pagos en tiempo real, pero los agentes sí.

Por eso, la aparición de los agentes IA hace que la idea de pagos nativos en internet tenga sentido.

En el ecosistema Tether, también surge una línea similar. El documento x402 de Tether WDK señala que x402 es importante para los agentes IA porque necesitan pagar programáticamente por recursos; permite que los pagos sean parte del stack web, y que en un ciclo request-response puedan descubrir precios, firmar pagos y obtener recursos. T402 se presenta como un estándar abierto para pagos nativos en internet, compatible con crypto, fiat, stablecoins y tokens.

Hay que ser cautelosos: no es que ya sea un estándar oficial de Tether, sino que en torno a USDT/Tether se están explorando protocolos similares a x402.

Detrás de esto hay una tendencia importante: Agentic Payment no es solo competencia de una empresa o una cadena, sino la formación de una nueva pila de protocolos.

• AP2 responde a: ¿Por qué un agente está autorizado a pagar?
• x402, L402, T402 responden a: ¿cómo un agente solicita y realiza pagos por recursos digitales?
• Las stablecoins y blockchain responden a: ¿con qué activos se liquida, dónde se verifica, cómo se hace de forma rápida, programable y cross-platform?

Por eso, discutir Agentic Payment junto a Crypto no es solo por “querer aprovechar IA en Web3”, sino porque este tipo de pagos reabre un problema que internet no resolvió: la “naturaleza nativa del pago”.

La información puede fluir de forma nativa en internet. Pero el valor, no. La aparición de los agentes está empujando a internet a cubrir esa capa.

Por eso, protocolos como x402, L402 y T402 son relevantes. No solo para que IA pague con criptomonedas, sino para definir una nueva forma de interacción: máquina pide recurso, máquina entiende precio, máquina verifica autorización, máquina paga, máquina recibe servicio.

Si el sistema de tarjetas resuelve el checkout, estos protocolos resuelven cómo las máquinas inician y completan pagos entre ellas. Y una vez en ese nivel, las stablecoins y blockchain dejan de ser solo herramientas de pago, para convertirse en el lenguaje y entorno de liquidación de Agentic Payment.

Cuarto, ¿por qué stablecoins? La IA necesita una unidad de valor estable, no activos volátiles

Si un agente realmente necesita un protocolo de pago legible por máquinas y automatizable, ¿por qué se habla tanto de stablecoins? ¿Por qué no BTC? ¿Por qué no ETH? ¿Por qué no tarjetas tradicionales?

La clave no está en “crypto assets” en sí, sino en qué tipo de activo de pago necesita un agente. Si solo mantiene activos a largo plazo, le interesarán las fluctuaciones, ganancias, riesgos. Pero si paga por tareas, lo que más necesita no es un activo especulativo, sino una unidad de valor estable.

Un agente de investigación que llama a una API puede gastar 0.1 USD. Uno de codificación, 0.03 USD. Uno de marketing, 1 USD. Un agente de compras que cotiza, ordena y paga, necesita controlar cada gasto dentro del presupuesto.

En estos escenarios, el agente no está haciendo trading ni especulando. Está cumpliendo tareas. Por eso, necesita saber: ¿cuánto cuesta ese recurso? ¿Superará el presupuesto? ¿Está autorizado a pagar? ¿Se puede registrar el costo? ¿Y si el valor del activo fluctúa, cómo se mantiene la coherencia?

Si el activo de pago fluctúa mucho día a día, la gestión del presupuesto se vuelve problemática. Hoy, una llamada API vale 0.1 USD, mañana puede ser 0.12 o 0.08 por la volatilidad. Para el mercado, no es un problema, pero para recursos bajo demanda, complica mucho.

Por eso, en Agentic Payment, las stablecoins son más naturales que los activos volátiles como BTC o ETH.

Su primer valor es ofrecer una unidad de valor más cercana a la realidad del comercio. Hoy, muchas API, SaaS, datos, modelos y servicios en la nube se cobran en dólares. Si un agente paga con stablecoins, puede mantener en una misma unidad el presupuesto, el precio y la autorización.

Parece trivial, pero es crucial. Porque el agente no solo paga, también decide: ¿vale la pena esa llamada? ¿Es dentro del presupuesto? ¿Requiere confirmación? ¿Se puede registrar el costo? ¿Y si hay errores, cómo se explica?

Por eso, un activo de pago estable, legible por máquinas, que pueda ser automatizado, es más adecuado que BTC o ETH. Además, las stablecoins son mejores para pagos pequeños, frecuentes, en tiempo real. Protocolos como x402 ya muestran esa tendencia: pagos instantáneos en stablecoins mediante HTTP, sin necesidad de cuentas o autenticaciones complejas.

El proceso sería:

• El agente solicita un recurso.
• El servidor responde con 402 Payment Required.
• El agente paga en stablecoins.
• El servidor verifica y entrega el recurso.

Este flujo es ideal para llamadas pequeñas, frecuentes, bajo demanda: consultas, modelos, desbloqueos, análisis en cadena, generación de gráficos. La documentación de Tether WDK sobre x402 lo explica claramente: los agentes IA necesitan pagar programáticamente por recursos, y x402 permite descubrir precios, firmar pagos y obtener recursos en un ciclo request-response.

No es que las tarjetas no sirvan, sino que las stablecoins son más adecuadas para pagos en tiempo real entre máquinas. Las tarjetas siguen siendo útiles para el consumo humano en checkout, pero las stablecoins son más aptas para pagos automáticos, instantáneos y en múltiples plataformas.

Por eso, la tercera razón es que las stablecoins son más aptas para interoperabilidad y pagos transfronterizos. Un agente puede llamar APIs en EE. UU., servicios en Europa, contenido en Asia, y hacer transacciones entre agentes en diferentes países. Si dependiera de bancos, cuentas y ciclos de liquidación locales, el proceso sería fragmentado. La stablecoin, como activo nativo de internet, puede fluir 24/7, en cualquier plataforma, en cualquier wallet, y ser gestion