Pagos recurrentes con Redsys en Andorra: guía completa

Para cobrar pagos recurrentes con Redsys desde una empresa de Andorra necesitas un TPV preparado para esa operativa, una autorización inicial del comprador y una integración que relacione cada cobro con su suscripción. Además, debes definir el calendario, el periodo de servicio y qué ocurre ante un fallo, un cambio o una baja.

En AndorPay conectamos esas partes sobre las capacidades habilitadas en tu TPV. Redsys participa en el procesamiento del pago; nosotros gestionamos el recorrido documentado de cobro y sus estados; tu aplicación utiliza la información para prestar el servicio. Esta guía explica el ciclo completo y las decisiones que conviene resolver antes de empezar.

Los requisitos, de un vistazo

Antes de preparar una suscripción con Redsys, comprueba estas cuatro piezas:

1. TPV habilitado: confirma con tu banco las operaciones recurrentes y la tokenización disponibles para tu comercio.
2. Alta autorizada: define qué acepta el comprador y cómo se obtiene la referencia para los cargos posteriores.
3. Calendario y estado: relaciona cada cobro con su suscripción y actualiza el servicio cuando llegue la confirmación.
4. Continuidad: prepara qué ocurre ante un fallo, una baja o un cambio antes de abrir las altas.

La documentación oficial de tokenización MIT desarrolla la operativa técnica. En los apartados siguientes explicamos cómo encajan esas piezas con tu negocio y qué revisamos para preparar la integración con AndorPay.

Qué significa cobrar de forma recurrente

Un pago recurrente es un cobro que se repite de acuerdo con una relación y unas condiciones aceptadas. En una suscripción, esos cobros suelen corresponder a periodos sucesivos de servicio. La frecuencia de cobro, la duración del acceso y la fecha de renovación deben ser comprensibles para el cliente.

No es lo mismo que enviar cada mes un enlace y esperar una nueva compra manual. Tampoco es necesariamente una venta fraccionada: esta divide una compra en pagos con un final previsto. Define primero qué relación estás ofreciendo para que el sistema siga las reglas correctas.

El resultado que buscas debe poder expresarse así: «Este cliente tiene este servicio durante este periodo; este pago lo confirma y esta es su próxima acción prevista». Esa relación evita que el negocio dependa de revisar una lista de movimientos sin contexto.

Pago único o recurrente: qué estás contratando

En una suscripción, cancelar las renovaciones futuras y devolver un cobro anterior son gestiones distintas. Explica ambas condiciones antes del alta y evita presentar un pago recurrente como una compra única.

Qué corresponde al banco, a Redsys, a AndorPay y a tu aplicación

El mismo proyecto puede coordinar varias partes, pero conviene reconocer sus funciones. Una activación bancaria no conecta por sí sola el acceso a un curso. Una aplicación con una tabla de socios tampoco habilita la recurrencia del terminal.

La diferencia entre pasarela y gestión de suscripciones amplía este reparto. Aquí nos centramos en cómo trabaja ese conjunto cuando la infraestructura de pago utiliza Redsys.

Redsys sí dispone de operativa recurrente

La documentación oficial de Redsys incluye tokenización, operaciones posteriores y gestión de clientes y pagos programados. Por tanto, la pregunta es qué recorrido está habilitado para tu comercio y cómo se conecta con el servicio que vendes.

Si ya utilizas una programación en el portal bancario o en otra plataforma, identifícala antes de añadir una nueva. Dos sistemas intentando renovar la misma relación pueden producir acciones contradictorias. Cada suscripción debe tener un responsable claro de solicitar sus cobros.

En nuestro recorrido, AndorPay coordina los cobros posteriores mediante la conexión preparada para la cuenta. No hay que duplicar esa programación en otro panel salvo que exista un diseño específico que lo requiera y mantenga las operaciones separadas.

Tokenización, primer pago y MIT, explicados sin rodeos

Una referencia para los cobros posteriores

