Shopify Scripts dejó de funcionar el 30 de junio de 2026. Esto es lo que debes hacer ahora.
Si tu tienda tenía un Script personalizado de descuentos, BOGO o paquetes, dejó de ejecutarse el 30 de junio de 2026, en silencio. Sin errores, sin alertas, sin nada en tus registros. Aquí te explicamos exactamente qué pasó, qué implica realmente migrar a Shopify Functions y una respuesta honesta sobre lo que Stackable puede reconstruir para ti.
- Shopify Scripts dejó de ejecutarse el 30 de junio de 2026 para todas las tiendas que aún los usaban.
- Cualquier lógica personalizada de descuentos, BOGO o paquetes que residiera dentro de un Script dejó de aplicarse a partir de esa fecha.
- El fallo es silencioso por diseño: una Shopify Function cuyas condiciones no coinciden con un carrito determinado simplemente nunca se activa. No genera ningún error y Shopify no te avisa.
Los comerciantes que están atravesando esta migración describen el mismo riesgo en los foros de la comunidad de Shopify:
“Mi antiguo Script dejó de aplicar un descuento sin que yo me diera cuenta, y solo lo descubrí porque un cliente se quejó de que le habían cobrado el precio completo. No hubo ningún error, ninguna alerta, nada en los registros de pedidos. Llevaba semanas funcionando con una configuración rota antes de notarlo.”
Ese es el riesgo principal de pasar de Scripts a Functions: una Function o está bien configurada y en funcionamiento, o está mal configurada y en silencio. No existe un estado intermedio visible, así que una condición mal definida, un error de tipeo en un umbral o una regla asignada a la colección equivocada producen exactamente el mismo silencio que una Function que funciona correctamente. La única forma de detectarlo es probar deliberadamente ambos escenarios antes de confiar en ella en producción.
Cuatro cosas que vale la pena saber antes de empezar
Un Script suele convertirse en tres migraciones
Un solo archivo de Script podía afectar a la vez la lógica de descuentos, las tarifas de envío y la personalización de pagos. Functions divide eso en tipos de Function independientes: descuento, entrega y pago, cada uno configurado e implementado por separado. Migrar "mi Script" normalmente significa migrar hasta tres elementos distintos, y esta es la queja que más mencionan los comerciantes sobre este cambio.
Los creadores sin código (no-code) suelen cubrir solo descuentos y BOGO
Si tu Script también afectaba las tarifas de envío o los métodos de pago, un creador sin código de Functions de descuento, Stackable incluido, no llega a esas áreas. Las personalizaciones de entrega y de pago requieren que un desarrollador escriba esa Function directamente.
Conserva ahora el código fuente de tu antiguo Script
Una vez que el Editor de Scripts se retire por completo, el código almacenado en él será irrecuperable. Exporta o copia hoy mismo el código fuente de tu antiguo Script, aunque todavía no estés listo para migrar, para tener una referencia de lo que sea que lo reemplace.
Prueba un carrito que debería activarse y otro que no debería
Antes de confiar en una nueva Function, crea dos carritos de prueba: uno que debería activarla y otro que deliberadamente no debería hacerlo. Una Function que se activa cuando no debería es tan costosa como una que nunca se activa en silencio.
Las tres cosas que explican cada decisión de migración
Casi todo debate sobre qué se puede y qué no se puede reconstruir se reduce a tres hechos: Scripts venía en tres tipos con un solo espacio cada uno, Functions dividió esos tres tipos en cuatro APIs distintas, y una Function tiene que declarar de antemano cada dato que va a leer antes de ejecutarse. Con esto claro, el resto de esta página es pura aritmética.
Shopify Scripts venía en tres tipos
El Editor de Scripts te pedía elegir un tipo antes de escribir una sola línea de Ruby, y ese tipo determinaba qué podía tocar tu código.
Scripts por línea
Los que cambiaban lo que costaban los productos. Recorrían el carrito línea por línea y volvían a fijar el precio, que es donde vivían todos los descuentos escalonados, BOGO, precios de paquete y rebajas.
Scripts de envío
Los que trabajaban con las tarifas de entrega. Podían descontar una tarifa, ocultarla, renombrarla o reordenar la lista que veía el comprador. De esas cuatro acciones, solo la primera es un descuento.
Scripts de pago
Los que trabajaban con los métodos de pago, con los mismos cuatro verbos: ocultar un método, renombrarlo, reordenar la lista o, en la práctica, sobre todo ocultarlo para ciertos carritos.
Ahora la restricción que dio forma a todo Script real que verás: solo se podía publicar un Script de cada tipo a la vez. Un único espacio de línea de producto para toda la tienda. Así que un comerciante que tenía un descuento VIP, un precio de liquidación, un umbral de gasto y una promoción de temporada no escribía cuatro Scripts. Escribía un solo archivo con los cuatro fusionados, normalmente con una regla artesanal de "quedarse con el precio que resulte mejor" al final. Por eso los Scripts reales se ven enredados. No son una sola regla mal escrita: son varias reglas a las que nunca se les permitió estar separadas.
Ver un Script real con cuatro campañas fusionadas en un archivoCuatro APIs de Function las reemplazaron
Shopify no reemplazó Scripts con una sola cosa. Los reemplazó con cuatro, divididas según qué puede cambiar el código y no según en qué parte del carrito se ejecuta.
Discount Function API
Descuentos en dinero. Los descuentos de producto, de pedido y de envío viven todos aquí ahora, en una sola API unificada. Si tu Script cambiaba un precio, es aquí donde va.
La documentación de ShopifyDelivery Customization API
Ocultar, renombrar y reordenar opciones de entrega. Shopify es explícito en que esta es la única API que puede personalizar las opciones de entrega en el checkout, así que una app de descuentos no puede llegar a ella sin importar cómo esté construida.
La documentación de ShopifyPayment Customization API
Ocultar, renombrar y reordenar métodos de pago, además de los términos de pago y si un pedido necesita revisión. La mitad de pagos del antiguo Editor de Scripts, en un solo lugar.
La documentación de ShopifyCart and Checkout Validation API
Bloquear el checkout con un mensaje. Aquí residen los límites de compra, las verificaciones de edad y las reglas de pedido mínimo. Devuelve errores, así que puede detener un pedido, pero no puede cambiarlo en silencio.
La documentación de ShopifyStackable es una app de Discount Function, y solo eso. Construimos funciones de descuento, así que podemos reconstruir cualquier cosa que tu Script hiciera a un precio, incluidos los descuentos de envío. No ofrecemos una personalización de entrega, una personalización de pago ni una función de validación, así que ocultar una tarifa de envío, renombrar un método de pago o limitar una cantidad de compra no es algo que rechacemos por no haberlo construido todavía. Es un tipo de app diferente.
Si juntas las dos mitades, llegas a la frase que los comerciantes descubren por las malas: un Script suele convertirse en tres migraciones. Un Script de línea de producto que además ocultaba una tarifa de envío y bloqueaba un método de pago ahora es una función de descuento, una personalización de entrega y una personalización de pago, escritas e implementadas por separado. Preferimos que lo leas aquí antes de que lo descubras después de la reconstrucción.
Ver un Script de envío que resulta no ser un descuento en absolutoLas Functions son puras, y cada campo se declara de antemano
Un Script se ejecutaba como Ruby normal contra lo que fuera que tuviera el carrito. Una Function se ejecuta en un entorno aislado (sandbox), y Shopify garantiza que no tiene nada de lo siguiente:
- Sin red. Una Function no puede llamar a tu ERP, a tu proveedor de fidelización ni a ningún otro servicio mientras un comprador está pagando.
- Sin reloj. Una Function no puede preguntar qué hora es, así que "mitad de precio los martes" tiene que convertirse en un descuento programado en lugar de una condición dentro del código.
- Sin aleatoriedad. Nada puede lanzar un dado para uno de cada diez compradores.
- Sin sistema de archivos, y sin poder alcanzar un campo que no pidió antes. Cada dato que lee una Function tiene que nombrarse de antemano, en una consulta de entrada, y esa consulta tiene un límite de costo estricto fijado por Shopify.
Esa última regla es la que más le cuesta a los comerciantes, y vale la pena ser precisos sobre a quién le cuesta. No es que Shopify oculte los datos. Nuestra propia consulta de checkout está en el costo máximo que permite Shopify, así que pedir un campo más significa renunciar a otro. Nueve de los tipos de Script que rechazamos hoy se rechazan exactamente por esa razón y ninguna otra, incluyendo omitir artículos que ya tienen rebaja, leer una provincia o código postal, y comprobar cuántos pedidos ha hecho un cliente. Shopify ofrece todos esos datos. Todavía no les hemos hecho espacio. Ese es nuestro límite, y llamarlo una limitación de la plataforma sería mentir.
Solo dos rechazos de toda la biblioteca son limitaciones genuinas de Shopify, y ambas vienen del mismo hecho: todas las funciones de descuento de una tienda se ejecutan en el mismo instante, y ninguna puede ver lo que hicieron las demás. Así que un Script que preguntaba "¿este artículo ya tiene un descuento aplicado?" o medía un umbral contra un subtotal ya reducido no puede ser reconstruido por nosotros ni por nadie más, hoy, a ningún precio. Todo lo demás en nuestra lista de rechazos es algo que nos corresponde arreglar, y lo etiquetamos así en la app y en cada página de la biblioteca.
Leer los dos rechazos que sí son limitaciones de ShopifyFijar un precio no es lo mismo que descontar dinero
Si solo lees una cosa antes de reconstruir un Script a mano, que sea esta. Dos archivos pueden llamar al mismo método, con la misma constante y el mismo mensaje, y significar cosas opuestas. Los dos casos siguientes son reales, ambos son comunes, y la diferencia entre ellos es un signo de resta.
Esto FIJA el precio en $9.99
FIXED_PRICE = Money.new(cents: 999)
Input.cart.line_items.each do |line_item|
next unless line_item.variant.product.product_type == "Clearance"
line_item.change_line_price(FIXED_PRICE * line_item.quantity, message: "Clearance $9.99 each")
end
Output.cart = Input.cartEn un artículo de $79.00, el descuento es de $69.01 y el comprador paga $9.99. Se reconstruye como una oferta de volumen cuya recompensa es un precio fijo, contada por variante y repetible, de modo que se vuelve a fijar el precio de cada unidad.
El ejemplo resuelto, con el carrito y la configuraciónEsto DESCUENTA $9.99
DISCOUNT = Money.new(cents: 999)
Input.cart.line_items.each do |line_item|
next unless line_item.variant.product.product_type == "Clearance"
new_price = line_item.line_price - (DISCOUNT * line_item.quantity)
line_item.change_line_price(new_price, message: "$9.99 off each")
end
Output.cart = Input.cartEn el mismo artículo de $79.00, el descuento es de $9.99 y el comprador paga $69.01. Se reconstruye como una oferta de volumen cuya recompensa es un importe de descuento por unidad, contada por producto y que se activa una sola vez.
El ejemplo resuelto, con el carrito y la configuraciónMismo método, mismos $9.99, misma redacción en el mensaje. La única pista es que el segundo archivo resta de `line_item.line_price` antes de asignar. Si lo lees al revés en un artículo de $79.00, te equivocas por $59.02 en una sola unidad, en cualquiera de las dos direcciones que más duela. Y las dos reconstrucciones no solo difieren en el número: una cuenta por variante y se repite, la otra cuenta por producto y se activa una sola vez, así que también divergen en cuanto el comprador compra dos.
Este es el fallo que el consejo habitual no puede detectar. Una oferta reconstruida que lee el archivo al revés igual se activa en un carrito que debería activarla y sigue en silencio en uno que no debería, así que probar ambas direcciones la deja pasar. Scripts Rescue cierra esa brecha haciendo una pregunta distinta: antes de dejarte publicar, quiere el importe que tu antiguo Script cobraba en un carrito que todavía puedes reproducir, y lo compara con lo que calcula la oferta reconstruida. Con un centavo de diferencia, la publicación se queda bloqueada. De las cinco apps que hoy venden migración de Scripts, nuestra investigación no encontró ninguna que le pida al comerciante demostrar el importe.
En qué se convierte cada fragmento de Ruby dentro de una campaña
Una reconstrucción falla casi siempre en los mismos pocos puntos, y casi nunca son los obvios. La recompensa suele ser fácil. El conteo y la recurrencia son donde el dinero se mueve en silencio, porque un Script los expresa en aritmética y una campaña los expresa en una configuración.
| En tu Script | En una campaña | Dónde falla |
|---|---|---|
change_line_price(PRICE * qty) | Una oferta de volumen con recompensa de precio fijo. | Asignación, no resta. Esta es la trampa de arriba. El precio unitario se convierte en la constante, así que un artículo de $79 se vende a $9.99. |
line_price - (AMOUNT * qty) | Una oferta de volumen con recompensa de importe de descuento por unidad. | La resta es toda la señal. La misma constante que la fila de arriba, una factura completamente distinta. |
line_price * 0.9 | Una recompensa de porcentaje del 10. | El multiplicador es lo que el comprador se queda, no lo que ahorra. Escrito directamente como 90, regala nueve décimas partes del catálogo. |
next unless line_item.quantity >= 3 | Un nivel con una cantidad mínima de 3. | Los niveles son inclusivos en el límite y solo se activa el nivel más alto que se cumple. Los Scripts que apilaban una regla sobre otra no tienen un equivalente de oferta única, y necesitan una oferta cada uno. |
line_items.size > 1 | Una cantidad mínima de 2. | No es la misma regla. Aquí los Scripts contaban líneas de carrito separadas, las campañas cuentan unidades, así que una sola línea con dos del mismo artículo ahora califica donde el Script la ignoraba. |
sets = quantity / (BUY + GET) | Compra X y Llévate Y con las unidades gratis contadas como adicionales. | Dividir solo entre COMPRA en su lugar hace que las unidades gratis sean inclusivas. En nueve unidades de una oferta compra 3 y llévate 1, eso es dos gratis o tres gratis. A un carácter de diferencia, la mitad más regalado. |
customer.tags.include?("vip") | Elegibilidad de cliente limitada por etiquetas. | Shopify hace coincidir las etiquetas de forma exacta, mayúsculas incluidas, mientras que muchos dialectos de Script ponían ambos lados en minúscula antes de comparar. Revisa la ortografía antes de publicar, no después. |
product.tags / product_type / vendor | Alcance de destino configurado por etiquetas, tipos de producto o proveedores. | Una línea de alcance olvidada es el error más costoso de esta tabla, porque convierte "20% de descuento en la etiqueta de rebajas" en 20% de descuento en todo lo que vendes. |
Algo que no encontrarás en esta tabla son las colecciones. Un Script podía leer las etiquetas, el tipo y el proveedor de un producto, pero nunca sus colecciones, así que cualquier código Ruby que afirmara comprobar una colección no hacía lo que parecía hacer. Las campañas sí pueden apuntar a colecciones; tu antiguo Script no podía.
Busca tu Script en lugar de intentar deducirlo
Cada tipo de Script que hemos catalogado tiene su propia página: el Ruby original, cómo se reconoce, la configuración exacta en la que se convierte, un carrito de nuestra tienda de demostración pública con el descuento que calcula el motor real, y el carrito que debe permanecer en silencio. Los rechazos se explican de la misma manera, cada uno etiquetado como una limitación de Shopify, un límite nuestro, o un trabajo para otro tipo de app. Es la referencia que nosotros hubiéramos querido tener al empezar, así que es pública.
- Formas de Script
- 42
- Reconstruidos hoy
- 38
- Rechazados, con motivo
- 21
Una respuesta honesta sobre el alcance
Stackable reconstruye la lógica de descuentos basada en reglas usando Shopify Functions nativas. No ejecuta código personalizado arbitrario.
Esto sí lo reconstruye Stackable
- Descuentos escalonados o por volumen (por ejemplo, "compra 3 o más y ahorra 15%")
- Lógica de Compra X y Llévate Y (BOGO), incluyendo niveles repetibles
- Reglas explícitas de acumulación de descuentos entre ofertas
- Inicio y fin programados, y pausa instantánea en cualquier campaña
Para esto seguirás necesitando un desarrollador
- Código personalizado arbitrario que ejecutaba tu antiguo Script (fórmulas de precios a medida, condiciones puntuales que ningún creador cubre)
- Personalizaciones de envío o entrega (un tipo de Function distinto)
- Personalizaciones de pago (un tipo de Function distinto)
- Cualquier cosa que no se pueda reducir a una configuración de descuento basada en reglas
Si tu antiguo Script hacía algo de esta lista, ningún constructor sin código, Stackable incluido, puede alcanzarlo. Eso es una Function escrita por un desarrollador, no una pantalla de configuración.
Preguntas comunes
¿Han desaparecido mis antiguos Scripts?
Scripts dejó de ejecutarse el 30 de junio de 2026, pero eso no significa necesariamente que el código almacenado en el Editor de Scripts se elimine en ese mismo momento. De todas formas, exporta o copia ahora el código de tu antiguo Script: una vez que Shopify retire por completo el editor, será irrecuperable.
¿Recibiré un error si una Function está mal configurada?
No. Una Function cuyas condiciones no coinciden con un carrito simplemente nunca se activa, en silencio, sin error ni alerta. Prueba siempre con un carrito que debería activarla y otro que no debería hacerlo antes de confiar en ella en producción.
¿Stackable reemplaza todo lo que hacía mi antiguo Script?
Solo la parte basada en reglas: descuentos escalonados y por volumen, BOGO, acumulación de descuentos y programación, todo reconstruido sobre Shopify Functions nativas. Stackable no ejecuta código personalizado arbitrario. Si tu Script hacía algo genuinamente a medida, una fórmula de precios personalizada o una condición que ningún creador cubre, eso todavía requiere que un desarrollador escriba la Function directamente.
¿Qué pasa con la lógica de envío o de pago que manejaba mi Script?
Esos son tipos de Function independientes (entrega y pago) que Stackable no gestiona. Un desarrollador debe migrarlos por separado de tu lógica de descuentos.
¿En qué plan está disponible Scripts Rescue?
Scripts Rescue, la herramienta que lee tu antiguo código Ruby y lo reconstruye, está disponible en el plan Pro. Stackable en sí es gratis de instalar, y el motor de descuentos principal (incluidos los niveles de volumen, Compra X y Llévate Y, las metas de gasto, el envío gratis, la programación y el simulador) es gratis en todos los planes. La recuperación de Ruby, en concreto, no lo es: está junto con multitienda y Shopify Flow en el plan Pro.
¿Cómo sé que el descuento reconstruido cobra lo mismo que el anterior?
Porque te obligamos a demostrarlo antes de poder publicar. Probar un carrito que debería activarse y otro que no es el consejo habitual, y no detecta el peor fallo, que es una oferta que se activa correctamente pero por el importe equivocado. Scripts Rescue te pide el importe que cobraba tu antiguo Script en un carrito que todavía puedes reproducir, lo compara con lo que calcula la oferta reconstruida, y mantiene la publicación bloqueada hasta que ambos coincidan al centavo. Nuestra investigación entre las cinco apps que venden migración de Scripts no encontró ninguna que pida eso.
¿Por qué mi Script se veía tan complicado?
Porque solo se podía publicar un Script de cada tipo a la vez. Una tienda con cuatro promociones activas no podía escribir cuatro Scripts, así que escribía un solo archivo con las cuatro fusionadas y una regla al final que decidía cuál ganaba. La mayoría del código Ruby que parece ilegible en realidad son varias reglas simples compartiendo un espacio, y cada una suele reconstruirse limpiamente por su cuenta.
¿Dónde puedo leer el análisis completo de la migración?
Nuestra primera publicación de blog explica con más detalle la baja de Scripts y el camino de migración, y la biblioteca de ejemplos de Scripts tiene una página por cada tipo de Script con el Ruby original y la reconstrucción exacta.
Funciones relacionadas
Discount Stacking
How to stack discounts in Shopify comes down to settings the platform hides by default: every discount belongs to a class (product, order, or shipping), and whether two discounts combine is decided per offer, per class. Stackable puts those combine switches on every offer, so a volume tier, a spend goal, and free shipping add up exactly the way you configured them, every time.
BOGO / Buy X Get Y
Running BOGO beyond the 100-product cap isn't possible with Shopify's native Buy X Get Y discount: it stops letting you add eligible products once you pass 100, and it only applies once per order. Stackable removes both limits and adds cheapest-item-free logic on top.
Scheduled Sales
Shopify scheduled sales fail two ways in the wild: campaigns that silently never start, and live campaigns with no pause button. Stackable's scheduler runs on the same reliability guarantee as its checkout math, and pausing takes effect storefront-wide in under a minute.
Instala Stackable y reconstruye tus descuentos basados en reglas
Escalones de volumen, BOGO, combinación y programación, funcionando sobre Shopify Functions nativas desde el primer día.
Rescate de Scripts está en el plan Pro. Instalar Stackable es gratis, sin necesidad de tarjeta.