Por qué fallan los cobros recurrentes con Redsys (y cómo evitarlo)

Redsys, la pasarela de pago que muchas empresas españolas desconocen‍

Mientras que Stripe es la opción más conocida internacionalmente, Redsys es la infraestructura de pagos detrás de la mayoría de los bancos españoles — BBVA, CaixaBank, Santander, Sabadell — y ofrece ventajas muy reales para negocios con clientes nacionales:

• Comisiones significativamente más bajas que las pasarelas internacionales
• Mayor tasa de aceptación para tarjetas españolas
• Cumplimiento nativo con la normativa europea PSD2
• Relación directa con tu banco, sin intermediarios

Para muchas pymes españolas, Redsys no es solo una opción viable: es la más inteligente económicamente. El problema es que automatizar cobros recurrentes con Redsys no es tan sencillo como parece.

‍

‍El problema: tener un TPV no es suficiente

‍Cuando un banco te activa un TPV virtual, lo configura por defecto para procesar pagos puntuales: el cliente introduce su tarjeta, confirma el pago, y listo. Esto funciona perfectamente para compras únicas.

Pero los cobros recurrentes (una suscripción mensual, una cuota trimestral..) son completamente diferentes. Aquí entra en juego la normativa PSD2.

Según PSD2, cualquier cargo a una tarjeta requiere que el titular la autorice activamente mediante autenticación reforzada (SCA: Strong Customer Authentication). Esto es lo que hace que tu banco te pida un código SMS o confirmación en la app cada vez que pagas algo online.

¿Cómo funciona esto en suscripciones? El usuario autoriza el primer cobro con autenticación completa, y en ese momento da su consentimiento explícito para los cobros futuros. Los siguientes ya no requieren su intervención activa (el comercio puede iniciarlos directamente. Esto es lo que se denomina una MIT: Merchant Initiated Transaction (transacción iniciada por el comercio). El problema es que para que tu TPV de Redsys pueda ejecutar MITs, el banco debe activarlo explícitamente. Y por defecto, no lo hace.

‍

‍Qué pasa cuando el MIT no está activado

‍Sin MIT activado, cada cobro recurrente que intentas procesar llega al banco emisor de tu cliente como una transacción nueva no autenticada. El banco la rechaza porque no ha habido SCA. El cargo falla.

Técnicamente, Redsys requiere que en las llamadas a la API se incluyan parámetros específicos como DS_MERCHANT_COF_TYPE y DS_MERCHANT_COF_INI  para indicar que se trata de una transacción recurrente bajo un mandato ya autorizado.

Sin ellos, el sistema no distingue el cobro recurrente de un intento de cargo no autorizado.La solución pasa por contactar con tu banco y solicitar expresamente la activación del MIT en tu TPV virtual. Es un proceso que muchos gestores bancarios tampoco conocen bien, lo que añade una capa más de fricción.

‍

‍Y si además necesitas adaptar los cobros a tu modelo de negocio...

‍Supongamos que ya tienes el MIT activado: ¡enhorabuena! Has superado el primer obstáculo. Pero ahora viene el segundo.La mayoría de los modelos de negocio no son tan simples como "cobrar X euros el día 1 de cada mes". En la realidad, muchas empresas necesitan:

• Cobrar una matrícula o setup fee diferente en el primer mes
• Variar el importe mensual según el uso o el número de usuarios
• Gestionar pausas, upgrades o cancelaciones de suscripción
• Reintentar automáticamente cobros fallidos sin perder al cliente

Implementar toda esta lógica internamente requiere un desarrollo técnico considerable: gestión del ciclo de vida de suscripciones, webhooks de estado, reconciliación de pagos, lógica de reintentos... Una infraestructura que la mayoría de pymes no puede permitirse construir y mantener.

‍