Fecha límite de Shopify Scripts: migra a Functions antes del 30 de junio de 2026

Hoy es 16 de abril de 2026. Ayer, 15 de abril, Shopify bloqueó Script Editor de forma definitiva. Ya no puedes crear ni publicar un Script nuevo. El plazo afecta especialmente a la lógica posterior a la compra: los cambios de dirección de envío son la edición más frecuente después de comprar y representan el 30,2 % de todos los pedidos editados (Revize, 2026). Cualquier Script que aún gestione esas ediciones ha quedado congelado. Dentro de 75 días, el 30 de junio de 2026, los Scripts dejarán de ejecutarse.

Si desarrollas para Shopify Plus —o gestionas una tienda Plus desde una agencia— y llevas doce meses aplazando esta migración para «el próximo sprint», tienes un problema. No es una mejora que pueda esperar: la pantalla de pago puede dejar de funcionar como esperas a partir de la medianoche del 1 de julio. Muchas tiendas Plus han acumulado entre 5 y 20 Scripts a lo largo de los años. Cada uno aplica discretamente una regla de descuento, oculta una opción de envío o restringe un método de pago que quizá nadie recuerda haber configurado.

Esta es la guía técnica de migración que nos habría gustado tener en enero. Incluye el código, además de la estrategia. Al terminar, sabrás cómo crear la estructura de una Function con Shopify CLI, escribir la lógica en Rust o JavaScript para descuentos y personalizaciones de envío y pago, probarla con un grupo de clientes identificados mediante una etiqueta y publicarla sin afectar a tu pantalla de pago actual.

Vamos a sustituir los Scripts de tu tienda por Functions.

Respuesta rápida: de Scripts a Functions en 60 segundos#

La migración en un párrafo: Shopify Scripts (código Ruby en Script Editor, exclusivo de Plus) se sustituye por Shopify Functions (módulos WebAssembly escritos en Rust o JavaScript y disponibles en todos los planes). Primero creas la estructura de una Function con shopify app generate extension. Después escribes una consulta run.graphql para obtener los datos del carrito que necesitas y un archivo run.rs o run.js que devuelve operaciones (descuentos, métodos de envío ocultos, etc.). Por último, la despliegas con shopify app deploy y la activas desde Shopify Admin o mediante una mutación GraphQL. Las Functions se ejecutan como WASM compilado con una latencia inferior a 5 ms, funcionan en todos los planes y son la única vía de personalización que Shopify admitirá en adelante.

Qué cambia exactamente el 30 de junio#

Antes de tocar el código, ten claras las fechas. Son dos y ambas importan.

La migración no admite términos medios. Si despliegas tu Function antes del 30 de junio, la pantalla de pago seguirá funcionando como esperas. Si no, cada carrito afectado volverá silenciosamente a los precios y tarifas de envío estándar, y se habilitarán todos los métodos de pago. El Script se ejecuta o no se ejecuta; después del 30 de junio, ya no se ejecutará.

Consejo: Abre Settings → Checkout → Customizations Report en Shopify Admin. El informe enumera todos los Scripts activos de tu tienda, qué hace cada uno y el tipo de Function recomendado para sustituirlo. Empieza por ahí.

Functions frente a Scripts: qué ha cambiado#

El cambio de arquitectura importa. Con Scripts, modificabas Ruby en un campo de texto. Con Functions, creas una aplicación, controlas sus versiones, la pruebas en local y la despliegas mediante un proceso de integración continua. La curva de aprendizaje es mayor. También debería ser la última migración de la lógica de la pantalla de pago que tengas que hacer en el futuro previsible: Shopify apuesta por Functions a largo plazo.

Cómo asociar cada Script con el tipo de Function adecuado#

Cada Script que tienes hoy corresponde a una API de Functions. Ten esta tabla a mano.

Si tienes diez Scripts, probablemente crearás entre tres y cinco Functions. A menudo, varios Scripts pueden reunirse en una sola Function con condiciones más claras.

Requisito previo: prepara tu entorno de desarrollo local#

Antes de crear la estructura de una Function, necesitas instalar tres herramientas en tu equipo. Ejecuta estas comprobaciones en la terminal.

1. Node.js 18+

node --version
# Must be >= 18.0.0

Si tienes una versión anterior, instálala mediante nvm o descárgala de nodejs.org.

2. Shopify CLI 3+

npm install -g @shopify/cli@latest
shopify version
# Should output 3.x or higher

