Suscripciones y pagos recurrentes en ecommerce: cómo montarlas en WooCommerce y Shopify

El ecommerce de compra única tiene un problema estructural: cada mes empieza de cero. Captas tráfico, pagas el CAC, conviertes… y vuelta a empezar. Por eso cada vez más tiendas online —desde el café en grano hasta el software con hardware asociado— están moviendo parte de su catálogo a un modelo de suscripción con pagos recurrentes: ingresos predecibles, mejor LTV y una relación continua con el cliente en lugar de una transacción aislada.

La teoría es atractiva; la implementación técnica, bastante menos trivial de lo que aparenta. Cobrar a alguien cada mes sin que esté delante implica tokenizar tarjetas, cumplir la normativa europea de autenticación reforzada (SCA/PSD2), distinguir cobros iniciados por el cliente de cobros iniciados por el comercio, gestionar reintentos cuando una tarjeta falla o caduca, y sincronizar todo esto con tu logística y tu ERP. Y cada plataforma lo resuelve de una forma distinta: WooCommerce te da control total a cambio de que asumas la complejidad, y Shopify te la gestiona a cambio de sus reglas y sus comisiones.

En esta guía analizamos, desde el punto de vista de un equipo de desarrollo, cómo montar suscripciones y pagos recurrentes en WooCommerce y en Shopify: qué piezas necesitas, qué pasarelas funcionan bien en España, dónde están las trampas (WP-Cron, dunning, churn involuntario) y qué métricas debes vigilar desde el primer día. Si estás valorando si tu plataforma actual aguanta un modelo recurrente, o cuál elegir para lanzarlo, aquí tienes el mapa completo.

1. El modelo de suscripción en ecommerce: por qué ahora

Las suscripciones no son nuevas, pero su adopción en ecommerce se ha acelerado por tres motivos muy concretos. Primero, el coste de adquisición: con el CPC de Google y Meta subiendo año tras año, amortizar el CAC en una sola compra es cada vez más difícil; una suscripción reparte ese coste entre muchos pedidos. Segundo, la madurez tecnológica: lo que en 2018 exigía desarrollo a medida hoy está soportado de forma nativa o casi nativa por las principales plataformas. Tercero, el cambio de hábitos: el consumidor ya está educado por Netflix, Spotify o HelloFresh y no percibe fricción en «suscribirse» a un producto físico.

1.1 Los tres modelos que funcionan

En la práctica, casi todas las suscripciones de ecommerce encajan en uno de estos patrones:

Replenishment (reposición): productos consumibles que se agotan a ritmo predecible — café, cuchillas de afeitar, comida de mascotas, suplementos, consumibles de impresora. Es el modelo con mejor retención porque resuelve una necesidad real: no quedarse sin producto. La frecuencia la marca el consumo, y permitir ajustarla (cada 2, 4, 6 semanas) es clave para reducir cancelaciones.

Curation (caja sorpresa): el cliente paga por una selección periódica — cajas de vino, libros, cosmética. Margen alto y buen storytelling, pero retención más frágil: cuando la novedad cae, el churn sube. Exige un motor de contenido/producto potente detrás.

Membership (membresía): el cliente paga una cuota por ventajas — envío gratis, precios especiales, acceso anticipado. Es el modelo Amazon Prime o Costco aplicado a tu tienda. Técnicamente es el más sencillo (no hay pedido recurrente físico, solo un cargo y un rol de cliente), y combina muy bien con los otros dos.

Antes de elegir herramienta conviene tener clarísimo cuál de estos modelos vas a operar, porque no todas las soluciones soportan bien los tres. Y si todavía estás decidiendo la base tecnológica de tu tienda, nuestra guía para elegir plataforma ecommerce es el paso previo a este artículo.

2. La parte difícil: cobrar cada mes sin el cliente delante

