Shopify Checkout Extensibility: Lo Que Todo Merchant Plus Debe Saber en 2026

Shopify Checkout Extensibility: Lo Que Todo Merchant Plus Debe Saber en 2026

Si tienes una tienda Shopify Plus y alguien de tu equipo mencionó que "checkout.liquid ya no funciona," tenía razón, y el momento importa más de lo que la mayoría de los merchants creen. Shopify eliminó checkout.liquid para los pasos principales del checkout (Información, Envío, Pago) en agosto de 2024. Las páginas de Thank You y Order Status resistieron un poco más, pero ese plazo también pasó, en agosto de 2025 para las tiendas Plus. Si estás en un plan que no es Plus, tu propio corte es el 26 de agosto de 2026, a siete semanas de hoy. Después de esa fecha, Shopify actualiza automáticamente cada tienda que todavía corre scripts legacy y elimina cualquier personalización que estuviera en checkout.liquid o en el campo Additional Scripts.

Esto no es una actualización menor de la plataforma. Es un reemplazo arquitectónico completo, y entenderlo ahora te ahorra descubrirlo de la peor manera, cuando tu pixel de Meta deja de disparar o tu app de upsell post-compra se queda en silencio.

Por qué checkout.liquid tenía que desaparecer

checkout.liquid permitía a los desarrolladores insertar HTML, CSS y JavaScript directamente en la página de checkout. Esa flexibilidad también era el problema. La inyección de scripts sin restricciones en una página que maneja datos de pago es un riesgo de seguridad, y hacía que el checkout cargara más lento conforme más apps acumulaban scripts en la misma página. También complicaba el trabajo de Shopify: cada nueva función de checkout tenía que considerar el código personalizado que los merchants habían insertado a lo largo de los años, lo que frenaba las mejoras a la experiencia de compra principal.

La respuesta de Shopify fue mover la personalización a un modelo aislado (sandboxed). En lugar de que merchants y desarrolladores escriban directamente en la página, ahora construyen a través de puntos de extensión estructurados que Shopify controla y puede actualizar de forma segura por debajo. Esa es la premisa completa de Checkout Extensibility: conservar la flexibilidad, eliminar el acceso sin restricciones.

Qué es realmente Checkout Extensibility

Checkout Extensibility no es una sola función. Es la combinación de dos sistemas que trabajan juntos, ambos desplegados mediante apps en lugar de pegados en un archivo de tema.

Las UI Extensions manejan la interfaz. A través del editor de checkout y cuentas, merchants y desarrolladores pueden agregar bloques de contenido personalizados, campos de formulario, banners e información de pago o envío en puntos definidos del flujo de checkout. ¿Quieres un campo para nota de regalo antes del pago, un upsell de seguro de envío, o una visualización de puntos de lealtad? Eso es una UI Extension.

Shopify Functions manejan la lógica por debajo. Reglas de descuento, filtrado de métodos de pago, personalización de entregas, validación de carrito, nada de eso vive ya en el checkout visible. Las Functions corren del lado del servidor en un entorno aislado, usando JavaScript o Rust, y reemplazan lo que antes manejaba Shopify Scripts (que Shopify también está retirando, con un plazo separado del 30 de junio de 2026, distinto al de checkout.liquid). Si quieres el detalle técnico para construir y desplegar Functions, lo cubrimos a fondo en /resources/shopify-functions.

Juntas, UI Extensions y Functions cubren la mayoría de lo que los merchants hacían con checkout.liquid. La diferencia es que cada extensión está delimitada, aislada, y sobrevive a las actualizaciones de la plataforma en lugar de romperse cada vez que Shopify toca el código de checkout subyacente.

Qué pueden hacer las UI Extensions

En la práctica, las UI Extensions cubren las personalizaciones que representan la mayoría de las solicitudes de los merchants: agregar un bloque de mensaje que recuerde la política de devoluciones, insertar un campo para una instrucción de entrega, mostrar una fecha estimada de entrega tomada de una integración con paquetería, o mostrar una recomendación de producto en la página de Thank You. Cualquier cosa que cambie lo que ve el cliente o la información que puede ingresar cae en esta categoría, y se construye y mantiene mediante una app en lugar de una edición de código directa.

Qué manejan las Functions

Las Functions operan una capa abajo, en la lógica que decide qué pasa en lugar de qué se muestra. Un merchant con un programa de lealtad por niveles puede usar una Function para aplicar el descuento correcto automáticamente según las etiquetas del cliente. Un merchant que vende internacionalmente puede usar una Function para ocultar ciertos métodos de pago para regiones o montos específicos. Las reglas de validación de carrito, como bloquear que un código de descuento se combine con un producto ya descontado, también corren a través de Functions. Estas son reglas de backend, invisibles para el comprador salvo por su efecto, y son el reemplazo directo de los Shopify Scripts basados en Ruby sobre los que muchas tiendas Plus construyeron años de lógica personalizada.