3. Herramientas de Rust (solo si vas a escribir Functions en Rust)

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
rustup target add wasm32-wasip1
cargo --version

Las Functions en JavaScript no necesitan Rust. Elige un lenguaje para tu equipo y úsalo de forma consistente: mantener ambos añade trabajo.

4. Una tienda de desarrollo

Inicia sesión en tu panel de Partner y crea una tienda de desarrollo, o utiliza una que ya tengas. Desplegarás las Functions allí antes de llevarlas a producción.

Crea la estructura de tu primera Function#

Shopify CLI genera la mayor parte del código inicial. Desde cualquier directorio:

# Create a new Shopify app (skip if you already have one)
shopify app init my-checkout-functions
cd my-checkout-functions

# Generate a Function extension
shopify app generate extension

Shopify CLI te guiará por varias opciones. Para una Function de descuentos, elegirías:

• Tipo: Function
• Plantilla: discount (o cart_checkout_validation, delivery_customization, payment_customization, etc.)
• Lenguaje: Rust o JavaScript
• Nombre: algo como volume-discount-fn

Esto crea extensions/volume-discount-fn/ con esta estructura:

extensions/volume-discount-fn/
├── shopify.extension.toml      # Function config — targets, build, version
├── src/
│   ├── cart_lines_discounts_generate_run.graphql   # Input query
│   └── cart_lines_discounts_generate_run.rs        # Function logic
├── Cargo.toml                  # Rust dependencies (Rust only)
└── README.md

Los tres archivos que editarás con más frecuencia son .toml (configuración), .graphql (datos de entrada) y .rs / .js (lógica). Eso es todo.

Tutorial 1: sustituir un Line Item Script (descuento por volumen)#

Supongamos que tu Script anterior aplicaba un 10 % de descuento al subtotal del pedido cuando el carrito contenía 5 o más unidades de una colección concreta. Esta es la Function equivalente.

Paso 1.1: configuración (shopify.extension.toml)#

api_version = "2026-01"

[[extensions]]
name = "volume-discount-fn"
handle = "volume-discount-fn"
type = "function"

[[extensions.targeting]]
target = "cart.lines.discounts.generate.run"
input_query = "src/cart_lines_discounts_generate_run.graphql"
export = "cart_lines_discounts_generate_run"

[extensions.build]
command = "cargo build --target=wasm32-wasip1 --release"
path = "target/wasm32-wasip1/release/volume-discount-fn.wasm"
watch = ["src/**/*.rs"]

Paso 1.2: consulta de entrada (src/cart_lines_discounts_generate_run.graphql)#

query Input {
  cart {
    lines {
      id
      quantity
      cost {
        subtotalAmount {
          amount
        }
      }
      merchandise {
        ... on ProductVariant {
          product {
            inAnyCollection(ids: ["gid://shopify/Collection/123456789"])
          }
        }
      }
    }
  }
  discount {
    discountClasses
  }
}

Consejo: Las Functions solo reciben los datos que solicitas en la consulta. Mantén la consulta GraphQL lo más breve posible: cada campo que omitas permite una ejecución más rápida y con menos recursos.

Paso 1.3: lógica (src/cart_lines_discounts_generate_run.rs)#

use super::schema;
use shopify_function::prelude::*;
use shopify_function::Result;

#[shopify_function]
fn cart_lines_discounts_generate_run(
    input: schema::cart_lines_discounts_generate_run::Input,
) -> Result<schema::CartLinesDiscountsGenerateRunResult> {
    // Bail if discount class doesn't match
    let has_order_discount = input
        .discount()
        .discount_classes()
        .contains(&schema::DiscountClass::Order);

    if !has_order_discount {
        return Ok(schema::CartLinesDiscountsGenerateRunResult { operations: vec![] });
    }

    // Sum quantities of items in the target collection
    let qualifying_qty: i64 = input
        .cart()
        .lines()
        .iter()
        .filter(|line| {
            if let schema::Merchandise::ProductVariant(v) = line.merchandise() {
                *v.product().in_any_collection()
            } else {
                false
            }
        })
        .map(|line| *line.quantity())
        .sum();

    if qualifying_qty < 5 {
        return Ok(schema::CartLinesDiscountsGenerateRunResult { operations: vec![] });
    }

    // Apply 10% off the order subtotal
    Ok(schema::CartLinesDiscountsGenerateRunResult {
        operations: vec![schema::CartOperation::OrderDiscountsAdd(
            schema::OrderDiscountsAddOperation {
                selection_strategy: schema::OrderDiscountSelectionStrategy::First,
                candidates: vec![schema::OrderDiscountCandidate {
                    targets: vec![schema::OrderDiscountCandidateTarget::OrderSubtotal(
                        schema::OrderSubtotalTarget {
                            excluded_cart_line_ids: vec![],
                        },
                    )],
                    message: Some("Volume discount: 10% off".to_string()),
                    value: schema::OrderDiscountCandidateValue::Percentage(
                        schema::Percentage { value: Decimal(10.0) }
                    ),
                    conditions: None,
                    associated_discount_code: None,
                }],
            },
        )],
    })
}