La tokenización permite utilizar una referencia del método de pago en lugar de gestionar directamente los datos completos de tarjeta en la aplicación del negocio. Esa referencia se obtiene dentro del recorrido autorizado y se utiliza conforme a la configuración del proveedor.

El equipo necesita relacionar el método con el cliente y la suscripción adecuados. El identificador de tu socio o usuario no es el token bancario; son referencias con funciones diferentes. Mantener esa separación ayuda a cambiar datos comerciales sin confundirlos con la credencial de pago.

El comprador participa en el alta

En la operación inicial, el comprador interviene y acepta las condiciones correspondientes. Puede tener que autenticarse con su banco. En la terminología de Redsys, una operación iniciada por el cliente se denomina CIT.

El alta prepara la relación recurrente. Tener un primer pago correcto no demuestra, por sí solo, que el terminal permita los cargos posteriores. Esa capacidad debe estar habilitada y formar parte de la integración.

Las renovaciones las inicia el comercio

MIT significa operación iniciada por el comercio. Es el tipo de recorrido utilizado para cobros posteriores dentro de la relación autorizada, sin pedir al cliente que repita toda la compra cada periodo.

La documentación de tokenización de Redsys y su guía MIT explican estas distinciones. Una MIT puede no confirmarse y requerir atención. Cobro automático no significa cobro garantizado.

Qué confirmar con el banco antes de integrar

Explica que necesitas suscripciones con una primera operación del comprador y renovaciones posteriores. Indica la empresa, el servicio y la frecuencia prevista. Pedir simplemente «un TPV online» puede dejar sin concretar la operativa que necesitas.

Confirma el comercio y terminal, la tokenización o pago por referencia y la recurrencia. Para nuestro recorrido de tarjeta, revisamos también inSite y los entornos de prueba y producción. La guía de preparación de producción detalla los requisitos técnicos.

Las capacidades dependen de la configuración habilitada para ese terminal. AndorPay utiliza lo que está disponible; la integración no sustituye la activación bancaria. Si el terminal actual tiene una limitación, la identificamos antes de preparar la puesta en marcha.

Revisa además dónde consultar operaciones y liquidaciones. Una renovación confirmada necesita una referencia que permita seguirla hasta la revisión administrativa. El momento en que el banco liquida los fondos tiene sus condiciones propias.

Define la suscripción antes de definir sus cargos

Escribe qué compra el cliente en cada periodo, cuándo comienza y cuándo se renueva. Una oferta mensual debe explicar si el periodo depende del alta o de un calendario acordado. La configuración concreta se revisa para que lo comunicado y lo ejecutado coincidan.

Define también qué ocurre cuando el cliente cambia de modalidad o solicita la baja. No hace falta diseñar todos los planes futuros. Sí necesitas una regla clara para la oferta que vas a vender ahora.

Si hay una prueba inicial, un descuento o una fecha especial de inicio, comprueba cómo se representa en el producto y su configuración. No resuelvas la diferencia modificando informalmente el importe de un cobro sin conservar la relación con la suscripción.

La guía de servicios digitales por suscripción desarrolla la oferta y la entrega. Aquí esas decisiones sirven para preparar el calendario que el sistema debe mantener.

Cómo funciona el alta inicial

El recorrido comienza identificando al comprador y el producto recurrente. La integración crea la sesión correspondiente y presenta el pago. El cliente reconoce la oferta y completa los pasos que se le solicitan, incluida la autenticación cuando sea necesaria.

Al recibirse el resultado, se relacionan los recursos del recorrido. En nuestra documentación, un producto recurrente puede generar una suscripción, un pago y una factura durante la conciliación. Cada uno describe una parte distinta de la venta.

Tu aplicación debe conservar su referencia de cliente y la relación con la suscripción. Así puede activar el servicio para la persona correcta y recuperar la operación si el navegador se cierra antes de volver.

