Shopify Scripts dejó de ejecutarse el 28 de agosto de 2025. Aquellos ficheros de Ruby que vivían en el Script Editor y que ningún desarrollador quería tocar porque no había manera decente de versionarlos ni de probarlos se apagaron de golpe. Casi un año después seguimos entrando en tiendas Plus donde la sustitución fue lo primero que se encontró en la App Store: una app de descuentos por volumen, otra para ocultar métodos de envío, otra para bloquear contrareembolso por encima de cierto importe. Tres cuotas mensuales, tres proveedores y tres puntos donde el checkout puede romperse.

Qué es una Function y por qué cambia el planteamiento

Una Shopify Function es código propio que se compila a WebAssembly y que Shopify ejecuta dentro de su infraestructura, en el mismo momento en que se calcula el carrito o se pinta el checkout. No es un servicio tuyo al que Shopify llama por HTTP: el binario vive en Shopify, recibe un input definido por una consulta GraphQL y devuelve una lista de operaciones. Se escribe en Rust o en JavaScript (que se compila a Wasm con Javy), se despliega como extensión de una app —normalmente una app personalizada de la propia tienda— y se gestiona con Shopify CLI, con su repositorio, sus tests y su historial de cambios.

La diferencia operativa con una app de terceros es esa: la lógica de negocio deja de ser una caja negra alojada en un servidor ajeno y pasa a ser código que puedes leer, versionar y auditar. Y como corre dentro de Shopify, no añade latencia de red al checkout.

Lo que se resuelve sin comprar nada

Estos son los encargos que más nos llegan y que se cubren con Functions propias:

• Descuentos por volumen y escalados: 3×2, tramos por cantidad, precios por unidad según el total del carrito, descuentos que solo aplican a una colección o a productos con determinado metacampo.
• Precios B2B por cliente: reglas que leen etiquetas de cliente, empresa o ubicación de la empresa y aplican el porcentaje pactado en el contrato.
• Bundles y kits con la Cart Transform API: agrupar varias líneas en un producto compuesto o expandir un kit en sus componentes, con su propio precio.
• Ocultar, renombrar y reordenar métodos de envío: nada de recogida en tienda si el carrito lleva un producto voluminoso, nada de urgente si el pedido sale de un almacén concreto.
• Personalización de pagos: quitar el contrareembolso por encima de un importe, ocultar pago aplazado a clientes de cierto segmento, subir arriba el método que mejor te convierte.
• Validaciones de carrito: mínimos de pedido, incompatibilidades entre productos, límites de unidades por cliente, bloqueos por país de envío.

En las versiones recientes de la API de descuentos, una sola función puede devolver descuentos de producto, de pedido y de envío, así que la mecánica completa de una campaña cabe en una única extensión en lugar de repartirse en tres.

Los límites que conviene conocer antes de firmar

Functions no es un entorno de propósito general y quien te diga lo contrario no las ha llevado a producción.

No hay red ni estado. Una Function no puede llamar a tu ERP, ni consultar una API externa, ni guardar nada entre ejecuciones. Todo lo que necesite saber tiene que llegarle en el input: campos del carrito, del cliente, de la entrega, y metacampos o metaobjetos que hayas declarado en la consulta. Si tu tabla de precios vive en un sistema externo, hay que sincronizarla a metaobjetos con un trabajo aparte. Ese trabajo de sincronización suele ser la mitad del proyecto y es lo que se olvida al presupuestar.

Hay presupuesto de ejecución. Shopify impone un límite de instrucciones y de memoria por invocación, documentado y medible con las herramientas del CLI. Para reglas normales sobra, pero se nota en carritos B2B de cientos de líneas combinados con lógica que recorre colecciones. Ahí importa cómo escribes la consulta de entrada: pedir menos campos es lo que más rebaja el consumo.

Hay topes de cuántas cosas pueden estar activas. Shopify limita el número de descuentos automáticos activos simultáneamente, y solo puede haber una personalización de pagos y una de envíos activas a la vez. Toda la lógica de pagos de la tienda tiene que convivir dentro de la misma función, lo que obliga a diseñar la arquitectura desde el principio en vez de ir añadiendo funciones sueltas. También hay que decidir la combinabilidad de cada descuento —producto, pedido, envío— porque de eso depende que las campañas se sumen o se pisen.

El plan importa. Los descuentos por Functions están disponibles en cualquier plan, pero las personalizaciones de pago y de envío y las extensiones de UI del checkout requieren Shopify Plus.

La cuenta que casi nadie hace

Cuando un cliente nos pide opinión sobre sustituir tres apps por Functions, la comparación no es «desarrollo contra suscripción», es esto:

• Suma las cuotas mensuales de las apps implicadas y multiplícalas por 36. Tres años es un horizonte razonable para una tienda estable.
• Añade lo que te cuesta cada revisión de checkout con soporte de terceros de por medio, y las horas que se van cada Black Friday probando que las apps no se pisan entre ellas.
• Enfrenta eso al desarrollo, que es un coste de una vez más un mantenimiento bajo pero real: Shopify versiona las APIs de Functions y toca actualizar cada cierto tiempo.

Con esa cuenta delante, la respuesta no siempre es desarrollar. Si tu regla es un 3×2 estándar sin variantes, hay apps buenas, baratas y bien mantenidas, y montar una extensión propia es tirar dinero. El desarrollo gana cuando la lógica es específica de tu negocio (tarifas B2B negociadas, reglas de envío por tipo de mercancía, incompatibilidades de catálogo), cuando ya pagas varias apps que se solapan, o cuando alguna te obliga a meter scripts en el checkout y eso se refleja en los tiempos de carga.

Cómo lo abordamos en Pango Studio

Empezamos por un inventario: qué apps tocan carrito y checkout, qué hace cada una de verdad y cuál de esas reglas sigue teniendo sentido comercial. En más de un proyecto, un tercio de la lógica heredada de Scripts era de campañas terminadas hacía años. Después escribimos la especificación de las reglas que sobreviven, con sus casos límite, y a partir de ahí las funciones, con tests sobre los inputs reales exportados de la tienda. El despliegue va por app personalizada, con la configuración en metaobjetos para que marketing pueda cambiar tramos y umbrales desde el admin sin volver a llamarnos.

La parte que se suele descuidar viene después: que el descuento se vea. Un tramo por volumen que solo aparece en el carrito convierte peor que uno anunciado en la ficha de producto, y ese es justamente el hueco que cubrimos con Discount Display. La Function calcula, la ficha lo comunica.

Si arrastras apps de descuentos desde la retirada de Scripts y no tienes claro qué está haciendo cada una con tu checkout, revisar ese inventario es un buen punto de partida. Escríbenos y lo miramos con tu tienda delante.