El corazón técnico de cualquier sistema de suscripciones no está en el catálogo ni en el área de cliente: está en el cobro recurrente. Y aquí hay cuatro conceptos que cualquier CTO debería dominar antes de firmar con una pasarela o instalar un plugin.

2.1 Tokenización: nunca guardes tarjetas

Tu plataforma jamás debe almacenar números de tarjeta. En el primer pago, la pasarela (Stripe, Redsys, Adyen…) guarda la tarjeta en su bóveda y te devuelve un token — una referencia que solo sirve para cobrar a través de esa pasarela. Con tokens, tu alcance PCI-DSS se reduce al cuestionario SAQ-A o SAQ-A-EP en lugar de una auditoría completa. Los network tokens (tokens emitidos por Visa/Mastercard en lugar de la pasarela) van un paso más allá: sobreviven a la caducidad y reemisión de la tarjeta física, lo que reduce de forma medible el churn involuntario.

2.2 SCA, PSD2 y la diferencia entre CIT y MIT

La normativa europea PSD2 exige autenticación reforzada (SCA, normalmente 3D Secure 2) en los pagos electrónicos. Pero un cobro mensual automático no puede pedirle al cliente que valide con su banco cada vez. La solución está en distinguir dos tipos de transacción: la CIT (Customer Initiated Transaction), el primer pago con el cliente presente, donde sí se aplica SCA y se establece el mandato; y las MIT (Merchant Initiated Transactions), los cobros posteriores iniciados por el comercio, que quedan exentos de SCA siempre que se marquen correctamente y referencien la transacción inicial. Si tu integración no etiqueta bien las MIT, los bancos emisores empezarán a rechazar cobros de forma aparentemente aleatoria — uno de los errores más comunes que nos encontramos en auditorías de tiendas con recurrencia.

2.3 Dunning: la gestión del fallo de cobro

Entre un 5% y un 15% de los cobros recurrentes fallan: saldo insuficiente, tarjeta caducada, bloqueos del emisor. El proceso de recuperación se llama dunning y combina reintentos programados (idealmente smart retries que eligen el mejor momento según datos del emisor), emails de aviso al cliente, actualización automática de tarjetas (card account updater) y una política clara de suspensión. La diferencia entre un dunning bien montado y no tener ninguno puede ser recuperar el 60-70% de los cobros fallidos frente a perderlos todos. En un negocio de suscripción, el dunning no es un detalle: es una línea de la cuenta de resultados.

2.4 Churn involuntario

Se estima que entre el 20% y el 40% de las cancelaciones en suscripciones no son decisiones del cliente, sino fallos de pago no recuperados. Es el churn involuntario, y es la fruta más baja de todo el modelo: network tokens, account updater y smart retries atacan directamente esta bolsa. Antes de invertir en retención «de marketing», asegúrate de que no estás perdiendo clientes que querían quedarse.

Flujo de un pago recurrente en ecommerce por suscripción: checkout CIT con SCA, tokenización, cobro MIT programado y dunning
Las cuatro fases del cobro recurrente: del checkout con autenticación al dunning cuando un cargo falla.

3. Suscripciones en WooCommerce: control total, responsabilidad total

WooCommerce sigue siendo la opción preferida cuando el modelo de negocio no encaja en un molde estándar, como analizamos en WooCommerce en 2026: cuándo sigue siendo la mejor opción. En suscripciones esto se cumple con más razón todavía: puedes construir exactamente el modelo que necesitas, pero cada pieza es responsabilidad tuya.

3.1 Woo Subscriptions y sus alternativas

Woo Subscriptions (la extensión oficial) es el estándar de facto: productos de suscripción simples y variables, cuotas de alta, periodos de prueba, prorrateos, cambios de plan (upgrade/downgrade), pausas y renovaciones manuales o automáticas. Se integra con la mayoría de pasarelas serias y tiene un ecosistema enorme de extensiones alrededor. Sus alternativas — YITH WooCommerce Subscription, SUMO Subscriptions o soluciones ligeras sobre Stripe Billing — pueden tener sentido en catálogos sencillos, pero en cuanto aparecen variaciones, envíos sincronizados o cambios de plan, la extensión oficial amortiza su licencia. Nuestra recomendación general: no ahorres en la pieza que ejecuta tus cobros.

