¿El agente de IA puede usar tarjetas bancarias?
¿Por qué Agentic Payment no puede evitar las monedas estables y la cadena de bloques?

Autor: Yokiiiya

La semana pasada participé en el Web3 Festival en Hong Kong, 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 de cumplimiento y 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 planteó directamente una pregunta: ¿Web3 está aprovechando la IA? Creo que no. Claro, habrá proyectos que sí lo hagan por tendencia. Pero si solo entendemos IA × Web3 como un collage narrativo, podemos estar perdiendo un cambio más profundo: IA encargada de entender, decidir y actuar, mientras Web3 proporciona activos, cuentas, liquidaciones y entornos de ejecución verificables. No son conceptos que se sumen, sino que están en una nueva división del trabajo.

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 máximo 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 autorizan esas acciones, cómo se liquidan, cómo se registran y quién asume la responsabilidad.

Entre los temas que cada vez se vuelven más relevantes está el Pago Agentico. Pero al principio también me surgió una duda sencilla: ¿por qué cuando hablamos de Pago Agentico o Comercio Agentico, parece que damos por hecho que siempre estará ligado a Cripto, Stablecoins y Blockchain?

¿La IA Agent no puede usar tarjetas bancarias? ¿No puede usar tarjetas de crédito? ¿No puede usar Apple Pay, Visa, Mastercard, Stripe, PayPal?

Si el Agent solo ayuda a comprar un billete de avión, reservar un hotel, renovar un SaaS, en teoría puede llamar a los sistemas de pago existentes. El usuario autoriza una vez, el Agent 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 algo irracional.

Por eso, la cuestión no es “¿se puede usar la tarjeta?”. Claro que sí. La verdadera pregunta es: ¿qué parte del Pago Agentico puede resolver la tarjeta bancaria y qué parte no? ¿El IA Agent usará realmente la tarjeta bancaria? ¿Y por qué, cuando el Pago Agentico evoluciona a cierto nivel, casi siempre termina inevitablemente ligado a stablecoins y blockchain?

Primero, la tarjeta resuelve el checkout, no la Economía del Agente

Si el Pago Agentico 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 esencial. La tarjeta puede usarse, la tarjeta de crédito también.

El usuario autoriza una vez, el Agent ejecuta el pago dentro de límites y reglas. Esto no es difícil de entender; en esencia, 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 los primeros pasos del Comercio Agentico.

El protocolo Machine Payments de Stripe y Tempo lo ejemplifica claramente. No se trata solo de stablecoins, sino de permitir a los comerciantes aceptar pagos directamente de agentes, soportando stablecoins, tarjetas, BNPL y otros métodos fiat. Es decir, en las etapas iniciales del Pago Agentico, la coexistencia de pagos tradicionales y stablecoins es más probable que una sustitución inmediata. Pero esto solo resuelve una parte del checkout.

El checkout presupone que los productos, comerciantes, pedidos, botones de pago, reembolsos y procesos de disputa ya existen. El Agent solo está al lado del usuario, ayudándole a automatizar una compra.

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

Por ejemplo, un agente de investigación para un informe sectorial puede necesitar llamar varias bases de datos, comprar datos de pago, acceder a APIs de modelos, usar servicios de scraping, pagar herramientas de generación de gráficos, e incluso comprar análisis a otro Agent. En estos casos, puede que 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 Agent.

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 de 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 basado en cuentas, planes y unidades API. Cada request consume unidades API, y el usuario necesita tener acceso o comprar un paquete de unidades. Aunque se pueda comprar acceso a Trends API, sigue basado en unidades API.

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

Aquí se produce una brecha entre Pago Agentico y los modelos tradicionales de API. La mayoría de las formas de cobrar APIs hoy en día están diseñadas para “empresas humanas comprando software”, no para “máquinas comprando recursos bajo demanda”.

Por eso, el problema del Pago Agentico no es solo si se puede cobrar 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 adquiriente y el procesador se encargan de la autorización, liquidación, gestión de riesgos y disputas.

Pero la Economía del Agente enfrenta otro conjunto de problemas: ¿Por qué un Agent 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 Agent, sin confirmación humana en cada paso, hacer pagos pequeños, frecuentes, en múltiples plataformas? ¿El proveedor puede liberar recursos inmediatamente tras recibir el pago? ¿Qué pasa si el Agent compra algo incorrecto, 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 agenticos. 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 Agent necesita una forma segura y sencilla de obtener permisos limitados, para actuar en nombre del usuario, y que la seguridad del protocolo depende de firmas criptográficas del usuario y del comerciante.

