ACP, UCP y AP2 comparados: los protocolos de comercio agéntico en octubre de 2026 y cuál necesita tu tienda

Tres protocolos abiertos describen ya cómo compra un agente de IA en una tienda. El Agentic Commerce Protocol (ACP) viene de OpenAI y Stripe. El Universal Commerce Protocol (UCP), de Google y Shopify. El Agent Payments Protocol (AP2), que Google puso en marcha y cedió a la FIDO Alliance en abril, no es en absoluto un protocolo de checkout: define una prueba firmada de que un usuario autorizó un pago y está diseñado para funcionar dentro de UCP. Los tres usan la licencia Apache 2.0.

A 22 de octubre de 2026 están en situaciones muy distintas. ACP lleva la etiqueta beta, su última versión es 2026-04-17 y no recibe ningún commit desde el 17 de julio. ChatGPT, su principal usuario, abandonó en marzo el checkout independiente y ahora usa ACP sobre todo para recibir datos de producto. UCP publicó en agosto una versión incompatible con las anteriores, 2026-08-25, mientras que las propias superficies de Google siguen con 2026-04-08 y su checkout está en acceso anticipado, solo en Estados Unidos. AP2 está en la v0.2, y ningún producto de Google documenta que lo use.

Este artículo es para los CTO y los jefes de desarrollo de tiendas y plataformas de comercio que tienen que decidir qué implementar. Para saber qué pide cada plataforma de IA a una tienda como negocio, empieza por nuestra visión general del comercio agéntico.

Comparativa

ACP: el Agentic Commerce Protocol

Gobernanza y versiones

El repositorio de la especificación dice que ACP lo mantienen OpenAI y Stripe, y lo etiqueta como beta. Su documento de gobernanza convierte a las dos empresas en Founding Maintainers (mantenedores fundadores): nombran los puestos del comité de dirección (hasta siete) y conservan un veto para usarlo «como último recurso». Meta se unió como tercer mantenedor principal y miembro del comité el 24 de abril de 2026. La documentación de Stripe presenta ACP como «creado por Stripe, OpenAI y Meta», pero el archivo de avisos del repositorio solo atribuye la autoría a OpenAI y Stripe. Pasar a una fundación neutral solo figura como un posible camino futuro.

Hay cinco versiones fechadas: 2025-09-29 (checkout y pago delegado), 2025-12-12 (cambios incompatibles aprendidos de los adaptadores de URBN y Etsy), 2026-01-16 (un proveedor de 3DS elegido por el comerciante), 2026-01-30 (negociación de capacidades, extensiones y un marco de gestores de pagos incompatible con lo anterior) y 2026-04-17 (carrito, feed, pedidos, autenticación delegada, descubrimiento y MCP), que declaró obsoleta la 2026-01-30. En los seis meses transcurridos desde entonces no ha salido ninguna versión. La carpeta unreleased/ contiene cambios menores fechados hasta el 17 de julio, como un ID de actualización del feed y una URL de producto opcional en los artículos del checkout.

Qué implementa un comerciante en 2026-04-17

La API de checkout la aloja el comerciante y la llama el agente:

• POST /checkout_sessions crea una sesión, POST /checkout_sessions/{checkout_session_id} la actualiza (un POST, no un PUT), un GET sobre esa ruta la recupera, y .../complete y .../cancel la cierran.
• Las peticiones llevan una clave de API de tipo bearer y un header API-Version obligatorio. Desde 2026-04-17, el Idempotency-Key es obligatorio en todos los POST, con errores definidos: 400 idempotency_key_required, 409 idempotency_in_flight y 422 idempotency_conflict.
• La petición de creación lleva un objeto capabilities. El agente declara lo que admite y el vendedor devuelve la intersección, así que una incompatibilidad aparece antes del pago.
• El comerciante envía por POST los eventos de pedido a un receptor que aloja OpenAI en /agentic_checkout/webhooks/order_events, firmados con HMAC-SHA256 en un header Merchant-Signature. Los estados van de created a delivered o canceled, y adjustments[] recoge reembolsos, devoluciones, disputas y contracargos.