3.2 Pasarelas: Stripe sí, Redsys con matices

No todas las pasarelas soportan igual de bien los cobros recurrentes. Stripe es la referencia: tokenización sólida, manejo correcto de CIT/MIT, smart retries, account updater y soporte de network tokens. Redsys —inevitable si quieres TPV bancario español— soporta pagos por referencia (COF/MIT), pero la calidad de la implementación depende críticamente del plugin que uses y de cómo marque las operaciones; hemos visto tiendas con tasas de rechazo del 20% en renovaciones por una integración COF deficiente. PayPal es útil como método adicional (billing agreements), pero como pasarela única para suscripciones se queda corta. La elección de pasarela condiciona además tu checkout y su conversión: en suscripciones, cada punto de fricción en el primer pago se multiplica por todo el LTV que pierdes.

3.3 La trampa del WP-Cron

Woo Subscriptions programa las renovaciones con Action Scheduler, que por defecto depende de WP-Cron — y WP-Cron solo se ejecuta cuando alguien visita la web. En una tienda con poco tráfico nocturno, las renovaciones de las 3:00 pueden dispararse a las 9:17, en ráfaga, compitiendo con el tráfico de la mañana. La solución es obligatoria, no opcional: desactivar WP-Cron (DISABLE_WP_CRON) y ejecutar wp cron event run --due-now desde cron real del sistema cada minuto, monitorizando la cola de Action Scheduler (tamaño, acciones fallidas, tiempo de ejecución). En tiendas con miles de suscripciones, las renovaciones son un proceso batch de verdad: hay que dimensionar PHP workers y base de datos para ese pico, igual que harías para una campaña.

3.4 Arquitectura y mantenimiento

Un WooCommerce con suscripciones es un sistema financiero, no un blog con carrito. Eso implica: entorno de staging donde probar cada actualización de la extensión y de la pasarela (un bug en renovaciones cobra mal a cientos de clientes antes de que nadie lo vea), logs de cada intento de cobro, alertas cuando la tasa de fallos se desvía, y backups coherentes de base de datos — el estado de una suscripción vive en la BD y un restore parcial puede duplicar o saltarse cobros. Es exactamente el tipo de operación donde un mantenimiento ecommerce profesional se paga solo.

4. Suscripciones en Shopify: la vía gestionada

Shopify aborda el problema desde la filosofía opuesta: la plataforma ejecuta los cobros y tú configuras el modelo. Desde la Subscription API y las selling plans, las suscripciones son un ciudadano de primera clase del checkout nativo — ya no hace falta (ni se permite) sacar al cliente a un checkout externo.

4.1 Selling plans y apps

El modelo de datos de Shopify separa el producto de su plan de venta: un mismo producto puede comprarse una vez o suscribirse con descuento y frecuencia elegida. Sobre esa base trabajan las apps especializadas: Recharge (el veterano, muy completo, con coste mensual + transaccional), Loop (fuerte en retención y flujos de cancelación), Appstle (agresivo en precio, buen soporte) o Seal. La app aporta el portal de cliente (pausar, saltar entrega, cambiar frecuencia, cambiar tarjeta), los flujos de dunning configurables y las analíticas de MRR y churn. La elección importa menos que en WooCommerce porque todas se apoyan en la misma infraestructura de cobro de Shopify — compara precio, portal de cliente y capacidad de migración de suscriptores existentes.

4.2 Lo que Shopify te quita de encima (y lo que te impone)

