Shopify está sacando la validación del checkout del navegador

Dos entradas de changelog separadas por seis meses parecen mantenimiento rutinario hasta que las pones una al lado de la otra.

El 26 de enero de 2026, las extensiones de UI del checkout pasaron a ser no bloqueantes por defecto: una extensión ya no puede impedir que el comprador avance salvo que el comerciante active explícitamente "Permitir que la app bloquee el checkout". La entrada también dice sin rodeos la recomendación de Shopify: usar Validation Functions en lugar de extensiones de UI para validar.

El 2 de julio de 2026, useBuyerJourneyIntercept y la capacidad block_progress quedaron deprecadas en la versión de API 2026-07, con retirada anunciada para una versión futura. El camino de migración son las Cart and Checkout Validation Functions; rechazar un código de descuento pasa a la API de Function de descuentos.

Eso no son dos ajustes. Es una sola decisión, anunciada dos veces.

Por qué tenía que pasar

Una extensión de UI del checkout es código de cliente que se ejecuta cuando el checkout se renderiza. Eso funciona mientras toda compra pase por un checkout renderizado, y cada vez pasan menos.

Un botón de cartera exprés lleva al comprador de la página de producto al pedido completado sin que la extensión llegue a ejecutarse. Un agente que completa una compra en nombre del comprador tampoco está ejecutando tu componente Preact. Cualquier regla que solo se aplique en una extensión de UI es, por tanto, una regla con agujeros, y los agujeros están en las rutas que más toma un comprador con prisa.

Las Validation Functions corren dentro de Shopify, sobre el carrito y el checkout, venga el pedido de la superficie que venga. Es una red mucho más amplia que la de una extensión de UI, aunque no completa: la matriz de compatibilidad documentada sigue dejando fuera POS, la Create Order API, la edición de pedidos, preventa y try-before-you-buy, y las renovaciones de suscripción. Revisa la matriz para las superficies por las que tu tienda vende de verdad antes de tratar una Function como cobertura total.

Qué significa para extensiones ya publicadas

Si hoy una extensión bloquea el avance, hay tres cosas ciertas. Solo sigue bloqueando donde un comerciante haya activado la capacidad. La API que usa está deprecada. Y el comportamiento que protegía tiene un hueco en las rutas exprés y agénticas que es anterior a ambos anuncios.

La migración parte la validación en dos piezas, que además es una forma mejor:

• La regla se convierte en una Validation Function. Corre en servidor, devuelve errores contra objetivos concretos y aplica en todas las superficies.
• La explicación se queda en la extensión de UI. Renderiza el campo, el texto de ayuda, el motivo por el que el pedido no puede avanzar: la parte que una Function no puede dibujar.

Shopify ha ido ensanchando el lado de las Functions para permitirlo. En abril de 2026, Cart and Checkout Validation incorporó billingAddress y poNumber junto con nuevos objetivos de error, lo que cubre un conjunto de reglas B2B y de cumplimiento que antes no tenían expresión en servidor.

Las reglas a las que afecta, en concreto

Conviene nombrar las reglas que viven en este patrón, porque la mayoría se escribieron hace años y ya nadie recuerda dónde corren.

• Reglas de dirección. Sin apartados postales, sin direcciones de reenvío, sin entrega fuera de una zona de servicio, número de departamento obligatorio en ciertos códigos postales.
• Reglas de cantidad. Mínimos, máximos, múltiplos, límites por cliente en un producto de lanzamiento.
• Reglas de carrito mixto. Mercancías peligrosas que no pueden viajar con nada más, refrigerados que no pueden viajar con secos, artículos frágiles que deben ir solos.
• Reglas de cuenta. Productos solo para mayoreo, números de licencia, órdenes de compra que deben existir antes de que un pedido B2B avance.

Cada una de ellas es una regla sobre si un pedido puede existir, y todas están mal si se saltan tocando un botón de cartera en una página de producto.

Qué hacer al respecto

Inventaría lo que bloquea. Para cada extensión, anota la regla que aplica y pregúntate si esa regla sigue aplicándose cuando el comprador usa una cartera exprés. Todo lo que responda que no ya está roto, con retirada o sin ella.

Mueve la regla antes de que llegue la fecha de retirada. "Una versión futura" no es una fecha, pero una API deprecada en un ciclo trimestral es una cuenta atrás aunque el número aún no esté publicado.

Y revisa el lado del comerciante: una extensión que dependía de bloquear y ahora es no bloqueante por defecto puede estar permitiendo pedidos que antes detenía, y nada en el storefront se verá distinto. Ese es el fallo que conviene encontrar esta semana y no al cierre del trimestre.

Esto es hoy el fondo del trabajo de extensibilidad del checkout, y es la razón por la que el desarrollo de Functions ha dejado de ser un tema avanzado.