La versión 2026-04-17 también añadió un /.well-known/acp.json estático y público, cuyo campo transports indica si la tienda habla rest, mcp o ambos. Añadió un binding de MCP sobre Streamable HTTP con cinco herramientas (create_checkout_session, get_checkout_session, update_checkout_session, complete_checkout_session, cancel_checkout_session), autenticado en la configuración del servidor y no en cada petición. Y añadió una Feed API que aloja el agente y a la que el comerciante envía los datos (POST /feeds, PATCH /feeds/{id}/products), un carrito de un solo vendedor sin datos de pago (POST /carts, PUT /carts/{id}) y la autenticación 3DS2 delegada (POST /delegate_authentication). No hay suscripciones: el RFC de extensiones recoge subscription como «Soporte para cobros recurrentes (futuro)».

Cómo funciona el pago en ACP

La respuesta original de ACP es el pago delegado. El PSP o el servicio que custodia las tarjetas (card vault) implementa POST /agentic_commerce/delegate_payment, que convierte una tarjeta (el único tipo de credencial) en un token que el PSP del comerciante solo puede usar dentro de unos márgenes: reason (solo one_time), max_amount, currency, checkout_session_id, merchant_id y expires_at. En palabras del RFC: «Los pagos, la liquidación y el cumplimiento normativo siguen pasando por la infraestructura del comerciante». Worldpay documenta su propia versión de la llamada, y PayPal admite ACP mediante tokens delegados en Braintree.

Desde 2026-01-30, los métodos aceptados se declaran como gestores de pagos en capabilities.payment.handlers. Los datos de pago de ejemplo del registro de cambios:

{ "handler_id": "card_tokenized", "instrument": { "type": "card", "credential": { "type": "spt", "token": "spt_123" } } }

El spt es el Shared Payment Token de Stripe, disponible «en EE. UU., Canadá y determinados países europeos». Un vendedor que usa Stripe lo cobra con payment_method_data[shared_payment_granted_token] en una versión preliminar (preview) de la API; un vendedor con otro procesador puede resolverlo una sola vez en credenciales de red. Nuestro artículo sobre pagos agénticos explica quién asume el riesgo.

Qué cambió el giro de OpenAI en marzo

El 24 de marzo de 2026 OpenAI escribió que «la versión inicial de Instant Checkout no ofrecía el nivel de flexibilidad que aspiramos a proporcionar», permitió a los comerciantes usar sus propios checkouts y dijo que estaba «ampliando ACP para que sea la capa de conexión entre comerciantes y usuarios a lo largo de todo el descubrimiento». Target, Sephora, Nordstrom, Lowe's, Best Buy, The Home Depot y Wayfair habían integrado ACP para el descubrimiento, y los catálogos de Shopify llegan a través de Shopify Catalog. Lo que significa para un desarrollador:

• El feed es la parte activa. La página para comerciantes de OpenAI dice que las compras «se completan en webs o apps propiedad del comerciante» y que las compras están activas para los usuarios de EE. UU. El alta del feed es para socios aprobados que entran desde una lista de espera: un archivo completo diario por SFTP con nueve campos obligatorios, actualizaciones por API a lo largo del día y promociones solo por API. La carga estándar «por ahora se dirige a EE. UU.».
• El checkout es otra puerta. La especificación del feed dice que el checkout «requiere una integración habilitada por separado». Para las apps de ChatGPT, la vía con disponibilidad general es un checkout externo en el dominio propio del desarrollador. La hoja de pago dentro del chat es una beta privada «limitada a determinados marketplaces», que entrega un token de pago al servidor MCP de la app en una llamada a la herramienta complete_checkout.
• Las páginas de OpenAI van por detrás de la especificación. Su referencia del checkout sigue mostrando API-Version 2025-09-12 y un enum provider con stripe, adyen y braintree. Desarrolla según el repositorio y confirma con OpenAI qué versión acepta.