Por eso, la primera pregunta del Pago Agentico no es: ¿de dónde sale el dinero? sino: ¿Por qué el Agent tiene derecho a gastar ese dinero?

El sistema de tarjetas puede resolver parte de esto, con tarjetas virtuales, credenciales tokenizadas, gestión de límites, control de gastos empresariales y reglas de riesgo, permitiendo que el Agent realice transacciones en los sistemas existentes.

Visa también avanza en esta línea. Su protocolo Trusted Agent y la iniciativa Intelligent Commerce buscan que los IA Agents puedan ser reconocidos, confiables y autorizados para actuar en nombre del consumidor o la empresa en la red de comerciantes actual. La descripción de Visa Developer sobre Trusted Agent Protocol dice que los agentes ayudan a los usuarios a navegar en sitios, descubrir productos, comparar precios y tomar decisiones, y que el proceso de automatización comienza antes del checkout; en el pasado, estas visitas automáticas eran bloqueadas por los sistemas anti-bot o CDN.

Esto indica que las redes de pago tradicionales también ven el 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 son mejores para integrar cómo un Agent entra en el flujo de comercio existente y realiza una transacción autorizada. No resuelven naturalmente cómo un Agent en la red abierta puede hacer pagos continuos, pequeños y automáticos a través de APIs, datos, modelos, recursos computacionales, contenido, o incluso otro Agent.

Por eso, las tarjetas no son inviables, sino que resuelven el checkout del comercio tradicional, pero el Economía del Agente requiere un protocolo de pago más profundo.

Este lleva la cuestió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 Agent, ¿cómo inician y completan pagos las máquinas? Es la razón por la que se discuten protocolos como x402, L402, T402.

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

Si el objeto de la transacción es un comerciante tradicional, el Agent puede usar los flujos existentes de checkout, con tarjetas, wallets, o pagos en línea. Pero si el objeto es una API, un modelo, un recurso de datos, o incluso otro Agent, 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 Agent solicita un recurso. El servicio responde: “este recurso requiere pago, cuesta tanto, la dirección de pago es tal, soporta estos métodos”. El Agent evalúa si la compra está autorizada por el usuario. Si cumple las reglas, paga. El servicio verifica el pago y libera el recurso.

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

Para los humanos, esto es tolerable. Registrarse, loguearse, vincular tarjetas, aprobar compras, reembolsar. Pero para los Agents, esto es demasiado pesado.

Un Agent no debería tener que crear una cuenta cada vez que llama a una API, ni comprar un paquete completo de unidades, ni pasar por todo un proceso de pago y compra por cada pequeña llamada. Esa es la razón 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ó. Permite que el servidor indique en la capa HTTP: “para acceder a este recurso, primero debes pagar”. El cliente puede ser humano o máquina. Tras pagar, el servidor verifica y entrega el recurso, API, contenido o servicio digital.

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 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:

• Crear cuenta.
• Comprar plan.
• Obtener API key.
• Llamar al servicio.
• Conciliar al final del mes.

Ahora:

• Solicitar recurso.
• Recibir 402 Payment Required.
• Realizar pago.
• Obtener recurso.

Esto es clave para el Pago Agentico, porque no se trata solo de unas pocas compras grandes, sino de muchas llamadas pequeñas, en tiempo real, bajo demanda.

Por ejemplo:

• Un agente de escritura compra datos para un artículo.
• Un agente de investigación financiera llama a análisis en cadena.
• Un agente de viajes consulta múltiples APIs de precios.
• Un agente de desarrollo compra modelos, revisiones o entornos de prueba.
• Un agente de análisis de tráfico solo compra datos de Semrush para un sitio, sin paquetes completos.

Si cada servicio requiere cuentas, suscripciones, API keys, y aprobaciones manuales, el agente se atasca en pagos y compras. Por eso, x402 no busca hacer los pagos “más cripto”, sino que los hace más parecidos a protocolos de internet: solicitables, verificables, automáticos.

L402 sigue una línea similar, usando también Lightning Network y macaroons para autenticación y micropagos. Su objetivo es facilitar la certificación y pago de recursos API y computacionales, permitiendo a los agentes de IA participar más fácilmente.

