Un día las tarifas funcionan y al siguiente no. Los productos no cambiaron, la dirección es válida y la app sigue mostrando Active en verde. Lo único que alguien recuerda es que la app se actualizó unos días antes. Si así está tu tienda, la causa puede ser el cambio de plataforma.
El 26 de junio de 2026, Shopify publicó un cambio incompatible para Admin GraphQL API 2026-10: un servicio de transporte creado mediante la API ya no se añade automáticamente al perfil de envío General. Ahora queda registrado, pero no hay nada que indique al checkout que lo use hasta que se vincula explícitamente.
Qué cambió en la versión 2026-10 de la API
Antes de 2026-10, crear un servicio activo mediante carrierServiceCreate, o su equivalente REST, hacía dos cosas: registraba el servicio y lo añadía a las zonas elegibles del perfil General. El segundo paso era invisible, por eso muchas tiendas nunca supieron que ocurría. Shopify explica que crear el servicio ahora solo lo registra y ya no lo añade por defecto al perfil General ni a sus zonas. Sin el paso adicional, los comerciantes no ven sus tarifas en el checkout.
Dos detalles determinan si este es tu problema.
- Afecta a servicios recién creados, no a los existentes. El cambio no desvincula un servicio ya asociado a un perfil. Las tarifas desaparecen cuando una app crea un servicio nuevo, durante una reinstalación o reconstrucción, con la versión 2026-10.
- Depende de la versión. Shopify indica que las versiones anteriores compatibles mantienen la vinculación automática hasta su retirada. Tu tienda lo nota cuando la app pasa a 2026-10 o posterior. Por eso parece ocurrir «tras actualizar una app» y no como una caída general de la plataforma en una fecha única.
Por qué coincide con una actualización de la app
Las apps actualizan la versión de Admin API que utilizan; Shopify lo exige con el tiempo al retirar versiones antiguas. Cuando una app que gestiona un servicio de transporte pasa a 2026-10, los servicios que cree desde entonces ya no se vinculan automáticamente. Si no añadió el paso de vinculación porque durante años no lo necesitó, la actualización es el desencadenante. La app puede estar cumpliendo el nuevo contrato de la API y aun así dejar la tarifa sin colocar.
Sucede lo mismo cuando se vuelve a crear el servicio en vez de actualizarlo. Una reinstalación, una nueva autorización o una reconstrucción puede sustituir el registro antiguo por otro. El nuevo no está vinculado y el antiguo, que sí lo estaba, ha desaparecido. Para el comerciante es un servicio que dejó de funcionar; para la API es otro registro.
Hay otra causa independiente con el mismo síntoma: el plan de la tienda. Los servicios de transporte requieren Advanced o superior, el plan Shopify con facturación anual o el complemento de servicios de transporte, o una tienda de desarrollo. Shopify indica que un cambio de plan que deje de cumplir esos requisitos desactiva la vinculación de la tienda con el servicio.
La comprobación de cinco minutos para distinguir los casos
Antes de reconstruir nada, identifica cuál de estos estados tienes. Cada uno tiene una solución distinta.
Tabla comparativa — desplázate horizontalmente para ver todas las columnas
| Qué encuentras | Qué significa | Dónde corregirlo |
|---|---|---|
| Falta la tarifa calculada en la zona de Settings > Shipping and delivery | Se omitió el paso de vinculación de 2026-10 | Añade de nuevo la tarifa al perfil, desde el administrador o la API |
| La tarifa está en el perfil, pero falla el callback de la app | Shopify recurre al respaldo porque el endpoint da error o agota el tiempo | Corrige el callback y vuelve a probar |
| El servicio ya no aparece en la app | Se eliminó o sustituyó | Créalo de nuevo y vincúlalo |
| El plan de la tienda cambió hace poco | El plan desactivó la vinculación | Cambia de plan o añade la función y vuelve a vincular |
| Todo parece correcto, pero algunas zonas no tienen tarifas | La tarifa se vinculó al perfil o zona equivocados | Muévela al perfil que cubre esos productos |
Cómo resolverlo
Primera vía: añadir la tarifa desde el administrador. Es la primera opción que recomienda Shopify. En Settings > Shipping and delivery, abre el perfil que cubre los productos afectados, entra en la zona correspondiente y añade una tarifa calculada por transportista o app, seleccionando el servicio. Los perfiles y las zonas determinan a qué productos se aplica una regla. Elegir bien el perfil importa tanto como la tarifa.
Segunda vía: vincularla por código. Para algo más que un perfil, usa las API de perfiles de envío: añade desde la app la tarifa al perfil y la zona adecuados. Shopify indica esta segunda opción en el registro de cambios. Si tu app escribe en perfiles gestionados por el comerciante, revisa también el anuncio de febrero de 2026 sobre opciones de envío: exige trasladar esas escrituras a la nueva API para evitar comportamientos inesperados.
Verifícalo en un checkout real. Introduce una dirección de una zona afectada, llega al checkout y confirma que aparece la opción con el nombre y precio esperados. Que una tarifa exista en el administrador solo demuestra que aparece en el checkout después de esta prueba.
Configura tarifas de respaldo antes de tocar nada. Si la tarifa calculada falla, por una respuesta 40x/50x, un tiempo de espera agotado o un array vacío, Shopify solo muestra tarifas de respaldo si existen y no hay otra tarifa elegible. Una tarifa fija de respaldo evita que la ausencia de una tarifa de transporte bloquee el checkout.
Qué debe hacer el callback en el código
Un servicio de transporte es un endpoint POST público al que Shopify llama durante el checkout con el origen, destino y artículos. Debe devolver un array JSON de tarifas en una sola respuesta. El precio se expresa en unidades menores: "total_price": "500" equivale a 5,00 en la divisa de la tienda. Un array vacío con estado 20x indica que no hay tarifa para ese carrito; un 404 indica que Shopify debe usar tarifas de respaldo. No hay reintento: la primera respuesta debe funcionar dentro de un tiempo que se reduce con el volumen, de 10 segundos por debajo de 1.500 solicitudes por minuto a 3 segundos por encima de 3.000. Las solicitudes idénticas se guardan en caché durante 15 minutos.
La llamada de creación mantiene su estructura; el paso de vinculación pasó a ser independiente:
mutation CreateCarrierService($input: DeliveryCarrierServiceCreateInput!) {
carrierServiceCreate(input: $input) {
carrierService { id name callbackUrl active }
userErrors { field message }
}
}{
"input": {
"name": "Regional delivery",
"callbackUrl": "https://rates.example.com/rates",
"supportsServiceDiscovery": true,
"active": true
}
}En 2026-10, esto devuelve y registra el servicio, pero no lo coloca en un perfil. La vinculación es una escritura separada: la actualización del perfil expone el servicio como proveedor de tarifas, un DeliveryParticipant con el identificador carrierService, dentro de una definición de método de la zona correspondiente. También puede añadirlo el comerciante manualmente.
Cómo lo verifico en implementaciones reales
He construido una app de este tipo. Para un comercio de equipamiento de clubes y colegios, los ajustes nativos no podían expresar la regla: un pedido de una sola colección de club o colegio se recoge allí gratuitamente; un carrito mixto paga una entrega según la zona. Construí un endpoint de tarifas que se consulta en el checkout, identifica las colecciones de cada artículo y aplica la regla. Incluía un motor de reglas con prioridades sobre colecciones, totales de carrito, etiquetas de cliente y país de destino, perfiles de precios por país, un editor de reglas sin código y sincronización de productos y colecciones.
La app evolucionó hacia una versión de producto. Reforcé especialmente el callback, crítico para el checkout: un token de 192 bits por tienda en vez de una cabecera de tienda falsificable, límites de solicitudes y un diseño con respuesta segura ante fallos para que una regla incorrecta no rompa el checkout. Esa línea de producto tiene unas 320 pruebas. El despliegue solo consta en el cliente original y no hay publicación en la App Store; lo digo en vez de insinuar una escala que no existe.
De ese trabajo mantengo una regla: un endpoint de tarifas debe responder de forma segura ante fallos. Cuando deja de hacerlo, la tienda puede dejar de cobrar. Por eso, ante «desaparecieron las tarifas», hay que demostrar cuál de los cinco estados anteriores se aplica y corregir ese.
«Hizo la app perfecta para nosotros y da gusto trabajar con él».
— Cliente de Upwork, 2026; traducción del testimonio original
Fallos habituales
- Dar por hecho que la app está rota. En 2026-10 puede funcionar y dejar las tarifas sin vincular. Corrige la vinculación.
- Añadir la tarifa sin buscar una existente. Crea dos opciones en la misma zona. Elimina la definición obsoleta del método en vez de acumular otra.
- Cambiar de plan primero. El cambio puede desactivar la vinculación. Confirma el requisito del plan antes de dedicar un día a la app.
- Probar solo en el administrador. Ahí ves lo que existe; en el checkout ves lo que Shopify ofrecerá realmente. Prueba en el checkout.
- Omitir tarifas de respaldo. Un callback que falla sin alternativa puede impedir completar la compra.
Limitaciones
- Es un cambio de comportamiento de la API, no una pérdida de datos. No se reprocesa el historial. La opción deja de ofrecerse para servicios nuevos sin vincular.
- La fecha depende de la versión usada por cada app. Las versiones anteriores compatibles conservan el comportamiento hasta su retirada. Dos tiendas con la misma versión de app pueden ver resultados distintos.
- La vinculación por código depende del perfil. Los perfiles gestionados por el comerciante y los gestionados por la app se escriben de forma distinta. Los primeros pueden requerir la nueva API de opciones de envío.
- La elegibilidad del plan puede imponerse a todo lo anterior. Vincular no sirve si la tienda ya no cumple los requisitos del servicio.
- Esto cubre implementación técnica, no asesoramiento legal ni fiscal.
Cuándo no necesitas esto
Si tu tienda solo usa tarifas fijas o por peso y ningún servicio de transporte, este cambio no te afecta. Si falta una tarifa pero la app la muestra vinculada en todas las zonas, revisa el callback o las tarifas de respaldo. Si solo tienes una zona y una tarifa en una tienda que puedes editar, la vía del administrador lleva minutos; pagar a alguien por ello sería la opción equivocada y te lo diré.
Puedo implementarlo para ti
Este es el caso de uso Los ajustes nativos no pueden expresar tus reglas: tarifas de envío personalizadas en el checkout.
Empieza con una conversación gratuita: describe tu tarea y confirmaré si falta el paso de vinculación de 2026-10, falla el callback o cambió el plan, antes de modificar nada.
Volver a vincular una tarifa ausente entre los perfiles de una tienda es una corrección acotada desde EUR 425. Construir o reforzar la lógica de reglas, por colección, carrito y destino, con un callback seguro y vinculación por código, es un proyecto de ingeniería a medida desde EUR 1.400. Si aún no está claro cuál es tu caso, una sesión de trabajo por EUR 185 determina la causa de una cuestión antes de cambiar nada.
Describe tu tarea.