Paso 1.4: probar, desplegar y activar#

# Local development with hot reload
shopify app dev

# When ready, deploy
shopify app deploy

# In the GraphiQL panel that opens (press `g` in the dev terminal),
# create the automatic discount that uses your Function:

mutation {
  discountAutomaticAppCreate(
    automaticAppDiscount: {
      title: "Volume Discount (5+ collection items)"
      functionHandle: "volume-discount-fn"
      discountClasses: [ORDER]
      startsAt: "2026-04-16T00:00:00Z"
    }
  ) {
    automaticAppDiscount { discountId }
    userErrors { field message }
  }
}

Ya está. La Function está activa, tiene control de versiones y sustituye por completo al Script anterior.

Tutorial 2: sustituir un Shipping Script (ocultar un método de envío según el subtotal)#

Un Script habitual dice: «Ocultar el envío exprés cuando el subtotal del carrito supera los $500 para evitar envíos urgentes costosos en pedidos grandes». Esta es la versión con una Delivery Customization Function.

Paso 2.1: crear la estructura#

shopify app generate extension --template delivery_customization --name hide-express-fn

Paso 2.2: consulta de entrada (src/run.graphql)#

query Input {
  cart {
    cost {
      subtotalAmount {
        amount
      }
    }
    deliveryGroups {
      deliveryOptions {
        handle
        title
      }
    }
  }
}

Paso 2.3: lógica (src/run.js, variante en JavaScript)#

// @ts-check
/**
 * @typedef {import("../generated/api").RunInput} RunInput
 * @typedef {import("../generated/api").FunctionRunResult} FunctionRunResult
 */

const NO_CHANGES = { operations: [] };
const THRESHOLD = 500.0;
const HIDE_TITLES = ["Express", "Overnight"];

/**
 * @param {RunInput} input
 * @returns {FunctionRunResult}
 */
export function run(input) {
  const subtotal = parseFloat(input.cart.cost.subtotalAmount.amount);
  if (subtotal < THRESHOLD) return NO_CHANGES;

  const operations = input.cart.deliveryGroups.flatMap((group) =>
    group.deliveryOptions
      .filter((opt) => HIDE_TITLES.some((t) => opt.title.includes(t)))
      .map((opt) => ({
        hide: { deliveryOptionHandle: opt.handle },
      }))
  );

  return { operations };
}

Paso 2.4: activar desde Shopify Admin (sin GraphQL)#

Las Delivery Customizations tienen una interfaz integrada en Shopify Admin. Después de ejecutar shopify app deploy:

1. Ve a Settings → Shipping and delivery
2. Desplázate hasta la sección Customizations, al final
3. Haz clic en Add customization y selecciona tu Function
4. Guarda los cambios

La regla que oculta el método de envío ya está activa en producción. No necesitas ninguna mutación.

Tutorial 3: sustituir un Payment Script (ocultar el pago contra entrega para B2B)#

Script anterior: «Ocultar el pago contra entrega a cualquier cliente con la etiqueta “B2B”». Esta es la versión con Payment Customization.

Paso 3.1: crear la estructura#

shopify app generate extension --template payment_customization --name hide-cod-b2b-fn

Paso 3.2: consulta de entrada#

query Input {
  cart {
    buyerIdentity {
      customer {
        hasTags(tags: [{ tag: "B2B" }]) {
          tag
          hasTag
        }
      }
    }
  }
  paymentMethods {
    id
    name
  }
}

Paso 3.3: lógica (src/run.js)#

const NO_CHANGES = { operations: [] };