Antes de dar el alta por terminada, comprueba el resultado económico, el periodo y la entrega prevista. Si la oferta incluye un comienzo diferido o una prueba, aplica esa regla específica; no confundas cualquier suscripción creada con dinero cobrado.

Qué ocurre en una renovación

Cuando corresponde renovar, el componente responsable identifica la suscripción y el periodo que debe cobrar. En el recorrido documentado de AndorPay, los cobros posteriores se inician como MIT sobre un TPV con tokenización y recurrencia habilitadas.

La operación obtiene su propio resultado. Una primera compra correcta no convierte todos los meses siguientes en pagos confirmados. El método puede necesitar una actualización, la operación puede ser rechazada o el resultado puede seguir pendiente.

Cuando el pago se confirma, la gestión de la suscripción y tu aplicación actualizan lo que corresponda a ese periodo. El cliente no necesita visitar el checkout para que el negocio conozca el resultado del cargo posterior.

Conserva la relación entre suscripción, periodo y operación. Si una persona pregunta por dos movimientos o por su próxima renovación, podrás revisar registros concretos. No tendrás que deducir el periodo únicamente por la fecha de llegada de un mensaje.

Calendario y periodo de servicio son datos distintos

La fecha prevista de cobro, el momento del intento y el periodo que se vende deben poder distinguirse. Un retraso técnico no debería modificar por accidente la oferta que el cliente contrató.

Por ejemplo, imagina una renovación correspondiente al siguiente mes de servicio cuyo resultado llega más tarde. El equipo necesita saber qué periodo está resolviendo antes de extender el acceso o reclamar otro pago. La fecha del aviso no explica por sí sola esa relación.

Mantén un único responsable del calendario y registra los cambios con su fecha de efecto. Si cambias el plan, revisa qué ocurre con las acciones ya previstas. Evita que un panel muestre una fecha mientras otra herramienta conserva una programación distinta.

Para comunicar la renovación al cliente, utiliza datos consistentes con la configuración real. Si el negocio trabaja con un día y una zona horaria determinados, el equipo técnico debe comprobar que las fechas mostradas y procesadas siguen esa convención.

Confirmar el pago y actualizar el servicio

En AndorPay, payment.succeeded comunica un pago confirmado. Los eventos de suscripción describen cambios de estado o periodo. Los de factura se refieren al documento asociado. La documentación del ciclo de pago explica cómo distinguirlos.

Tu aplicación verifica la notificación y aplica el efecto correspondiente. Una confirmación visual del navegador sirve a la experiencia del comprador, pero no sustituye esa comprobación. Las renovaciones, además, pueden completarse sin una visita del cliente.

El mismo evento puede recibirse más de una vez. La integración debe reconocerlo y evitar otra entrega, otra ampliación de acceso o un segundo registro del mismo resultado. Reprocesar una confirmación existente no equivale a solicitar un nuevo cargo.

También debe poder recuperar un estado si la aplicación estuvo temporalmente indisponible. La información del pago permanece relacionada con la operación; la recuperación consiste en aplicar el resultado correcto a la compra correspondiente.

Un ejemplo completo: acceso mensual a un servicio

Imagina una biblioteca profesional con una modalidad mensual. Una persona crea su cuenta, acepta la oferta y completa el alta. El sistema relaciona su usuario, la suscripción, el periodo inicial y el resultado del pago. La aplicación permite el acceso según esas condiciones.

Al llegar la renovación, AndorPay solicita el cobro dentro del recorrido configurado. Si se confirma, el nuevo periodo queda identificado y la aplicación mantiene el acceso. Si la notificación se repite, conserva ese periodo sin ampliarlo de nuevo.

Supongamos ahora que el pago se confirma, pero la aplicación no actualiza el acceso. La incidencia se resuelve revisando la recepción y aplicación del resultado sobre ese mismo pago. Cobrar otra vez no arreglaría la falta de acceso.

Si, en cambio, la operación es rechazada, el equipo revisa el motivo disponible y la acción necesaria. La política comercial define qué puede seguir utilizando el cliente mientras lo resuelve. Si pide la baja, esta se registra con su efecto previsto y se revisan las acciones pendientes.