Las páginas de PSP que todavía presentan Instant Checkout como activo están desactualizadas.

UCP: el Universal Commerce Protocol

Gobernanza y versiones

Google lanzó UCP el 11 de enero de 2026, desarrollado junto con Shopify, Etsy, Wayfair, Target y Walmart. Las normas de gobernanza dan a Google y a Shopify un voto permanente a cada uno en el Governing Council (consejo de gobierno), al que se unió Stripe el 28 de abril de 2026, y establecen que «Google tiene el voto delegado de todos los puestos vacantes hasta diciembre de 2028». El 24 de abril, el Shopping Tech Council pasó a tener 16 puestos con la entrada de Amazon, Meta, Microsoft, Salesforce y Stripe, así que Meta y Stripe están ahora tanto en el comité de ACP como en el consejo de UCP.

El repositorio tiene cuatro versiones. 2026-04-08 añadió las capacidades de carrito y catálogo, la firma de peticiones y respuestas, y Get Order. 2026-08-25 rompe la compatibilidad: signing_keys[] dejó paso a un JWK Set en keys[], las extensiones de pago pasaron de dev.ucp.shopping.* a dev.ucp.common.payment.*, los esquemas compartidos cambiaron de sitio y de URL $id, y los PAN y los tokens de red pasaron a ser tipos de credencial distintos. También añadió 3DS2 independiente del proveedor, pagos divididos, condiciones de pago e interoperabilidad con Web Bot Auth.

Aquí está la trampa. La guía de perfiles de Google solo cubre 2026-04-08 y 2026-01-23, el propio perfil de agente de Google en ucp.goog declara "version": "2026-04-08", y Salesforce B2C Commerce 26.9 sirve esas mismas dos versiones. El Checkout MCP de Shopify, en cambio, enlaza a 2026-08-25. Si desarrollas según la última versión, desarrollas una versión que Google no documenta. La respuesta de la especificación es un objeto supported_versions que asigna a cada versión anterior su propia URI de perfil.

Descubrimiento, transportes y autenticación

Cada negocio publica un perfil en /.well-known/ucp con ucp.version, ucp.services y ucp.payment_handlers, y Google exige que sea público y sin autenticación. La plataforma del agente también publica uno, y cada petición lleva su URI en un header UCP-Agent, por HTTPS con TLS 1.3 como mínimo. La autenticación la elige el negocio: ninguna, X-API-Key, OAuth 2.0, TLS mutuo o HTTP Message Signatures según el RFC 9421. Google envía un token bearer, y sus preguntas frecuentes también ofrecen mTLS. El Idempotency-Key es solo un «SHOULD» (una recomendación); un servidor que lo acepta lo conserva al menos 24 horas y responde con un 409 cuando se reutiliza con un cuerpo distinto.

REST es el transporte principal, junto con MCP, una extensión A2A y un modo integrado al que se llega mediante un continue_url. Los pedidos son un GET /orders/{id} más un webhook del negocio a la plataforma firmado según el RFC 9421. Las rutas del carrito son las mismas que en ACP. Las operaciones de checkout se parecen, pero no son intercambiables:

Un mismo núcleo de checkout puede servir a los dos. Una misma tabla de rutas, no.

Cómo funciona el pago en UCP

UCP no mueve dinero. Un gestor de pagos es una especificación escrita por un proveedor de credenciales, como com.google.pay para Google Pay o dev.shopify.shop_pay para Shop Pay. El negocio enumera los gestores que acepta, la plataforma ejecuta uno y, en complete, el negocio recibe un token opaco que cobra a través de su propio PSP.

En las superficies de Google el único gestor es Google Pay, PAN_ONLY es el único método de autenticación que se usa y tu PSP «debe poder procesar nuestros tokens». Stripe publica com.stripe.payments para tarjeta y Apple Pay: «El agente envía un shared payment token (SPT) en la petición Complete Checkout y el vendedor lo cobra». Google Pay sigue con su propio gestor. PayPal acepta el gestor de Google Pay a través de Braintree o de su API Orders v2.