Con Shopify Payments, la tokenización, el cumplimiento PCI, el manejo CIT/MIT y buena parte de los reintentos vienen resueltos de serie. El coste de esa comodidad: comisión por transacción (que se suma a la de la app de suscripciones), personalización del checkout limitada a lo que permita Checkout Extensibility, y tus datos de suscriptores viviendo en la app de turno — pregunta siempre cómo se exportan los tokens de pago si algún día migras. Para catálogos D2C estándar, el trade-off suele compensar; para modelos B2B con facturación compleja, precios negociados o cargos por consumo, el corsé aprieta — ahí conviene revisar lo que ya permite Shopify B2B antes de descartar nada.

¿Vas a montar suscripciones en tu tienda o ya las tienes y fallan cobros?

En Keliam implementamos y mantenemos modelos de pago recurrente en WooCommerce y otras plataformas: integración de pasarelas con CIT/MIT correcto, dunning, colas de renovación y monitorización de cobros.

Habla con nuestro equipo →

5. WooCommerce vs Shopify para suscripciones: cómo decidir

La comparativa general entre plataformas ya la hicimos en Shopify vs WooCommerce vs PrestaShop; aplicada específicamente a suscripciones, los criterios se afilan.

5.1 Elige WooCommerce si…

Tu modelo se sale del estándar: precios por cliente, bundles dinámicos, sincronización de entregas compleja, B2B con facturación a fin de mes, o necesitas que la lógica de suscripción dialogue con un ERP o un sistema propio. También si el control del dato es innegociable: en WooCommerce los suscriptores, los tokens (referencias en tu pasarela) y todo el historial son tuyos, en tu base de datos, exportables sin pedir permiso. El coste real no está en las licencias sino en la operación: cron fiable, staging, actualizaciones vigiladas y alguien que mire los logs de cobro.

5.2 Elige Shopify si…

Quieres lanzar rápido un modelo D2C estándar (replenishment o curation con frecuencias fijas) y prefieres pagar comisión a cambio de no operar infraestructura de cobros. El time-to-market es semanas en lugar de meses, el dunning viene configurado con buenos defaults y el portal de cliente es sólido desde el día uno. Asume a cambio la doble comisión (Shopify + app), menor flexibilidad en checkout y la dependencia del ecosistema de apps para cualquier caso particular.

5.3 El error a evitar en ambos casos

Tratar la suscripción como «un producto más». Es un flujo de negocio transversal que toca checkout, pagos, logística, atención al cliente y contabilidad. Los proyectos que fallan no lo hacen por elegir mal la plataforma, sino por no dimensionar la operación: nadie configuró el dunning, nadie sincronizó los pedidos recurrentes con el almacén, nadie definió qué pasa cuando un producto suscrito se descataloga.

Comparativa de suscripciones y pagos recurrentes en ecommerce: WooCommerce frente a Shopify
Dos filosofías: control y propiedad del dato en WooCommerce, operación gestionada en Shopify.

6. Operativa: logística, ERP y atención al cliente

Cuando el cobro funciona, el trabajo se traslada a la operación. Tres frentes concentran casi todos los problemas.

6.1 Pedidos recurrentes y almacén

Cada renovación genera un pedido que tu logística debe tratar con normalidad… con matices: los pedidos de suscripción llegan en lotes (todas las renovaciones del día 1), son predecibles (puedes preparar stock con antelación — esa es precisamente una de sus ventajas) y son más sensibles a errores: fallar el envío a un cliente nuevo cuesta una venta; fallárselo a un suscriptor puede costar todo su LTV. Funciones como skip (saltar una entrega) o cambio de dirección deben propagarse al instante hacia el almacén.

6.2 Integración con ERP y facturación

La recurrencia multiplica el volumen de documentos: cada cobro exige factura, y los cambios de plan generan prorrateos y abonos. Integrar la plataforma con el ERP deja de ser opcional en cuanto superas unas decenas de suscriptores; los patrones (API, colas de eventos, middleware) son los mismos que describimos en Integraciones API en ecommerce: ERP, logística y pasarelas de pago, con una exigencia extra de idempotencia: un webhook de renovación duplicado no puede generar dos facturas ni dos envíos.