Este ejemplo muestra el objetivo del conjunto: que el dinero, el periodo y el servicio cuenten la misma historia. El sistema de pago aporta el resultado económico y la aplicación lo conecta con lo que el cliente ha comprado.

Fallo, espera o falta de ejecución: tres problemas diferentes

Un rechazo confirmado significa que ese intento terminó sin cobro. Un resultado pendiente exige conocer el estado de la operación existente. Una renovación no iniciada requiere revisar el calendario y la ejecución. No conviene agrupar los tres casos bajo «tarjeta que no funciona».

El mensaje al cliente debe reflejar lo que sabes. No atribuyas un rechazo a falta de fondos si la respuesta no lo confirma. No anuncies una cancelación cuando todavía estás comprobando un resultado pendiente.

La guía de renovaciones fallidas desarrolla la recuperación. El principio es identificar el caso antes de actuar y mantener un siguiente paso comprensible para el comprador.

Reintentos y actualización del método de pago

La repetición de un intento necesita una regla y un responsable. No programes varios mecanismos independientes que actúen sobre la misma renovación. Tampoco adoptes un calendario genérico sin comprobar que corresponde al producto y a la integración utilizados.

Algunas incidencias requieren que intervenga el comprador. Nuestra API documenta una acción alojada para actualizar el método de pago de una suscripción, sujeta a las capacidades necesarias. La actualización tiene su propio resultado y debe relacionarse con el cliente correcto.

Completar ese cambio no significa que cualquier deuda anterior esté automáticamente resuelta. Comprueba qué ocurrió con la renovación afectada y cuál es el siguiente paso previsto. Cuando se confirme el pago, cierra los avisos que hayan dejado de tener sentido.

Tu equipo necesita saber dónde termina el seguimiento automático y quién recibe los casos pendientes. La recuperación funciona mejor cuando el estado indica qué se ha intentado y qué falta por hacer.

Bajas y cambios de plan sin perder la relación con el periodo

Una baja afecta a la continuidad de la suscripción. Concreta cuándo tiene efecto, qué acceso permanece y qué operaciones ya estaban en curso. La decisión del cliente debe quedar vinculada a la suscripción adecuada, con una respuesta que pueda entender.

Un cambio de plan también necesita una fecha de efecto y un resultado comprobable. Nuestra API documenta operaciones de cambio y cancelación de cambios programados. El comportamiento debe ajustarse al contrato del endpoint y a la configuración de la oferta.

No deduzcas una actualización completada solo porque se aceptó la solicitud. Revisa el estado y el cambio asociado antes de mostrar al cliente nuevas condiciones como vigentes. La referencia de API recoge las operaciones disponibles.

Una baja no es automáticamente una devolución. Si esta resulta necesaria, se gestiona como una operación distinta. Los reembolsos Redsys no están habilitados en nuestra API actual; el procedimiento aplicable debe acordarse antes de ofrecer una acción automática al cliente.

Facturas, cobros y liquidación bancaria

Relaciona cada documento con el cliente, el pedido o la suscripción correspondiente. Un documento creado y un pago confirmado describen hechos distintos. Si el cobro falla, esa diferencia ayuda a entender qué queda pendiente.

La liquidación en la cuenta bancaria también se consulta según las condiciones contratadas con la entidad. No utilices el estado de acceso como sustituto del seguimiento económico ni una lista de movimientos como único registro del servicio.

La conexión documental debe encajar con tu gestión administrativa. Si utilizas otra herramienta de facturación o contabilidad, define qué datos necesita y quién mantiene la correspondencia. Tener una API de facturas no completa por sí solo cualquier configuración fiscal o conexión externa.

Si ya cobras suscripciones y vas a cambiar la conexión

Una migración afecta a las altas nuevas y a las relaciones existentes de forma diferente. Para una nueva alta puedes preparar el nuevo recorrido; para una suscripción activa debes revisar el periodo, el calendario y la referencia de pago disponible.