Qué exige Google antes de llamarte

La guía del checkout integrado de Google pide la API REST de checkout y se queda con el paso del pago: el comprador introduce los datos sensibles «solo con la interfaz de Google». Sus niveles de servicio son una disponibilidad de al menos el 95% en cada endpoint, con latencias p50 y p95 de 1 y 4 segundos para crear, de 1 y 5 para actualizar y de 6 y 10 para completar. Después de un pedido, envías las actualizaciones de estado a un webhook de Google con un ID de socio y una clave que se emiten en el alta. En Merchant Center, cada producto necesita native_commerce(checkout_eligibility) con el valor true («tiene FALSE como valor predeterminado»), la política de devoluciones y el contacto de atención al cliente son obligatorios, y quedan excluidos las suscripciones, los pagos a plazos, los productos personalizados, los artículos usados y reacondicionados, las preventas y los productos con restricción de edad.

La opción más ligera, desde 2026-04-08, es la transferencia del carrito: solo implementas la creación del carrito, Google entrega el carrito a tu web y no hace falta ni gestor de pagos ni webhook de pedidos.

El acceso es el verdadero límite. El checkout está «disponible para comerciantes seleccionados» a través de un formulario de interés de acceso anticipado, en el que te comprometes a empezar en un plazo de 30 días y aceptas que el acceso «puede retirarse» si no avanzas. Las condiciones de UCP Checkout se aplican «solo a Estados Unidos». El hub de Merchant Center llegará después a Australia y Canadá, «a principios del año que viene»; Google no da fecha de checkout para ningún otro país.

UCP fuera de Google

Microsoft Merchant Center acepta feeds compatibles con UCP en EE. UU. desde el 21 de abril de 2026. Copilot Checkout necesita un feed conforme a UCP, admite a comerciantes en lengua inglesa que venden a compradores de EE. UU. en dólares, con un PSP cada uno, y su ajuste en la tienda está marcado como «solo un piloto para clientes seleccionados». Shopify expone UCP sobre MCP en https://{shop}/api/ucp/mcp y ha retirado sus antiguas herramientas de catálogo y carrito. El 24 de septiembre de 2026 se fusionó como borrador una capacidad de reserva de alojamiento, que no está en ninguna versión.

AP2: el Agent Payments Protocol

AP2 no es una tercera forma de hacer el checkout. Su especificación dice que «funciona como una función de seguridad dentro de un protocolo de comercio» y que está «diseñado explícitamente para ser compatible con el Universal Commerce Protocol (UCP)». La versión 0.1.0 salió el 16 de septiembre de 2025 y la v0.2, el 28 de abril de 2026, el día en que Google donó AP2 a la FIDO Alliance. El anuncio de FIDO cita un grupo de trabajo de Agentic Authentication y otro de Payments, presididos por miembros de Mastercard y Visa, y dice que las contribuciones «se revisarán y se seguirán desarrollando». FIDO no ha publicado ninguna especificación de AP2. El repositorio de GitHub ya solo acepta ejemplos y cambios del SDK, y su último commit es del 29 de abril.

La versión 0.2 define un Checkout Mandate (el mandato sobre lo que se compra) y un Payment Mandate (el mandato sobre el pago, con restricciones como payment.amount_range, payment.budget y payment.allowed_payees). Cada uno es un SD-JWT con una forma cerrada y otra abierta (mandate.payment.1 y mandate.payment.open.1, por ejemplo). En el modo Human Present (con la persona presente), el usuario aprueba los mandatos cerrados. En el modo Human Not Present (sin la persona presente), el usuario aprueba mandatos abiertos que fijan restricciones y que llevan la clave pública del agente en un claim cnf, y el agente monta los cerrados dentro de esos límites. Los tutoriales que hablan de Intent Mandates y Cart Mandates describen la v0.1; esos términos han desaparecido de la v0.2.