6.3 El portal del cliente como herramienta de retención

Contraintuitivo pero cierto: cuanto más fácil es pausar o saltar una entrega, menor es el churn. El cliente que no encuentra el botón de pausa no se queda — cancela desde el banco (con el chargeback correspondiente) o cancela definitivamente. Un buen portal ofrece pausar, saltar, cambiar frecuencia, cambiar producto y actualizar tarjeta sin tocar soporte. Cada una de esas acciones es una cancelación evitada.

7. Las métricas que importan desde el día uno

Un negocio de suscripciones se gobierna con métricas distintas a las del ecommerce transaccional. Las cinco imprescindibles: MRR (ingreso recurrente mensual, la línea base de todo), churn rate separado en voluntario e involuntario (se combaten con herramientas diferentes: propuesta de valor el primero, dunning el segundo), LTV por cohorte (cuánto vale de verdad un suscriptor captado en cada campaña, que es lo que justifica tu CAC), tasa de recuperación de cobros fallidos (el KPI de tu dunning: por debajo del 50% hay dinero encima de la mesa) y engagement de portal (los suscriptores que usan skip y cambio de frecuencia cancelan menos que los inactivos). Móntalas antes del lanzamiento: reconstruir cohortes a posteriori desde los datos de la pasarela es un trabajo arqueológico que nadie disfruta.

Conclusión

Las suscripciones son la vía más sólida para que un ecommerce deje de comprar cada venta a los ads y construya ingresos predecibles. Pero el modelo se gana o se pierde en la fontanería: tokenización correcta, CIT/MIT bien marcados, dunning trabajado, colas de renovación fiables y una operación logística que trate al suscriptor como lo que es — tu mejor cliente. WooCommerce te da la libertad de construirlo exactamente a tu medida si asumes la operación; Shopify te alquila una maquinaria excelente si tu modelo cabe en ella. La decisión correcta depende menos de la plataforma que de tu modelo de negocio, tu equipo técnico y tu horizonte: elige con esa foto completa, y monta la medición y el dunning desde el primer cobro, no después del primer susto.

Preguntas frecuentes

¿Puedo cobrar suscripciones con Redsys y Bizum?

Con Redsys sí, mediante pagos por referencia (COF/MIT), aunque la fiabilidad depende mucho del plugin y de cómo marque las operaciones; exige pruebas exhaustivas de renovación antes de lanzar. Bizum no soporta cobros recurrentes automáticos a día de hoy: sirve para el alta o pagos puntuales, no como método principal de una suscripción.

¿Qué pasa con las suscripciones si migro de plataforma?

El dato crítico son los tokens de pago, que viven en la pasarela o en Shopify Payments. Si mantienes la misma pasarela (por ejemplo Stripe en ambos lados), los tokens son portables y la migración es viable sin pedir la tarjeta de nuevo. Si cambias de pasarela, prepara una campaña de re-autorización y asume una pérdida de suscriptores en el proceso.

¿Necesito cumplir PCI-DSS para vender suscripciones?

Siempre que cobres con tarjeta te aplica PCI-DSS, pero con tokenización y campos de pago embebidos de la pasarela tu alcance se reduce al cuestionario SAQ-A o SAQ-A-EP. Lo que nunca debes hacer es almacenar o hacer pasar números de tarjeta por tu servidor: además de riesgo, multiplica tu alcance de cumplimiento.

¿Cuántos suscriptores necesito para que compense?

Más que un número de suscriptores, mira el margen de contribución recurrente frente al coste fijo de operarlo (licencias o apps, mantenimiento, dunning, soporte). Con producto de reposición y ticket medio razonable, el modelo suele sostenerse a partir de unos pocos cientos de suscriptores activos; por debajo, trátalo como una apuesta de medio plazo financiada por la venta transaccional.

Scroll al inicio