export function run(input) {
  const tagCheck = input.cart?.buyerIdentity?.customer?.hasTags?.[0];
  const isB2B = tagCheck?.hasTag === true;
  if (!isB2B) return NO_CHANGES;

  const codMethod = input.paymentMethods.find((pm) =>
    pm.name.toLowerCase().includes("cash on delivery")
  );
  if (!codMethod) return NO_CHANGES;

  return {
    operations: [{ hide: { paymentMethodId: codMethod.id } }],
  };
}

Paso 3.4: activar#

Las Payment Customizations también tienen una interfaz en Shopify Admin, en Settings → Payments → Customizations. Sigue el mismo proceso que para el envío: selecciona tu Function y guarda los cambios.

Ya que estás aquí: unas palabras sobre lo que ocurre después de la compra#

Una aclaración breve, porque este es el blog de Revize. Revize gestiona lo que Functions no puede modificar: una vez realizado el pedido, los clientes pueden querer añadir un artículo, cambiar una talla, corregir la dirección de envío o aplicar un descuento que olvidaron usar. Functions actúa en la pantalla de pago. Revize actúa después. Functions determina qué se permite en el carrito; Revize permite a los clientes y al equipo de atención editar el pedido después, sin tener que reembolsarlo y crearlo de nuevo. Esto importa a dos tipos de tiendas: las que reciben tantos pedidos que la edición manual deja de ser viable (operadores Plus, por supuesto, pero también tiendas Advanced con un gran volumen de pedidos) y las que basan su marca en la experiencia del cliente, donde un correo que dice «lo sentimos, no podemos cambiarlo» puede costarles una nueva compra.

Si tu plan de migración cubre el paso de Scripts a Functions, pero aún no has resuelto las ediciones de pedidos después de la compra, probablemente te encontrarás con el siguiente «¿por qué es tan difícil?» en unas tres semanas. La guía de gestión de pedidos que acabamos de publicar explica todo el proceso posterior a la pantalla de pago.

Volvamos a la migración.

Estrategia de pruebas: usar una etiqueta de cliente#

Las Functions no tienen un «modo borrador» que puedas activar en Shopify Admin. Una forma de probarlas es limitar la nueva Function a clientes con una etiqueta, ejecutar en paralelo el Script anterior y la Function nueva, comprobar que ofrecen el mismo resultado a esos clientes y, después, activarla para todos.

Paso 1: etiqueta a los usuarios de prueba#

En Customers, añade la etiqueta FN-TESTER a dos o tres cuentas internas.

Paso 2: condiciona la Function a la presencia de la etiqueta#

// At the top of your run function
let is_tester = input
    .cart()
    .buyer_identity()
    .and_then(|bi| bi.customer())
    .map(|c| c.has_any_tag())
    .unwrap_or(&false);

if !*is_tester {
    return Ok(default_result);  // Fall through to existing Script
}

// New Function logic only runs for tagged users

Paso 3: añade hasAnyTag a la consulta de entrada#

cart {
  buyerIdentity {
    customer {
      hasAnyTag(tags: ["FN-TESTER"])
    }
  }
}

Paso 4: comprueba el resultado en la pantalla de pago#

Inicia sesión como usuario con la etiqueta, avanza por la pantalla de pago y confirma que se ejecuta la Function. Después, inicia sesión como usuario sin la etiqueta y confirma que sigue ejecutándose el Script anterior. Cuando los resultados coincidan durante varios días, elimina la comprobación de la etiqueta y permite que la Function se ejecute para todos.

Paso 5: deja de publicar el Script anterior#

Ve a Apps → Script Editor → [Your Script] → Unpublish. Una vez que dejes de publicarlo, la Function será la única fuente de esa lógica.

Un proceso de despliegue que puede crecer contigo#

No despliegues siempre desde el portátil de un desarrollador. Cuando hayas migrado uno o dos Scripts, configura un proceso de integración continua.

El proceso mínimo viable#

# .github/workflows/deploy-functions.yml
name: Deploy Shopify Functions
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - uses: dtolnay/rust-toolchain@stable
        with: { targets: wasm32-wasip1 }
      - run: npm install -g @shopify/cli@latest
      - run: shopify app deploy --force
        env:
          SHOPIFY_CLI_PARTNERS_TOKEN: ${{ secrets.SHOPIFY_CLI_PARTNERS_TOKEN }}

Genera el token de Partner en Settings → Tokens de tu panel de Partner. A partir de entonces, cada cambio incorporado a main desplegará tus Functions. Se acabaron los hilos de Slack para averiguar si alguien ya hizo el despliegue.