L402 muestra que no es una invención reciente: ya se intentaba combinar control de acceso, micropagos y permisos digitales. Pero faltaba una demanda 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, consultas y pagos en tiempo real, pero los agentes sí.

Por eso, la aparición de IA Agents hace que la ruta de pagos nativos en internet tenga sentido.

Incluso en el ecosistema USDT/Tether, ya hay exploraciones similares. La documentación de x402 de Tether WDK dice que es importante para IA agents, 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 USDT, tokens y fiat.

Es importante ser cautelosos: no es que ya sea un estándar oficial de Tether, sino que en torno a USDT/Tether surgen protocolos similares en exploración.

Detrás, hay una tendencia clara: el Pago Agentico no es solo competencia de una empresa o una cadena, sino que está formando una nueva pila de protocolos.

• AP2 responde: ¿Por qué un Agent está autorizado a pagar?
• x402, L402, T402 responden: ¿cómo el servicio inicia un pago cuando el Agent solicita un recurso?
• Stablecoins y blockchain responden: ¿con qué activo se liquida, dónde se verifica, cómo se hace en bajo costo, en tiempo real y de forma programable?

Por eso, el Pago Agentico y la criptoeconomía no se discuten solo porque Web3 quiera aprovechar IA, sino porque el Pago Agentico vuelve a plantear la “pago nativa” que internet no resolvió.

La información puede fluir nativamente en internet. Pero el valor, no. La aparición de los Agents está empujando a internet a cerrar esa brecha.

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áquinas piden recursos, entienden precios, verifican autorizaciones, pagan, y reciben servicios.

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

Tercero, ¿por qué stablecoins? Porque el agente necesita una unidad de valor estable, no activos volátiles

Si un Agent 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 bancarias?

La clave no está en “crypto assets” en sí, sino en qué tipo de activo de pago necesita el Agent. 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 costar 0.1 USD. Uno de codificación, 0.03 USD. Uno de marketing, 1 USD. Un agente de compras que compara, ordena y paga, necesita controlar cada gasto dentro del presupuesto.

En estos escenarios, el Agent no está haciendo trading ni especulando. Está cumpliendo tareas. Por eso, necesita saber: ¿cuánto cuesta este recurso? ¿Superará el presupuesto? ¿Está autorizado a pagar? ¿Se puede registrar el costo? ¿Y qué pasa si el precio fluctúa? ¿Y si la llamada se hace en diferentes plataformas?

Si el activo de pago fluctúa mucho, la gestión del presupuesto se vuelve difícil. Hoy, una API puede valer 0.1 USD, mañana 0.12 o 0.08 USD por la volatilidad. Para el mercado, no es un problema, pero para recursos bajo demanda, sí lo es. Añade complejidad innecesaria.

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

El primer valor de las stablecoins es ofrecer una unidad de valor más cercana a la realidad del comercio. Hoy, muchas APIs, SaaS, datos, modelos y servicios en la nube se valoran en dólares. Si un Agent compra estos servicios, usar stablecoins en USD permite mantener la coherencia en presupuesto, precios, autorizaciones y facturación.

Parece trivial, pero es crucial. Porque el Agent no solo paga, también evalúa: ¿vale la pena? ¿Es suficiente el presupuesto? ¿Requiere confirmación? ¿Se puede registrar el costo? ¿Y qué pasa si el precio fluctúa?

Si el activo de pago es muy volátil, la gestión del presupuesto se complica. La stablecoin, que mantiene un valor estable, ayuda a que el control sea más sencillo y confiable.

El segundo valor es que las stablecoins son más aptas para pagos pequeños, frecuentes y en tiempo real. Como en x402, donde Coinbase define pagos instantáneos y automáticos en stablecoins, permitiendo a APIs y servicios digitales cobrar sin necesidad de cuentas o autenticaciones complejas. La idea es que el pago ocurra en una sola petición API, no en un checkout completo.

El flujo sería:

El Agent solicita un recurso.
El servidor responde: “se requiere pago, cuesta tanto”.
El Agent evalúa y paga en stablecoins.
El servidor verifica y entrega el recurso.

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

No es un escenario de tarjetas, sino de pagos automáticos en la red. La tarjeta es para consumo humano en el checkout, la stablecoin para pagos máquina a máquina en tiempo real. No significa que las tarjetas desaparezcan, sino que los métodos se complementan: Stripe y Tempo soportan pagos en cadena y pagos fiat con tarjetas y BNPL.

