Puedes añadir suscripciones a un TPV existente cuando el banco, la operativa de pago y la aplicación están preparados para trabajar juntos. El punto de partida es aprovechar lo que ya tienes: tu relación bancaria, tu terminal virtual y tu tienda o servicio. Después conectamos el primer pago, las renovaciones y el acceso del cliente para que cada periodo tenga un resultado identificable.
En AndorPay abordamos esa puesta en marcha desde el recorrido completo. Cobrar una tarjeta es una parte; saber a quién corresponde el pago, qué periodo cubre y qué hacer si falla permite gestionar una suscripción. Esta guía te ayuda a preparar esa conexión sin rehacer tu negocio por una limitación del sistema de cobro.
Primero, identifica qué TPV tienes realmente
La palabra TPV puede referirse al datáfono del local, al terminal virtual contratado con el banco o al programa de gestión que utilizas para vender. Para cobrar suscripciones online necesitamos identificar la operativa de comercio electrónico. Tener un dispositivo que acepta tarjetas en el mostrador no demuestra que exista un terminal preparado para renovaciones a distancia.
Reúne el nombre del banco, la plataforma donde vendes y la documentación disponible del terminal virtual. Añade quién mantiene actualmente la integración: tu equipo, una agencia o el proveedor del programa. Esa información permite localizar el punto de conexión sin empezar por una lista de herramientas que quizá no necesitas.
Si ya cobras compras puntuales en una web, describe cómo se realiza una venta: dónde elige el producto el comprador, dónde introduce la tarjeta y dónde aparece el pedido pagado. Guarda referencias de pruebas y configuración, sin enviar credenciales por formularios comerciales. El objetivo inicial es entender la instalación; los accesos se gestionan después por el canal adecuado.
Qué puedes conservar y qué requiere trabajo
Una instalación existente puede aportar la relación con el banco, el catálogo, las cuentas de usuario y el sistema que entrega el servicio. La suscripción introduce nuevas responsabilidades: mantener una referencia válida de pago, calcular el próximo periodo y coordinar los cambios de estado.
Por ejemplo, una plataforma de formación que ya vende un curso puede conservar sus contenidos y usuarios. Al ofrecer acceso mensual, necesita decidir cuándo empieza el mes, cómo se amplía el acceso y qué ocurre cuando termina. Esas decisiones pertenecen al producto y a la integración, aunque el cobro continúe utilizando el TPV bancario.
Comprueba la operativa necesaria con el banco
Para renovar un cobro sin volver a pedir todos los datos en cada periodo, hace falta una operativa compatible con ese uso. La disponibilidad depende del terminal y de su configuración. La documentación de Redsys para desarrolladores describe las integraciones y servicios; la entidad confirma las condiciones habilitadas para tu comercio.
La conversación útil con el banco parte de una necesidad concreta: «Queremos cobrar un servicio mensual por tarjeta, con un primer pago del cliente y renovaciones posteriores». Es mucho más precisa que preguntar si el TPV «admite suscripciones», porque esa expresión puede referirse a una capacidad de procesamiento o a un programa que gestiona todo el ciclo.
Prepara estas preguntas:
- ¿El terminal contratado permite la operativa necesaria para los cobros posteriores?
- ¿Qué activación y documentación se necesitan para utilizar referencias de pago?
- ¿Cómo se realizan las pruebas antes de utilizar la configuración de producción?
- ¿Quién debe intervenir si una operación exige una acción adicional del comprador?
- ¿Cómo se consultan las operaciones para comprobar un resultado y conciliarlo?
No necesitas convertirte en especialista en parámetros bancarios. Con esas respuestas podemos revisar la puesta en marcha sobre información concreta. Los detalles de autorización y referencias están desarrollados en nuestra guía de pagos recurrentes con Redsys.
Reparte las responsabilidades antes de integrar
Una suscripción funciona mejor cuando cada pieza tiene una responsabilidad clara. Tu oferta define qué recibe el cliente. La operativa bancaria procesa el pago. AndorPay conecta la gestión del cobro con los eventos que necesita tu aplicación. El sistema que presta el servicio aplica las reglas de acceso correspondientes.
| Parte del recorrido | Decisión o información necesaria | Resultado que debe comprobarse |
|---|---|---|
| Oferta | Servicio, frecuencia y condiciones de continuidad | El comprador entiende qué contrata |
| Primer pago | Cliente, plan y operación asociados | El resultado corresponde a la contratación correcta |
| Renovación | Periodo que se cobra y fecha prevista | Un periodo no genera cargos incompatibles |
| Acceso | Inicio, duración y tratamiento de incidencias | El servicio refleja el estado acordado |
| Baja | Momento de efecto y fin del periodo vigente | Las siguientes acciones respetan la baja |
Esta separación evita un fallo frecuente: utilizar una etiqueta genérica de «activo» como respuesta a todo. Una cuenta de usuario puede seguir existiendo aunque su acceso haya terminado. Una suscripción puede estar creada aunque su primer pago todavía necesite confirmación. El modelo debe conservar esas diferencias para que atención al cliente pueda explicar qué ha ocurrido.
Para ordenar estas conexiones y decidir qué tareas automatizar primero, consulta la guía de automatización de cobros en Andorra.
Decide dónde vive el calendario
El calendario es la respuesta a «cuándo corresponde volver a cobrar». Puede partir de la fecha de alta o de un día común para todos los suscriptores, según tu oferta y la implementación disponible. Documenta cuál utilizas y qué ocurre en meses de distinta duración. «Mensual» necesita una regla compartida por la página de venta y el sistema.
También hay que decidir qué sistema inicia las renovaciones. Si un complemento de la tienda programa un cobro y otra herramienta programa el mismo periodo, puedes crear intentos duplicados. La puesta en marcha debe asignar un responsable único del calendario y dejar claro cómo reciben el resultado las demás piezas.
Incluye los cambios de plan en esta conversación. Si alguien cambia de modalidad a mitad de un periodo, define cuándo entran en vigor las nuevas prestaciones y cuándo cambia el próximo cobro. Para empezar, una política sencilla de cambio en la siguiente renovación puede resultar más fácil de explicar y mantener, si encaja con tu servicio.
Plugin o integración propia: elige por el recorrido necesario
Una tienda con un complemento compatible y una aplicación desarrollada a medida requieren trabajos diferentes. Lo importante es comprobar el recorrido disponible en tu instalación: alta, cobro, renovación, incidencia y baja. Una marca en una lista de integraciones no sustituye esa comprobación.
En una tienda, revisa qué componente gestiona las suscripciones, qué componente procesa el pago y cuál modifica el pedido. Identifica también las versiones utilizadas. Un plugin preparado para pagos únicos no demuestra, por sí solo, que pueda coordinar cualquier regla de renovación o cualquier extensión de membresías.
En una aplicación propia, el equipo debe conectar la contratación con el cliente y escuchar los cambios relevantes. Nuestra documentación del ciclo de pago distingue la confirmación económica de los eventos de suscripción. Esa diferencia permite actualizar el periodo sin confundir la creación de una suscripción con un cargo confirmado.
Para revisar el encaje, basta con un esquema de la aplicación y el recorrido que quieres ofrecer. Los detalles técnicos se concretan después. En nuestra página de TPV para cobrar online desde Andorra puedes ver cómo planteamos la conexión con el negocio.
Del alta a la primera renovación: un ejemplo completo
Imagina un servicio que da acceso mensual a una biblioteca profesional. El comprador elige la modalidad mensual, crea su cuenta y completa el primer pago. La contratación conserva la relación entre usuario, plan, pago y periodo.
El primer pago activa el periodo correcto
El navegador puede mostrar una pantalla de confirmación, pero la aplicación utiliza el resultado confirmado del pago para activar el servicio. Si el comprador cierra la ventana después de pagar, el acceso debe poder actualizarse igualmente al llegar la notificación correspondiente.
La prueba debe comprobar también el caso contrario: volver a la web sin haber completado el pago no puede abrir automáticamente un periodo de servicio pagado. La URL de retorno sirve para continuar la experiencia; el resultado económico llega por el canal previsto para ello.
La renovación amplía el servicio una sola vez
Cuando llega la siguiente fecha, el sistema responsable identifica el periodo pendiente y solicita el cobro que corresponda. Al confirmarse, la aplicación actualiza la duración del acceso. La operación y el periodo quedan relacionados para que el equipo pueda responder a una consulta posterior.
Si una misma notificación llega otra vez, el acceso no debe ampliarse un mes adicional. Procesar una comunicación dos veces no equivale a haber vendido dos periodos. Esta comprobación es especialmente importante cuando los sistemas vuelven a entregar notificaciones por una interrupción temporal.
Un fallo abre un recorrido de recuperación
Si la renovación resulta rechazada, aplica la política definida: comunicar la incidencia, ofrecer la acción necesaria y gestionar la continuidad del acceso. Si el resultado sigue pendiente, consulta el estado antes de tratarlo como rechazo. Pedir otro pago sin resolver el anterior puede crear un problema adicional.
La recuperación tiene su propia guía: cómo gestionar renovaciones fallidas. Aquí lo esencial es incorporarla al diseño inicial, para que el primer fallo no obligue a improvisar un proceso mientras el cliente espera.
Prepara la transición si ya tienes suscriptores
Añadir suscripciones nuevas y trasladar suscripciones existentes son trabajos distintos. En una transición necesitas conocer qué periodos están pagados, cuándo vence cada uno y qué sistema tiene acciones programadas. La fecha de cambio debe evitar que dos herramientas cobren el mismo ciclo.
Tampoco debes dar por hecho que una referencia de tarjeta pueda moverse entre proveedores o terminales. Esa posibilidad depende de la operativa y de las partes implicadas. Si el nuevo recorrido requiere que el cliente actualice su método de pago, prepara el mensaje, la fecha y el seguimiento antes de iniciar el traslado.
Una forma ordenada de preparar el cambio es separar suscriptores por próxima renovación. Así puedes revisar el estado de cada grupo y comunicar instrucciones relevantes. Conserva un registro de las excepciones: pagos pendientes de confirmar, bajas solicitadas y periodos que todavía corresponden al sistema anterior.
Qué probar antes de abrir las altas
Un primer pago correcto es necesario, pero deja sin comprobar gran parte de una suscripción. Prepara escenarios de prueba con cuentas destinadas a ello y verifica el resultado tanto en el cobro como en la aplicación.
- Alta completada: el usuario recibe el plan y periodo adecuados.
- Alta abandonada: no se concede acceso pagado por una simple vuelta al sitio.
- Notificación repetida: el mismo pago no genera otra entrega ni amplía dos veces el acceso.
- Renovación confirmada: se actualiza un único periodo y queda su referencia.
- Renovación rechazada: se aplica el aviso y la política de continuidad previstos.
- Resultado pendiente: el sistema mantiene el seguimiento sin iniciar otro cargo por su cuenta.
- Baja solicitada: la fecha de fin y las siguientes acciones respetan lo comunicado.
- Cambio de configuración: las claves y terminales de prueba no se mezclan con producción.
Anota el resultado esperado y el observado. Un error visible debe poder relacionarse con una operación y un momento, sin depender de capturas aisladas. Esta pequeña disciplina ahorra conversaciones de soporte en las que nadie sabe si el problema está en el cobro o en el acceso.
Qué enviarnos para revisar tu puesta en marcha
Para empezar necesitamos el banco, la plataforma, el tipo de servicio y la frecuencia de cobro. Indica si partes de cero o ya tienes suscriptores, quién mantiene la web y qué debe suceder cuando alguien paga, renueva o solicita la baja.
Añade las excepciones que de verdad utilizas: periodos de prueba, cambios de modalidad o acceso para varios usuarios. Podemos revisar su encaje dentro del alcance propuesto. Las condiciones comerciales se preparan de forma privada según la instalación y el trabajo necesario.
Si todavía estás definiendo el servicio, continúa con la guía para monetizar un servicio digital con suscripciones. Si ya tienes clara la oferta, solicita una revisión de tu TPV para suscripciones y cuéntanos cómo cobras hoy. Con ese contexto podemos concretar qué aprovechamos y qué hay que conectar.
Preguntas frecuentes
¿Tengo que cambiar de banco?
El primer paso es revisar el terminal existente y la operativa que puede habilitar tu entidad. Esa revisión permite determinar si podemos aprovechar la configuración actual o si hace falta una modificación. No necesitas decidir un cambio bancario antes de conocer esos datos.
¿Basta con instalar un plugin?
El plugin debe ser compatible con el pago y con el sistema que organiza las suscripciones. Además, hay que probar el ciclo completo. La instalación de un componente no resuelve automáticamente las reglas de acceso, los cambios de plan o la transición de suscriptores.
¿La renovación funciona si el cliente no vuelve a la web?
Ese es el recorrido que debe cubrir la operativa recurrente habilitada. El primer pago y la referencia utilizada después forman parte de su preparación. Algunas incidencias requieren una nueva acción del comprador; por eso la recuperación y la comunicación también deben estar previstas.