Versiones y reversión#

shopify app deploy crea una instantánea con versión. Para volver a una versión anterior:

shopify app versions list
shopify app release --version <previous-version-id>

Con Scripts, revertir un cambio significaba recordar el código anterior y volver a pegarlo. Aquí el proceso es mucho más sencillo.

Errores frecuentes de los equipos#

Tras ayudar a comerciantes Plus con esta migración durante el último año, hemos visto repetirse estos cinco errores.

1. Trasladar cada Script a una Function por separado. No es necesario. Una sola Function puede sustituir tres Scripts con condiciones más claras. Revisa todos tus Scripts en conjunto antes de reescribirlos.

2. Olvidar los permisos de lectura. Muchas Functions necesitan read_customers, read_orders o write_discounts. Añádelos en shopify.app.toml, dentro de scopes, y vuelve a autorizar la aplicación. De lo contrario, la consulta de entrada devolverá un valor nulo.

3. Ejecutar Functions para clientes sin etiqueta antes de comparar resultados. Aunque el código parezca correcto, pueden surgir problemas en casos especiales: carritos vacíos, tarjetas de regalo, crédito en tienda o borradores B2B. Una activación limitada por etiqueta te cuesta dos días y puede evitar una incidencia crítica.

4. Omitir el Customizations Report. Es el mejor inventario de lo que realmente está en funcionamiento. Basa la migración en el informe, no en lo que recuerdes.

5. Incluir identificadores de colecciones y etiquetas de clientes directamente en el código. Si el comerciante necesita cambiar esos valores, usa una configuración de la Function mediante metacampos. Shopify CLI puede generar una estructura de configuración respaldada por metacampos; consulta la documentación de Shopify sobre la configuración de Functions.

Lista de tareas para los próximos 75 días#

Este es un plan semanal realista para llegar al 30 de junio con margen.

Si empiezas esta semana, tienes margen. Si empiezas en junio, no.

Qué hacer esta semana#

No cierres esta pestaña sin actuar. Haz estas cuatro cosas en los próximos siete días.

1. Descarga el Customizations Report. Ve a Settings → Checkout → Customizations Report y expórtalo. Será tu lista de tareas para la migración.

2. Prepara tu entorno de desarrollo. Instala Node 18+, Shopify CLI y Rust si corresponde. Confirma que shopify version funciona. Tiempo total: 30 minutos.

3. Crea y despliega una Function pequeña en una tienda de desarrollo. Elige tu Script más sencillo, normalmente una regla para ocultar un método de pago, y migra todo el proceso. Aunque nunca llegue a producción, habrás comprobado que las herramientas funcionan.

4. Reserva tiempo en el calendario para las próximas ocho semanas. Las migraciones no se completan en los ratos libres entre sprints. Reserva un horario recurrente —por ejemplo, cada martes y jueves por la tarde— y trátalo como un lanzamiento.

Entre los equipos cuya migración hemos visto, se repite el mismo patrón: dos semanas de aplazamientos, tres de trabajo y una de ajustes finales. Son seis semanas. Tú tienes diez. Aprovecha el margen para revisar el código y hacer controles de calidad, no para retrasar el inicio.

Y cuando hayas resuelto la lógica de la pantalla de pago, lo siguiente que suelen abordar los equipos son los cambios posteriores a la compra: direcciones de clientes, sustituciones de productos y descuentos añadidos después de realizar el pedido. Si eso está en tus planes —y debería estarlo tanto si gestionas una tienda Plus con un gran volumen de pedidos como una tienda Advanced centrada en la experiencia del cliente—, Revize está disponible en Shopify App Store y funciona junto con todas las Functions que crees aquí.

Recursos#

• Introducción a Shopify Functions — documentación para desarrolladores de Shopify
• Migrar de Shopify Scripts a Functions
• Tutorial para crear una Discount Function
• Referencia de la API de Delivery Customization Function
• Referencia de la API de Payment Customization Function
• Documentación de Shopify CLI

Actualizado en agosto de 2026. Revize es una aplicación de Shopify que permite a los clientes editar sus propios pedidos después de la compra: pueden cambiar la dirección de envío, sustituir una variante o un producto, cancelar el pedido y recibir un reembolso o crédito en tienda antes de la preparación de pedidos (fulfillment), sin abrir una solicitud al equipo de atención. Descubre cómo permitir que tus clientes editen sus propios pedidos de Shopify o encuentra Revize en Shopify App Store.