Dentro de UCP, AP2 es la extensión dev.ucp.common.payment.ap2_mandate (dev.ucp.shopping.ap2_mandate antes de 2026-08-25). Una vez negociada, el negocio firma sus respuestas de checkout, la plataforma presenta un checkout_mandate y un payment_mandate en complete, y la sesión queda «bloqueada por seguridad» (Security Locked): ninguna de las partes puede volver a un checkout normal.

Nadie lo pide todavía. Las preguntas frecuentes de Google dicen que AP2 es «especialmente útil para escenarios futuros con transacciones autónomas de agentes de IA». El propio perfil de agente de Google indica Google Pay como su único gestor de pagos y no declara ninguna capacidad AP2, y su perfil 2026-08-25 tampoco tiene ninguna entrada de AP2. Ningún producto de Google documenta el uso de AP2, así que un comerciante no tiene nada que desarrollar hasta que una plataforma lo negocie.

Los protocolos vecinos

MCP

ACP y UCP pueden funcionar sobre MCP, cuya especificación actual, 2026-07-28, elimina las sesiones y el header Mcp-Session-Id, suprime el handshake initialize, exige server/discover y hace que un cliente vuelva a emitir una petición con un ID nuevo cuando se corta su stream. El binding de ACP sigue enlazando el transporte 2025-11-25. Un ID de sesión de checkout es exactamente el identificador emitido por el servidor que espera la nueva especificación, y un complete perdido a mitad del stream vuelve como una petición nueva: trata las claves de idempotencia como obligatorias en los dos protocolos.

WebMCP

WebMCP es un estándar web propuesto para exponer las funciones de una página a los agentes del navegador. Shopify ofrece el checkout de UCP como Checkout MCP y como Checkout WebMCP, con el mismo objeto de checkout, y recomienda Checkout MCP. Nuestra guía de WebMCP explica en qué punto está.

x402 y MPP

x402 y el Machine Payments Protocol, diseñado por Tempo y Stripe, cobran a un agente por cada petición HTTP a una API, a unos datos o a un contenido. No son protocolos de checkout para tiendas. Consulta nuestro artículo sobre x402.

Visa Trusted Agent Protocol y Mastercard Agent Pay

Estos funcionan junto a ACP y UCP, no los sustituyen. El Trusted Agent Protocol de Visa da a un agente «un método criptográfico estandarizado» para demostrar ante los comerciantes su identidad y su autorización, y Mastercard Agent Pay es un programa de tokenización para el comercio agéntico. La guía para comerciantes de Mastercard sitúa UCP y ACP en su nivel de preparación más alto, señala que «los primeros en adoptarlos los están integrando ya» y aconseja a los comerciantes empezar por sus dos niveles más sencillos. Nuestro artículo sobre pagos agénticos cubre los dos programas.

Personal Agent Protocol

Sierra dice que anunció el Personal Agent Protocol («Poppy») con Meta el 6 de octubre de 2026, y publicó un borrador el 9 de octubre. Una empresa publica un único archivo en /.well-known/poppy.json; el protocolo usa OAuth, JWT, HTTPS, OpenAPI y MCP para que un agente personal se identifique y obtenga el permiso del cliente para cualquier tipo de tarea, y Sierra lo considera complementario de UCP. La web del protocolo muestra la versión 0.2 y dice «Es un borrador». No encontramos ninguna publicación sobre él en la sala de prensa de Meta.

¿Cuál necesitas?

En Shopify

Nada que desarrollar. Los agentic storefronts (escaparates agénticos) de Shopify están «activos por defecto para las tiendas que cumplen los requisitos». ChatGPT recibe tu catálogo a través de Shopify Catalog y envía a los compradores a tu tienda. El checkout directo de Google está activado por defecto para las tiendas con sede en Estados Unidos que venden allí, y Copilot inscribió automáticamente a los comerciantes de Shopify. Lo que decides tú son los datos de producto y si mantienes activado el checkout directo, sabiendo que los píxeles personalizados no se disparan en el de Google.

En Salesforce, commercetools u otra plataforma

