El comercio digital se diseñó para una secuencia conocida: una persona abre una página, busca un producto, compara opciones, añade artículos al carrito, introduce sus datos, elige un medio de pago y confirma la compra. Durante años, casi toda la arquitectura del comercio electrónico partió de la idea de que hay una persona navegando por una interfaz visual y tomando cada decisión directamente en la pantalla.
Los agentes de IA cambian esa premisa.
Cuando un agente puede interpretar una intención, buscar productos, comparar condiciones, preparar una cesta, consultar existencias, calcular gastos de envío e iniciar una compra, el checkout deja de ser solo una página. Pasa a ser también un conjunto de capacidades que otros sistemas deben poder descubrir, entender y utilizar de forma segura.
Eso no significa que las tiendas, los ERP, las pasarelas, los PSP y los sistemas de pedidos dejen de existir. El movimiento más interesante es el contrario: la infraestructura que ya sostiene el comercio necesita una capa capaz de exponer sus capacidades a nuevos canales sin perder el control del catálogo, los precios, las existencias, la identidad, los pagos y la posventa.
Es precisamente esa frontera la que convierte el comercio agéntico en un asunto de infraestructura, y no solo de interfaz.
¿Qué son los pagos por agentes de IA?
Los pagos por agentes de IA son pagos iniciados dentro de una experiencia en la que un agente de software participa activamente en el descubrimiento, la decisión, la preparación o la ejecución de una compra en nombre de una persona o empresa.
El agente puede tener distintos grados de autonomía. En un escenario, se limita a encontrar opciones y llevar al usuario al checkout tradicional. En otro, prepara el carrito y solicita confirmación antes de continuar. En arquitecturas más avanzadas, puede operar dentro de límites previamente definidos de importe, categoría, comercio, frecuencia o finalidad.
La diferencia importante no es simplemente que haya IA al principio del recorrido. El punto de inflexión aparece cuando un sistema deja de limitarse a recomendar y empieza a ejecutar acciones que modifican el estado real del comercio.
Consultar el catálogo es una operación de lectura. Reservar existencias es una acción. Crear un pedido es una acción. Seleccionar el envío es una acción. Confirmar un cobro es una acción financiera.
Cuanto más avanza el agente en esta cadena, mayor es la necesidad de identidad, autorización, límites, trazabilidad y control del estado.
El comercio agéntico no elimina el comercio existente
Una interpretación superficial sería imaginar que los agentes sustituirán el comercio electrónico tradicional por una pila tecnológica completamente nueva. En la práctica, los protocolos y productos que están surgiendo apuntan hacia otro camino: los agentes se conectan a la infraestructura existente mediante interfaces estructuradas.
El comercio sigue necesitando catálogo, existencias, precios, reglas promocionales, logística, pedidos, prevención del fraude, pagos, atención al cliente y conciliación. Lo que cambia es el punto de entrada.
Hoy, gran parte de las capacidades del comercio se utilizan mediante páginas diseñadas para personas. En una experiencia agéntica, esas mismas capacidades deben ser accesibles para el software de forma predecible y verificable.
El principio es sencillo: el comercio sigue perteneciendo al comerciante. El agente se convierte en un nuevo canal.
Esta es también la propuesta pública de AZPay Agents. La iniciativa parte de la infraestructura que la empresa ya utiliza y añade una capa para agentes, manteniendo el catálogo, el checkout, el cliente, el pedido, el pago y la posventa en la operación existente. La página del producto describe una arquitectura en la que las plataformas de comercio electrónico y los sistemas de gestión se conectan a una capa común, en colaboración con Trydak, para preparar las capacidades comerciales para los canales agénticos compatibles.
Este enfoque evita una trampa habitual de las nuevas tecnologías: exigir que una empresa reconstruya todo antes de probar un nuevo canal.
¿Qué significa convertir el checkout en capacidades?
Una página de checkout presenta opciones a una persona. Una integración agéntica necesita presentar estados y acciones a otra máquina.
Pensemos en un carrito sencillo. Para una persona, la interfaz puede mostrar el nombre del producto, la imagen, el precio, la cantidad, el envío y el botón de compra. Para un agente, la infraestructura debe responder a preguntas de forma estructurada: ¿sigue existiendo el artículo? ¿Cuál es el precio actual? ¿Hay existencias? ¿Qué opciones de entrega están disponibles? ¿Hay restricciones para el código postal? ¿Existe algún descuento aplicable? ¿Cuál es el total final? ¿Sigue siendo válida la sesión? ¿Qué medios de pago se pueden utilizar?
Más importante aún: la respuesta debe proceder de la fuente autorizada.
Un agente no debería completar una compra utilizando un precio que apareció en una recomendación de hace varios minutos si el comercio ya ha actualizado ese importe. El estado final debe confirmarse en la infraestructura responsable del pedido.
Por eso, las arquitecturas de comercio agéntico suelen trabajar con sesiones de checkout, estados completos del carrito y operaciones explícitas de creación, actualización y finalización.
La documentación pública del Agentic Commerce Protocol de OpenAI sigue esta lógica: el comercio crea y actualiza sesiones de checkout, devuelve el estado de referencia del carrito, recibe una llamada de finalización y mantiene el procesamiento del pedido y del pago en su propia infraestructura.
El principio arquitectónico va más allá de un protocolo concreto: los agentes necesitan contratos claros para conocer el estado y ejecutar cambios.
¿Quién es responsable del pago cuando compra un agente?
Un agente puede iniciar o coordinar una compra sin convertirse necesariamente en el procesador financiero de la transacción.
En los modelos actuales de comercio agéntico, el comercio sigue utilizando su infraestructura de pagos. El agente o la plataforma puede transportar una autorización, un token o una instrucción limitada, mientras que el PSP y los participantes tradicionales ejecutan la autorización, la captura y la liquidación.
Esto conserva una separación importante de responsabilidades.
El agente entiende la intención y coordina la experiencia. La infraestructura de comercio valida el pedido. La infraestructura de pagos ejecuta el flujo financiero según sus propias reglas de seguridad, riesgo y autorización.
En el Agentic Commerce Protocol, por ejemplo, el modelo Delegated Payments se diseñó para permitir que una credencial o autorización de pago se delegue de forma limitada, con restricciones como el comercio, el importe y la caducidad. El comercio y su PSP siguen siendo responsables de procesar el pago.
Esto muestra por qué los pagos agénticos no consisten simplemente en entregar una tarjeta a una IA. El problema es crear una autorización que solo pueda utilizarse dentro de un contexto concreto.
Delegar no es dar acceso sin restricciones
Para que los pagos por agentes sean aceptables, la delegación debe tener límites.
Imagina la diferencia entre dos instrucciones.
La primera es vaga: utiliza mi tarjeta cuando lo consideres necesario.
La segunda es verificable desde el punto de vista operativo: puedes completar esta compra en este comercio, hasta este importe, dentro de esta sesión y antes de esta hora.
La segunda puede representarse mediante políticas y datos que los sistemas pueden validar. La primera exige una confianza excesiva en un único componente.
Por eso, una buena arquitectura agéntica tiende a convertir la intención humana en permisos explícitos.
Estos permisos pueden incluir un importe máximo, un comercio autorizado, un periodo de validez, una finalidad, la identidad del agente y la identidad de la sesión. Según el protocolo, también pueden representarse mediante tokens de un solo uso, credenciales delegadas o mecanismos criptográficos de firma.
El objetivo es reducir el poder implícito del agente y aumentar la capacidad de verificar la acción.
¿Cómo sabe el comercio que está hablando con un agente de confianza?
En el comercio electrónico tradicional, los bots suelen tratarse como tráfico sospechoso. En el comercio agéntico, parte del tráfico automatizado puede representar a un comprador legítimo que actúa a través de un agente autorizado.
Esto crea un problema nuevo: distinguir la automatización fiable de la maliciosa.
Visa, por ejemplo, desarrolló el Trusted Agent Protocol para permitir que los agentes aprobados se identifiquen ante los comercios. La propuesta incluye firmas y elementos temporales para reducir los ataques de repetición y asociar la solicitud al contexto en el que debe utilizarse.
Los detalles específicos de cada protocolo pueden cambiar. La necesidad es estructural.
El comercio debe poder responder a preguntas como: ¿quién es el agente? ¿En nombre de quién actúa? ¿Qué acción se ha autorizado? ¿Es reciente la solicitud? ¿Se ha modificado? ¿Es válida esta autorización para este dominio y esta acción?
Sin una capa de confianza, el aumento de la automatización puede limitarse a ampliar la superficie de fraude y abuso.
El pago sigue necesitando idempotencia
La llegada de los agentes no elimina los problemas clásicos de los sistemas distribuidos. De hecho, puede hacerlos aún más importantes.
Consideremos un intento de completar un pedido. El agente envía la solicitud, pero la conexión se interrumpe antes de recibir la respuesta. No sabe si se ha creado el pedido. Si repite la acción sin control, puede generar dos pedidos o dos cobros.
La idempotencia permite que la infraestructura reconozca que dos solicitudes representan la misma intención y evite producir efectos duplicados dentro del alcance admitido.
Esto ya es esencial en las API de pago. En el comercio agéntico, pasa a formar parte de la frontera entre dos sistemas autónomos.
Una buena implementación debe identificar, como mínimo, la sesión, la intención de compra y los intentos de ejecución. También debe distinguir un fallo de comunicación de un fallo real de negocio.
Un timeout no demuestra que no haya ocurrido nada.
Los webhooks dejan de ser un detalle de integración
Una experiencia de compra no termina cuando regresa la respuesta a la solicitud HTTP.
Un pago puede confirmarse después. Un pedido puede cambiar de estado. Un artículo puede prepararse, enviarse, cancelarse o reembolsarse. Una entrega puede actualizarse. Un comercio puede necesitar comunicar estos cambios al canal en el que comenzó la compra.
Por eso, los protocolos agénticos tratan los eventos asíncronos como una parte central de la arquitectura.
La documentación del Agentic Commerce Protocol utiliza webhooks para mantener sincronizado el estado del pedido entre el comercio y la experiencia del agente. El mismo principio se aplica a los pagos: los eventos asíncronos ayudan a cerrar el ciclo entre la intención, la autorización y el estado final.
El reto consiste en garantizar que estos eventos se autentiquen, se dedupliquen y se procesen con suficiente orden para que el sistema no retroceda a un estado incorrecto.
Cuando la interfaz deja de ser una página aislada y pasa a ser una relación entre sistemas, la coherencia del estado se convierte en experiencia de usuario.
La tokenización adquiere un papel aún más estratégico
Los pagos agénticos aumentan la importancia de los tokens y las credenciales restringidas.
El PAN de una tarjeta es una credencial sensible y potente. Cuantos más sistemas necesiten interactuar durante una compra, mayor será la necesidad de reducir la exposición de esa credencial.
La tokenización permite sustituir datos primarios por identificadores con un alcance controlado. Según el modelo, un token puede estar asociado a un comercio, dispositivo, canal o escenario de uso.
EMVCo define Payment Tokenisation como una forma de sustituir el PAN por un valor alternativo cuyo uso puede restringirse a contextos específicos.
En una arquitectura agéntica, esta característica es especialmente valiosa: el agente no necesita recibir una credencial universal para poder participar en la experiencia.
La tendencia es acercar identidad, intención y credencial. En lugar de preguntar simplemente si existe un medio de pago válido, la infraestructura pasa a preguntar si este actor puede utilizar esta credencial, en esta compra y dentro de estos límites.
El comercio agéntico y la orquestación de pagos convergen
Cuando un agente inicia una compra, el problema del procesamiento sigue existiendo después de que la intención llegue al comercio.
El pago puede seguir pasando por una pasarela, un PSP, un adquirente, sistemas antifraude, autenticación y otros componentes. Si la operación trabaja con varios proveedores, sigue siendo necesario decidir qué ruta utilizar.
Esto crea una conexión natural entre el comercio agéntico y la orquestación de pagos.
El agente no necesita conocer la topología interna de pagos del comercio. Expresa la intención comercial. La infraestructura del comercio y su capa de orquestación pueden decidir cómo ejecutar esa intención según reglas de disponibilidad, método, geografía, coste, rendimiento y riesgo.
Esta separación es saludable porque evita exponer la complejidad operativa al canal.
Un agente no debería necesitar saber qué adquirente procesa la transacción para poder completar la compra. Del mismo modo, el comercio no debería tener que modificar el agente cada vez que cambia su estrategia de enrutamiento.
Los agentes aumentan la importancia de la observabilidad
Cuando un usuario dice que una compra realizada por un agente ha fallado, el equipo debe poder reconstruir lo ocurrido.
¿Se encontró el producto correcto? ¿Estaba actualizado el precio devuelto? ¿Se confirmaron las existencias? ¿Caducó la sesión de checkout? ¿La autorización del usuario estaba dentro de los límites? ¿Era válido el token? ¿Se rechazó el pago? ¿Hubo un timeout? ¿Se creó el pedido? ¿Llegó un webhook después?
Sin correlación entre estos eventos, el nuevo canal puede crear una caja negra operativa.
Por eso, el comercio agéntico exige una observabilidad que atraviese fronteras.
No es necesario exponer todos los detalles internos al agente, pero la operación debe poder correlacionar una intención con una sesión, un pedido, un intento de pago y sus eventos asíncronos.
Los identificadores coherentes forman parte de la arquitectura.
¿Qué cambia para la prevención del fraude y el riesgo?
Hoy, muchas estrategias de riesgo utilizan señales vinculadas a la sesión de un usuario en un navegador: dispositivo, IP, comportamiento, historial, identidad y contexto de la compra.
Cuando un agente entra en el flujo, parte de ese contexto cambia.
Una solicitud puede proceder de la infraestructura del agente y no del dispositivo final del comprador. El comportamiento de navegación puede desaparecer. Al mismo tiempo, surgen nuevas señales: identidad del agente, cadena de delegación, límites explícitos, firma de la solicitud e historial de autorizaciones agénticas.
Eso no significa que los agentes sean necesariamente más o menos seguros. Significa que el modelo de riesgo debe comprender a un nuevo actor.
Intentar evaluar una transacción agéntica utilizando exactamente las mismas señales que en la navegación humana puede producir falsos positivos o dejar lagunas.
La evolución probable es combinar las señales tradicionales de pago con señales propias de la delegación y la identidad del agente.
El usuario sigue necesitando control
La automatización no elimina el consentimiento.
Cuanto más autónomo sea un agente, más importante resulta definir de antemano qué puede hacer.
Existe una diferencia profunda entre un agente que solicita confirmación para cada compra y un agente corporativo autorizado a reponer un determinado suministro cuando las existencias caen por debajo de un límite. Ambos pueden tener sentido, pero exigen modelos de permisos diferentes.
El sistema necesita saber si la acción exige confirmación en ese momento o si existe una autorización previa válida.
Este es uno de los motivos por los que los pagos agénticos acercan el mundo de las interfaces comerciales al de las políticas de acceso.
La compra pasa a ser también una cuestión de autorización de software.
Brasil añade sus propias capas
El comercio agéntico global no puede ignorar la realidad local.
En Brasil, una experiencia comercial puede necesitar gestionar Pix, pagos a plazos, boleto, distintos modelos logísticos, normas fiscales y plataformas locales. Esto modifica el diseño de una integración que no puede dar por supuesto que toda compra termina con una tarjeta de crédito y un único flujo de entrega.
AZPay Agents se presentó públicamente precisamente con esa preocupación. La página destaca Pix, el pago a plazos, el envío, la operativa fiscal y las plataformas locales como parte de la realidad del comercio brasileño.
Además de plataformas como Shopify y WooCommerce, el proyecto muestra la conexión con ecosistemas relevantes en el país, como Nuvemshop, Loja Integrada, Tray y VTEX, así como con sistemas de gestión y backoffice como Bling, Tiny ERP, Omie, Conta Azul y Odoo.
El mensaje arquitectónico es importante: adaptar el comercio a los agentes no consiste en crear un catálogo paralelo. Consiste en conectar capacidades que ya existen en distintos sistemas de la operación.
¿Dónde encaja AZPay Agents?
AZPay Agents es una iniciativa de AZPay en colaboración con Trydak para conectar la operación comercial existente a los canales agénticos compatibles.
La propuesta pública es trabajar a partir de la infraestructura que la empresa ya tiene. La capa organiza capacidades que los agentes pueden consultar o utilizar y las prepara para nuevos canales y protocolos a medida que sean compatibles.
Esto conserva una distinción fundamental.
AZPay Agents no parte de la idea de que la empresa debe abandonar su comercio electrónico, ERP o checkout. Parte de la idea de que estos sistemas ya contienen las capacidades de negocio necesarias y deben presentarse de forma adecuada a un nuevo tipo de consumidor de software.
El resultado esperado es un nuevo punto de entrada sin perder el control de la operación.
El catálogo sigue perteneciendo al comercio. El pedido sigue perteneciendo al comercio. El pago sigue en la infraestructura del comercio. La relación con el cliente sigue perteneciendo a la empresa.
El comercio agéntico es un nuevo canal, no un nuevo propietario de la operación
Este principio ayuda a evaluar cualquier propuesta de comercio por agentes.
Si adoptar un nuevo canal exige que el comercio entregue permanentemente el catálogo, las relaciones, los datos, los pagos y la posventa a otra plataforma, se produce un cambio estructural de dependencia.
Si, en cambio, el canal puede operar mediante contratos claros sobre la infraestructura existente, la empresa conserva una mayor portabilidad.
Este debate se parece a la evolución de los pagos. Integrar un PSP resuelve el procesamiento. Orquestar varios PSP crea control sobre las rutas. Del mismo modo, publicar productos en un canal resuelve la distribución. Exponer capacidades comerciales de forma estructurada crea una capa de control que puede servir a distintos canales.
La pregunta deja de ser qué agente dominará el mercado y pasa a ser si tu comercio está preparado para comunicarse con agentes diferentes.
¿Qué debería preparar ahora una empresa?
No es necesario prever exactamente qué protocolo se impondrá para empezar a organizar la arquitectura.
El primer paso es entender dónde están las fuentes de verdad. ¿Qué sistema controla el catálogo? ¿Cuál controla los precios? ¿Cuál controla las existencias? ¿Quién calcula los gastos de envío? ¿Dónde se crea el pedido? ¿Qué sistema representa su estado? ¿Cómo se inicia el pago? ¿Cómo se comunican los cambios posteriores?
El segundo es convertir las capacidades importantes en contratos de integración coherentes. Una API no tiene que ser pública para todo el mundo, pero la empresa necesita saber qué acciones pueden exponerse y con qué permisos.
El tercero es mejorar la identidad y la trazabilidad. Las sesiones, los pedidos, los intentos y los eventos necesitan identificadores que permitan reconstruir una experiencia.
El cuarto es revisar la idempotencia y los eventos asíncronos. Si una integración externa repite una llamada, el sistema debe producir el comportamiento correcto. Si un evento llega dos veces o fuera de orden, la operación no debería corromper el estado.
El quinto es tratar el pago como un dominio separado. El canal debería solicitar una intención de compra; las decisiones de autorización, enrutamiento, riesgo y captura deben seguir bajo el control de la infraestructura de pagos.
¿Necesito reconstruir mi checkout para vender a través de agentes?
No necesariamente.
Esta es una de las preguntas más importantes para las empresas que ahora observan el comercio agéntico. Si el catálogo, las existencias, los precios, el checkout, el pedido y el pago ya existen, la oportunidad está en organizar cómo pueden acceder a esas capacidades los nuevos canales.
Una empresa puede necesitar crear o mejorar API, webhooks y contratos de estado. Puede necesitar revisar la autenticación, la autorización y la idempotencia. Puede necesitar que algunas reglas dependan menos de una interfaz visual.
Pero eso es distinto de abandonar la operación actual.
El principio de AZPay Agents es precisamente conectar lo que ya existe y añadir una capa para agentes.
¿Los agentes sustituirán a los sitios web y las aplicaciones?
Es pronto para considerar inevitable ese resultado.
Los sitios web, las aplicaciones, los marketplaces, la mensajería y los agentes pueden coexistir como canales diferentes. Algunas compras son sencillas y están orientadas por una intención. Otras dependen del descubrimiento visual, el entretenimiento, la marca, la experimentación o la interacción humana.
Lo que parece más relevante desde el punto de vista arquitectónico es preparar el comercio para que no dependa de una única interfaz.
Si el producto, el precio, las existencias, el pedido y el pago solo pueden gestionarse a través de una página concreta, cada nuevo canal exigirá una reconstrucción. Si esas capacidades se organizan como servicios y contratos, pueden surgir nuevas interfaces sin reescribir todo el negocio.
El comercio agéntico funciona como una prueba de madurez de la arquitectura comercial.
El reto no es conseguir que una IA haga clic en comprar
Automatizar un clic es fácil en comparación con el resto del problema.
El verdadero reto es demostrar que la acción estaba autorizada, garantizar que el precio sigue siendo válido, confirmar existencias, calcular las condiciones correctamente, proteger las credenciales, evitar duplicados, procesar el pago, mantener los estados sincronizados y permitir que el equipo explique qué ha ocurrido cuando algo falla.
Por eso, la próxima generación del comercio no se construirá únicamente en la capa de interfaz.
Dependerá de API, identidad, políticas de autorización, tokenización, webhooks, observabilidad, orquestación y sistemas capaces de operar con claridad en entornos distribuidos.
La pantalla puede dejar de ser obligatoria en algunas experiencias. La infraestructura, no.
El comercio más allá de la pantalla
Durante años, el checkout se trató como el punto final de la experiencia digital. El comercio agéntico convierte el checkout en una interfaz entre sistemas.
Esto cambia el tipo de preguntas que deben hacerse las empresas.
No basta con preguntar si un agente puede encontrar mi producto. Hay que preguntar si puede recibir un precio de la fuente autorizada, comprender las opciones disponibles, actuar dentro de una autorización verificable, iniciar un pago de forma segura y seguir el estado real del pedido sin asumir el control de la operación.
Esta es la transición de un comercio diseñado únicamente para personas ante pantallas a un comercio preparado también para agentes.
En AZPay, vemos este cambio como un reto de construcción. El comercio que ya existe debe seguir funcionando. La innovación consiste en crear una capa que le permita participar en nuevos canales sin perder su identidad, control e infraestructura.
Ese es el ámbito de AZPay Agents: conectar el comercio de hoy con el comercio más allá de la pantalla.
Para distinguir el papel de las herramientas, los contratos de checkout y la autorización verificable, consulta MCP, ACP, UCP y AP2: qué resuelve cada protocolo en el comercio por agentes.