Checkout extensibility en Shopify, pasados los plazos

Casi todo lo que se ha escrito sobre checkout extensibility sigue en futuro. No debería. Los plazos que publicó Shopify ya pasaron, las actualizaciones automáticas se ejecutaron, y las tiendas que no migraron no recibieron un aviso: recibieron un checkout con las personalizaciones eliminadas.

Si llegas aquí porque algo de tu checkout dejó de funcionar y nadie encuentra el código que lo hacía, este artículo es para ti. El código no está roto. Ya no está, y se fue en una fecha publicada.

Qué pasó exactamente, y cuándo

La guía de actualización de Shopify no se anda con rodeos. El 28 de agosto de 2025 era la fecha límite para actualizar las páginas de agradecimiento y estado del pedido, «incluidas tus apps que usan script tags y additional scripts». Después, en enero de 2026, «empezaron las actualizaciones automáticas, y todas las personalizaciones que usaran additional scripts, apps con script tags o checkout.liquid en las páginas de agradecimiento y estado del pedido se perderán».

Se perderán. La palabra es de Shopify. No hubo renderizado de respaldo ni modo degradado: la actualización sustituyó la página y lo que colgaba de ella se fue con ella.

Los pasos principales del checkout cayeron antes y más fuerte. checkout.liquid ya no está soportado en los pasos de información, envío y pago. Los script tags en agradecimiento y estado del pedido se retiraron en tiendas Plus en esa misma fecha de agosto de 2025, y en tiendas sin Plus el 26 de agosto de 2026.

Así que no queda ventana de migración que planificar. Queda una auditoría que hacer.

Qué lo sustituyó, sin adornos

Lo que se suele pasar por alto es que checkout.liquid no fue reemplazado por una cosa. Era un archivo que podía hacer cualquier cosa, y lo sustituyeron cuatro superficies distintas, cada una capaz de un subconjunto definido. Ese es el intercambio completo: renunciaste a «editar la plantilla» y recibiste «extender en puntos soportados», que sobrevive a las actualizaciones porque Shopify sabe dónde está tu código.

Las Checkout UI extensions son la parte visible. Componentes de React que se pintan en targets con nombre dentro del checkout: un mensaje de confianza bajo el bloque de pago, un campo de instrucciones de entrega, un upsell sobre el resumen. No eliges posiciones en píxeles: eliges un target, y Shopify decide dónde vive. Es la parte que más frustra a los merchants y la que hace que las actualizaciones del checkout dejen de romper cosas.

Las Functions son la parte invisible, y ahí se fue casi toda la lógica de verdad. Descuentos que las reglas nativas no saben expresar, validación que bloquea un pedido, personalización de métodos de envío y pago, cart transforms que añaden una línea de cargo o expanden un bundle. Se ejecutan dentro de la infraestructura de Shopify en el momento en que calcula el carrito, así que no hay servidor tuyo que pueda ir lento o caerse. Esto lo construimos nosotros, y lo que sorprende no es el lenguaje: es que una Function no puede consultar tu base de datos ni leer un reloj.

Branding y ajustes cubren lo que antes era CSS. Colores, tipografía, radio de esquina, posición del logo, elección de layout: se configuran, no se estilan. Si tu checkout antiguo tenía una maquetación que ningún ajuste sabe expresar, aquí es donde te enteras.

Los web pixels cubren la analítica que vivía en additional scripts. Corren en un sandbox con un esquema de eventos definido, no como JavaScript libre en la página, y por eso muchas configuraciones de gestor de etiquetas hubo que rehacerlas en vez de portarlas.

Qué corresponde a qué

Para auditar un checkout antiguo conviene recorrerlo por intención, no por código.

Todo lo que cambiaba un precio o una regla —descuentos por tramos, precios por grupo de cliente, pedido mínimo, ocultar un método de pago según el carrito, bloquear un apartado postal— es trabajo de Functions. Vino de Scripts, y Scripts también desapareció: la edición se deshabilitó el 15 de abril de 2026 y todos los Scripts publicados dejaron de ejecutarse el 30 de junio de 2026. Si tus reglas eran Scripts, ahora mismo no están corriendo: aquí está la cronología con fechas, incluido el plazo aparte de los script tags que llega a marzo de 2027 y pilla a quien creía haber terminado.

Todo lo que mostraba o recogía algo —un campo de mensaje de regalo, un selector de fecha de entrega, un aviso de política de devoluciones, un número de pedido B2B— es una UI extension.

Todo lo que se veía de cierta manera es branding, y aquí la respuesta honesta a veces es «eso no vuelve». Un checkout reconstruido visualmente en Liquid no se porta. Lo que se porta es la intención que había detrás.

Todo lo que disparaba una etiqueta es un web pixel, y hay que volver a probarlo, no reapuntarlo: los nombres de evento y las cargas no son los que escuchaban tus scripts viejos.

Cómo averiguar qué perdiste

Si la actualización automática corrió sobre una tienda que heredaste, puede que nadie sepa qué había. Tres sitios donde mirar, por orden de utilidad.

El historial del tema o una copia anterior a la actualización, si existe. El checkout.liquid viejo es la especificación de todo lo que ocurría, y es el único lugar donde la intención está escrita.

Los propios pedidos. Atributos de pedido, notas y propiedades de línea que dejaron de aparecer en pedidos nuevos te dicen exactamente qué campo desapareció y más o menos cuándo.

Los tickets de soporte y las quejas internas. En la práctica es la señal más rápida: lo que falta ya suele estar reportado como «los clientes ya no pueden dejar instrucciones de entrega», y nadie lo relacionó con un plazo de plataforma.

Lo que conviene decir sin rodeos

Checkout extensibility se cuenta como una limitación, y en sentido estricto lo es: hay cosas que el archivo antiguo hacía y que ningún punto de extensión hará nunca. Pero el arreglo anterior era uno en el que cada mejora del checkout de Shopify amenazaba con romper tu tienda, así que las mejoras iban lentas y tus personalizaciones eran frágiles en ambos sentidos.

El arreglo actual es peor para la tienda que quiere un checkout a medida y mucho mejor para la que quiere un checkout que siga funcionando. La mayoría son del segundo tipo y les habían vendido el primero.

Si tu checkout perdió algo en la actualización, la pregunta útil no es cómo recuperar la implementación vieja. Es a cuál de las cuatro superficies pertenece ahora esa intención, y si escrita así sobrevive a la próxima actualización sin que nadie tenga que pensarlo. Ese es el trabajo que hacemos aquí.