Salesforce B2C Commerce 26.9 sirve UCP 2026-01-23 y 2026-04-08: /.well-known/ucp con un mapa supported_versions y los endpoints de sesión de checkout detrás de un token SLAS. Según Salesforce, el checkout de UCP en Google tiene disponibilidad general en octubre de 2026. Una sesión es una vista headless de una cesta, y la guía de auditoría de Salesforce advierte de que los controladores de SFRA y SiteGenesis y «otros recursos de SCAPI que usas hoy no se ejecutan en este flujo», así que la lógica asociada a ellos hay que copiarla o conectarla con los hooks de sesión de checkout de UCP. El feed tiene que dirigirse a en-US, y Salesforce «no se salta la lista de espera de Google». Para ChatGPT, Salesforce es una de las vías de entrega que cita OpenAI para los feeds de ACP.

En commercetools u otra plataforma, pregunta al proveedor qué versiones y capacidades de UCP sirve, cuáles de tus hooks se ejecutan en un checkout de agente y si envía feeds a OpenAI.

Con software propio

1. Primero, los feeds. Google Merchant Center y, cuando OpenAI te admita, su feed de productos. El uso comercial que tiene hoy ACP en ChatGPT es exactamente este.
2. UCP para Google, si vendes en Estados Unidos y Google te admite. Desarrolla según 2026-04-08: el perfil con com.google.pay, las operaciones de checkout dentro de los objetivos de latencia de Google, un PSP que procese los tokens de Google Pay, el webhook de pedidos y el atributo del feed. O empieza solo con la transferencia del carrito.
3. Checkout de ACP solo si hay un motivo, como una app de ChatGPT admitida en la beta de la hoja de pago. Desarrolla según la 2026-04-17 del repositorio.
4. AP2: nada por ahora.
5. Un único núcleo de checkout. Los dos protocolos quieren una sesión que se pueda crear, actualizar, completar y cancelar por API, y reintentar sin riesgo. Desarróllala una sola vez sobre tu lógica de pedidos, impuestos y pagos, con adaptadores finos de ACP y UCP encima y MCP donde los agentes lo necesiten.

Ninguno de los dos protocolos ofrece hoy a un negocio de suscripciones un checkout de agente nativo.

Si solo vendes fuera de Estados Unidos

Ninguno de los tres te da hoy un checkout de agente. Las compras en ChatGPT y la carga estándar de feeds de OpenAI son de EE. UU.; las condiciones de UCP Checkout de Google son solo para EE. UU.; Copilot Checkout atiende a compradores de EE. UU. en dólares. El siguiente paso anunciado por Google es el hub de Merchant Center en Australia y Canadá «a principios del año que viene», sin fecha para el Reino Unido ni para la UE.

Mantén completo tu feed de Merchant Center y, si de todos modos vas a rehacer el checkout, desarrolla el núcleo basado en API que se describe arriba, para que un adaptador sea un trabajo pequeño cuando se abra tu mercado. ¿Vendes a Estados Unidos desde el extranjero? Comprueba dónde exige cada programa que tenga su sede el comerciante; el checkout directo de Google en Shopify, por ejemplo, exige una tienda estadounidense.

Dónde conseguir ayuda

Desarrollamos la capa de protocolos para tiendas que no funcionan con Shopify: un perfil /.well-known/ucp y endpoints de sesión de checkout sobre tu lógica actual de pedidos, impuestos y pagos, webhooks de pedidos hacia Google, feeds de productos para Google Merchant Center y OpenAI, y servidores MCP que exponen ese mismo checkout a los agentes. Nuestro servicio de desarrollo de agentes de IA e integración MCP es donde empieza ese trabajo.

Escribe a office@c9group.dev con tu plataforma, tu proveedor de pagos y los países en los que vendes, y te diremos qué protocolo se aplica y qué supondría implementarlo. Las condiciones de los programas de Google y OpenAI son contratos: somos ingenieros, no abogados, así que pide a un asesor que las lea antes de firmar.