Instalar un módulo en tu tienda parece gratis: descargas un fichero, lo subes y ya tienes los envíos conectados. El coste no está en instalarlo. Está en los tres años siguientes, cada vez que actualizas la tienda y tienes que comprobar si el módulo sigue vivo.
Lo que vas a encontrar
Casi todas las tiendas online en España corren sobre un gestor de contenidos: WooCommerce sobre WordPress, PrestaShop, y unas cuantas más. Y casi todos los servicios que conectas (pasarela de pago, facturación, envíos) llegan en forma de módulo: un paquete de código que se instala dentro de tu tienda y pasa a formar parte de ella.
Funciona. Hasta que actualizas.
Porque un módulo no es una pieza suelta que convive con tu tienda: es tu tienda. Corre con su mismo PHP, en su misma versión, con sus mismas dependencias. Cuando algo de eso se mueve, el módulo tiene que moverse con ello. Y si no se mueve, se rompe algo: a veces el propio módulo, a veces la pantalla en la que estaba.
Este es el caro, y se ve mejor con un ejemplo real y público.
PrestaShop 1.7 entró en mantenimiento de solo seguridad en cuanto salió PrestaShop 8. El anuncio del propio proyecto, en enero de 2023, no deja lugar a interpretación: a partir de ahí, los parches de 1.7.8 solo se publicarían si se reportaban fallos críticos o si hacían falta correcciones de seguridad. Y añadía cuándo terminaba eso:
«Este periodo de mantenimiento terminará cuando se publique PrestaShop 9.0.0. Cuando llegue ese día, PrestaShop 1.7 dejará de mantenerse.»
Ese día llegó. PrestaShop va hoy por la 9.1 estable, con la 9.2 en beta. Así que 1.7 ya no se mantiene, y quien siga ahí lo hace sin red.
Ahora crúzalo con tus módulos. Cada uno se publicó para una versión concreta. Si tu tienda va por 1.7 y tu proveedor de envíos solo publica módulo para 8, no puedes actualizar sin quedarte sin envíos. Si actualizas primero y el módulo no está listo, tampoco. Te has quedado atrapada entre dos calendarios que no controlas: el de tu gestor de contenidos y el de cada proveedor que tengas instalado.
Y multiplícalo. No tienes un módulo: tienes el de envíos, el de la pasarela, el de facturación, el del chat. Para actualizar la tienda los necesitas alineados a todos a la vez.
Lo de PrestaShop no es un caso raro. En el mundo de WordPress pasa lo mismo, y encima el margen se ha reducido a propósito.
WooCommerce seguía una política llamada L-2: daba soporte a la última versión de WordPress y a las dos anteriores. En junio de 2023, con WooCommerce 7.8, la cambió a L-1: la última y una anterior, con el objetivo declarado de reducir el riesgo de fallos y empujar a las tiendas a mantenerse al día.
Es una decisión razonable desde el lado del software. Desde el lado de la tienda significa otra cosa: la ventana en la que tu montaje es oficialmente compatible se acortó a la mitad. Y WordPress publica varias versiones mayores al año, así que esa ventana se mide en meses, no en años.
Súmalo a lo anterior y tienes el cuadro completo: tu gestor de contenidos avanza en su calendario, tu proveedor de envíos publica módulo en el suyo, y tú estás en medio con la obligación de que ambos coincidan. Nadie te avisa el día que dejan de hacerlo.
Conviene decir que el módulo no fue una mala idea. Fue la única idea durante años.
Cuando tu tienda vive en tu propio servidor y no expone una forma estándar de que otros sistemas hablen con ella, la manera de conectar algo es meterlo dentro. El módulo era eso: la única puerta que había. Y a cambio daba algo real (control total, funcionamiento sin depender de que un tercero esté disponible) que sigue teniendo valor en algunos casos.
Lo que ha cambiado no es que el módulo fuera malo. Es que ha dejado de ser la única puerta.
Las plataformas de tienda llevan años abriendo formas de conectarse desde fuera, sin que haya que instalar nada dentro. La conexión se autoriza una vez, los pedidos salen hacia el servicio y los estados vuelven, y el código vive en el servicio, no en tu tienda.
La diferencia práctica, para quien lleva una tienda:
| Módulo instalado | Conexión desde fuera | |
|---|---|---|
| Dónde vive el código | Dentro de tu tienda | En el servicio |
| Al actualizar la tienda | Hay que comprobar compatibilidad | No te afecta |
| Si el proveedor mejora algo | Descargas y actualizas tú | Lo tienes sin hacer nada |
| Si falla | Puede tumbar una página tuya | Se cae la conexión, no tu tienda |
| Versiones | Necesitas la de tu versión exacta | No aplica |
No es magia ni es gratis: a cambio dependes de que el servicio esté disponible, y de lo que la plataforma de tu tienda permita hacer desde fuera. Pero el reparto de riesgos cambia por completo, y sobre todo desaparece el problema de las versiones, que es el que te dejaba atrapada.
Sirven para envíos y para todo lo demás. Se hacen antes de contratar, no después:
eComm funciona desde el navegador, sin instalar nada en tu tienda. Es la respuesta a la primera pregunta de la lista de arriba, y es también la razón por la que las tres de en medio dejan de aplicar: no hay versión que casar, no hay código nuestro en tu checkout y no hay nada que desinstalar.
Lo que sí tienes que valorar es lo otro: que la conexión dependa de un servicio externo, y que lo que se pueda automatizar sea lo que tu plataforma permita hacer desde fuera. Eso es un intercambio, no una ventaja gratuita, y conviene entenderlo antes de decidir.
Si quieres ver cómo queda esto dentro de una operación con varias redes, está en la guía de trabajar con varios transportistas.
Lo de PrestaShop sale del anuncio oficial del proyecto (5 de enero de 2023) y de su página de versiones, consultada el 3 de septiembre de 2026. El cambio de política de WooCommerce, del blog de desarrollo de WooCommerce. Los costes de rendimiento, checkout y desinstalación son elaboración propia a partir del funcionamiento conocido de los módulos en un gestor de contenidos: no son datos de mercado y por eso no llevan cifras.
eComm conecta tu tienda con las redes de transporte desde el navegador, sin instalar nada en ella. 15 días de prueba con acceso completo, sin tarjeta.