Qué NO puede hacer Checkout Extensibility

Aquí es donde los merchants se equivocan, normalmente porque un artículo viejo o un desarrollador acostumbrado a la era de checkout.liquid describe el nuevo sistema como un reemplazo directo. No lo es, al menos no para todo.

Las Checkout UI Extensions corren en un entorno aislado y no pueden inyectar JavaScript de terceros arbitrario. Si tu personalización anterior en checkout.liquid dependía de cargar un script externo (un widget de chat, un tag de analítica específico, una librería de formularios personalizada), ese patrón no se traslada directamente. Ya no puedes acceder al DOM completo de la página de checkout como antes, lo cual era en realidad parte del punto: ese acceso sin restricciones era el hueco de seguridad que Shopify cerró. Y algunos patrones legacy muy específicos, particularmente los construidos manipulando el HTML renderizado de checkout.liquid con JavaScript después del hecho, simplemente no tienen equivalente. La funcionalidad tiene que reconstruirse usando el modelo de extensiones, no trasladarse tal cual.

Para el rastreo (tracking) específicamente, la ruta de reemplazo son los Web Pixels, no las UI Extensions ni las Functions. Si tu tracking de checkout estaba construido sobre inyección de scripts personalizados, esa es una auditoría separada de tus personalizaciones visuales y de lógica, y vale la pena tratarla como su propio proyecto en lugar de asumir que queda cubierta en una migración general.

La ruta de migración

La auditoría empieza con un inventario honesto. Revisa cada personalización que actualmente está en checkout.liquid, cada entrada en el campo Additional Scripts tanto en el checkout como en la página de Order Status, y cada app que toca el checkout de alguna forma. Para cada una, pregunta qué hace realmente: ¿cambia la interfaz (candidata a UI Extension), cambia la lógica (candidata a Function), o dispara tracking (candidata a Web Pixel)? La mayoría de las personalizaciones legacy se clasifican claramente en uno de estos tres grupos una vez que separas lo que el código muestra de lo que decide de lo que reporta.

De ahí, el orden de construcción importa. Las Functions normalmente toman más tiempo para construirse correctamente, ya que involucran lógica de negocio real y necesitan pruebas contra casos límite (qué pasa cuando un cliente tiene dos códigos de descuento en conflicto, qué pasa con inventario en cero). Las UI Extensions suelen ser más rápidas una vez que la lógica de las Functions está resuelta, ya que se trata principalmente de posicionamiento y contenido. La migración de Web Pixels suele ser la más rápida de las tres si usas una plataforma de analítica convencional con una integración existente con Shopify, y la más lenta si tu tracking era personalizado y sin documentar.

Recientemente acompañamos a un merchant Plus exactamente en este proceso después de que descubrieran que su app de upsell post-compra había dejado de dispararse en silencio tras la ola de actualización automática de Shopify en enero de 2026. La personalización de la página Thank You llevaba dos años sin mantenimiento dentro de checkout.liquid, y nadie detectó la falla hasta que los datos de conversión de esa página cayeron a cero. La solución tomó cerca de una semana: una UI Extension reemplazó el bloque visual de upsell, una Function manejó la lógica de descuento que antes corría por Scripts, y un Web Pixel restauró el tracking. La lección más importante fue que una auditoría completa seis meses antes habría detectado la dependencia antes de que fallara en producción.

Si no has confirmado qué sistema corre actualmente tu tienda, Settings > Checkout en tu admin de Shopify te lo dice directamente. Un banner de advertencia amarillo o un editor de código visible para checkout.liquid significa que todavía tienes personalizaciones legacy activas. Si en cambio ves el editor visual de checkout y cuentas, ya fuiste migrado, aunque vale la pena revisar si cada personalización que esperabas realmente sobrevivió la transición.

Para merchants que también lidian con la eliminación paralela de Shopify Scripts, tenemos una guía dedicada en /resources/shopify-scripts-deprecation-migration-2026, ya que los dos plazos se confunden con frecuencia y esa confusión sale cara.

Checkout Extensibility no va a desaparecer, y tampoco la presión de migrar antes de que Shopify lo haga por ti. Si quieres una segunda opinión sobre tu configuración actual de checkout, o una reconstrucción completa de lo que checkout.liquid solía manejar, ese es exactamente el tipo de trabajo que hacemos en Shugert. Hemos llevado este proceso de auditoría y migración para merchants Plus que descubrieron huecos solo después de que los datos de conversión o el tracking ya habían fallado, y entre más temprano se corra voluntariamente, más barato sale corregirlo. Puedes ver cómo abordamos estos proyectos en /services.