Por eso, la conclusión no es “stablecoin reemplaza tarjeta”, sino que las redes tradicionales sirven para comercio establecido, y las stablecoins para pagos en la red abierta, bajo demanda, en pequeños montos, en múltiples plataformas.

El tercer valor es que las stablecoins son más aptas para operaciones transfronterizas y multiplataforma. Un Agent puede llamar APIs en EE. UU., usar servicios en Europa, acceder a recursos en Asia, y hacer transacciones con otro Agent en diferentes países. Si cada paso dependiera de bancos, adquirientes y sistemas locales, el proceso sería fragmentado. La stablecoin, como activo nativo de internet, puede fluir 24/7, cruzar plataformas, wallets, aplicaciones, y ser gestionada por contratos inteligentes o protocolos de pago. Para el usuario humano, solo será más rápido. Para el Agent, es esencial: no debe detenerse por fines de semana, fronteras, ventanas de liquidación bancaria o sistemas de cuentas. Necesita un activo de liquidación siempre disponible, automatizable y verificable.

Por eso, x402, Tether WDK y exploraciones como t402 apuntan en la misma dirección: convertir los pagos en stablecoin en componentes del stack web, accesibles por máquinas, no solo en páginas de pago diseñadas para humanos.

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

La reserva, transparencia, regulación, liquidez en cadena varían mucho entre ellas. El informe económico anual del BIS 2025 critica que las stablecoins aún no cumplen con estándares clave de moneda moderna: singularidad, elasticidad, integridad. No son una sustitución completa.

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

Su valor no está en la narrativa de descentralización, sino en que cumplen varias condiciones: precio estable, programable, transfronterizo, 24/7, integrable con pagos nativos en internet, 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 el Agent no es una “mano que pase la tarjeta”, sino un dinero que las máquinas puedan entender y usar directamente.

Si la tarjeta fue diseñada para el consumo humano, la stablecoin es para la economía de máquinas: un lenguaje de liquidación estable y confiable.

Por supuesto, aún no está maduro. La experiencia en cadena sigue siendo compleja, las wallets no son amigables, la regulación de stablecoins cambia, y la liquidez entre cadenas es dispersa. Más importante aún, que un Agent controle fondos directamente es muy peligroso. Sin gestión de permisos, límites, riesgos, revisiones humanas y auditorías, el Pago Agentico puede pasar de automatización a caos.

Por eso, la visión no es que el Agent tenga una wallet y pueda gastar a voluntad. Es un proceso evolutivo: primero integrarse en los sistemas existentes, ayudando en el checkout automatizado; luego, obtener permisos más finos: límites, listas blancas, rangos de uso, tiempos, niveles de riesgo; después, APIs, datos, modelos y contenidos soportarán pagos legibles por máquinas; y, finalmente, las stablecoins serán la base de liquidación en escenarios de pagos pequeños, frecuentes, transfronterizos y multiplataforma.

Desde esta perspectiva, el Pago Agentico no lo logra una sola empresa, cadena, stablecoin o protocolo. Es una reconfiguración de toda la infraestructura de pagos ante la presencia de agentes de IA.

Hasta ahora, los sistemas de pago estaban diseñados para humanos y empresas. En el futuro, también deberán atender a un nuevo sujeto: los proxies de software autorizados.

No son personas en el sentido legal, ni cuentas empresariales tradicionales, pero pueden hacer solicitudes, comparar precios, llamar servicios, consumir recursos, activar pagos y dejar registros. Cuando estos sujetos comiencen a ser comunes, los sistemas de pago deberán responder: ¿quiénes son? ¿a quién representan? ¿qué permisos tienen? ¿cuánto pueden gastar? ¿qué compraron? ¿excedieron permisos? ¿quién asume la responsabilidad?

Estas preguntas ya no se resuelven solo con un botón de pago.

Volviendo a la pregunta inicial: ¿Usará la IA Agent una tarjeta bancaria?

Sí.

Pero no solo eso.

Las tarjetas seguirán resolviendo el checkout humano. Las stablecoins empezarán a resolver pagos nativos, pequeños y en tiempo real. La blockchain ofrecerá un entorno verificable para estados y ejecuciones. Protocolos como AP2, x402, L402 y T402 intentarán enlazar autorizaciones, solicitudes de pago y acceso a recursos.

Eso es lo que más importa del Pago Agentico: no solo que la IA tenga un método de pago, sino que nos obliga a repensar qué necesita un sistema de pagos cuando las máquinas participan en la economía.