No presupongas que los tokens se trasladan libremente entre proveedores, comercios o terminales. La portabilidad depende de las condiciones de la referencia y de la operación admitida. Puede ser necesaria una acción del comprador, que debe planificarse sin confundirla con una compra duplicada.

Prepara un inventario de suscripciones activas, próximas renovaciones y pagos pendientes. Decide qué sistema será responsable de cada una durante el cambio. Evita mantener dos calendarios activos para el mismo periodo.

Conserva el historial necesario para atender consultas sobre operaciones anteriores. Cambiar de conexión no elimina la necesidad de localizar un pago antiguo o explicar una baja. La transición se completa cuando cada relación tiene un responsable y el cliente sabe qué debe hacer, si se requiere alguna acción.

Puesta en marcha: qué debe quedar preparado

El entorno de pruebas permite verificar el alta, la renovación y los estados relevantes sin tratarlo como una venta real. La validación productiva es una comprobación separada. La guía de pruebas de integración explica cómo registrar escenarios y resultados.

Para el responsable técnico, la documentación útil es el ciclo del pago, la referencia de API, los webhooks y la preparación de producción. Para el negocio, basta con una descripción de la oferta, la plataforma y cómo se gestiona hoy el servicio. No necesitas traducir tu operativa a parámetros bancarios antes de hablar con nosotros.

Qué revisar cuando el ciclo ya está funcionando

Comprueba cuántas renovaciones estaban previstas, cuáles se iniciaron y cuáles tienen un resultado confirmado. Revisa aparte los casos que necesitan intervención y los pagos cuyo acceso no se ha actualizado. Así podrás localizar el paso que requiere atención.

Conserva el contexto del periodo al revisar esas cifras. Comparar intentos con suscripciones sin distinguir reintentos puede producir una lectura equivocada. Una misma renovación puede generar más de un evento sin representar varios clientes nuevos.

Revisa también las preguntas de soporte. Si los clientes no entienden la fecha de renovación o cómo actualizar su método, puede faltar claridad en el recorrido. Resolver ese mensaje forma parte de gestionar bien el cobro recurrente.

Antes de activar ventas, utiliza la matriz de pruebas de pagos recurrentes: alta, renovación MIT, rechazo o espera, notificación duplicada y baja efectiva. Guarda el resultado de cada caso junto con la suscripción y el periodo; aprobar el primer cobro no sustituye estas comprobaciones.

Preguntas frecuentes

¿Sirve cualquier TPV Redsys para cobrar suscripciones?

Debe tener habilitada la operativa necesaria para el recorrido. Revisamos terminal, tokenización, recurrencia y configuración con el banco. Un pago puntual correcto no confirma por sí solo esa capacidad.

¿Tengo que guardar números de tarjeta en mi aplicación?

Nuestro recorrido utiliza la conexión preparada y referencias de pago. Tu aplicación conserva las relaciones comerciales necesarias; no debe copiar datos completos de tarjeta para gestionar las renovaciones.

¿La primera compra valida todas las renovaciones?

No. Hay que comprobar un ciclo posterior, sus resultados y su efecto en el periodo. La renovación utiliza una operativa y un momento distintos del alta inicial.

¿Puedo mantener mi banco actual?

Primero revisamos la configuración disponible. La guía para añadir suscripciones a tu TPV ayuda a preparar ese punto de partida sin asumir que hace falta cambiar toda la infraestructura.

Prepara tu ciclo recurrente con AndorPay

Cuéntanos qué servicio vendes, qué plataforma utilizas y cómo quieres organizar los periodos. Revisaremos el TPV, el alta, las renovaciones y la conexión con el acceso para preparar una propuesta con un alcance concreto.

Consulta nuestro TPV online para empresas de Andorra o solicita una propuesta para tus suscripciones. Partimos de tu operativa para conectar cada cobro con el servicio que debe mantener.