Una exportación de clientes de WHMCS no es un mandato de pago transferible. Antes de migrar la facturación recurrente, identifica la cuenta del proveedor, la referencia de pago guardada y la autorización utilizada por cada servicio. A continuación, confirma si el destino puede utilizar esa configuración o si el cliente necesita una nueva autorización. Los datos de la factura y el permiso para cobrar son registros diferentes.
Esta guía ayuda a los proveedores de alojamiento a planificar esa decisión. No proporciona un script de copia de tokens ni promete la portabilidad automática de los métodos de pago. La hoja de trabajo de preparación original que figura a continuación puede completarse sin recopilar los datos brutos de la tarjeta. Para una migración más amplia, empieza por la «Lista de comprobación para la migración desde WHMCS».
¿Qué representa un método de pago guardado en WHMCS?
Una referencia de pago guardada identifica una relación en una pasarela y una cuenta de proveedor concretas. Su significado depende del módulo. Puede referirse a un cliente, a un método de pago almacenado o a un acuerdo recurrente externo. La etiqueta por sí sola no indica si la nueva plataforma podrá realizar el cobro.
El documento oficial «Documentación del módulo de Stripe para WHMCS» describe el almacenamiento tokenizado y las referencias específicas de cada módulo. Revisa el módulo que utiliza realmente tu instalación. Un identificador de cliente de Stripe no es un calendario de suscripción completo, y un calendario no identifica por sí solo una tarjeta válida.
Algunas pasarelas crean acuerdos recurrentes fuera de WHMCS. La página independiente Documentación sobre la gestión de suscripciones de WHMCS describe los ganchos de cancelación de la pasarela para esos acuerdos. Se trata de un mecanismo diferente al de una aplicación que decide cuándo generar una factura y solicitar el pago.
Anota el nombre y la versión reales de la pasarela, la cuenta del proveedor y el titular del cobro. Averigua quién inicia cada renovación: WHMCS, el sistema de suscripción del proveedor u otra integración. Sin esa respuesta, es fácil desactivar un plan mientras un acuerdo independiente sigue cobrando.
Considera el inventario inicial como una recopilación de pruebas. No modifiques las referencias activas mientras las identificas. Una instantánea estable permite al equipo de facturación comparar el acuerdo anterior con el destino previsto e identificar las cuentas que requieren un tratamiento especial antes de la próxima renovación.
Separa los datos del cliente, la autorización y los calendarios de renovación
Los datos del cliente te ayudan a verificar la identidad. La autorización establece una forma válida de cobro. El calendario determina cuándo y cuánto facturar. Mantén estos tres elementos como comprobaciones independientes, incluso cuando la interfaz anterior los muestre en una sola página.
Descargar el archivo CSV de preparativos para el pago. La plantilla en inglés registra los resultados de la verificación y las referencias ficticias. Se trata de una hoja de trabajo de planificación, no de un archivo de importación obligatorio del proveedor. No incluyas en ella números de tarjeta, códigos de seguridad, contraseñas ni claves secretas de API.
| Registro | Pregunta de planificación | Ejemplo de resultado |
|---|---|---|
| Coincidencia del cliente | ¿Pertenece esta referencia al cliente previsto? | Identidad verificada |
| Cuenta del proveedor | ¿A qué cuenta pertenece el método guardado? | Cuenta existente registrada |
| Autorización de pago | ¿Puede el nuevo sistema usar esta autorización para este servicio? | A la espera de confirmación |
| Calendario de renovación | ¿Qué periodo ya se ha pagado? | Octubre pagado; noviembre próximo |
| Titular del cobro | ¿Qué sistema inicia el pago hoy? | Flujo de trabajo de la pasarela existente |
| Asignación de destino | ¿Se ha verificado allí una referencia compatible? | No está listo para el cobro automático |
En el caso de un cliente ficticio A, es posible que todos los datos de contacto se transfieran correctamente, mientras que la asignación de pago sigue sin confirmarse. Ese cliente no está listo para el cobro automático. Marcar el registro como «importado» no debería agrupar las tres comprobaciones en un único estado verde.
En el caso del cliente B, es posible que el acuerdo de pago esté confirmado, pero que el siguiente periodo ya se haya abonado. Una autorización correcta no justifica volver a cobrar. Combina esta hoja de cálculo con la «registro de traspaso de renovaciones» antes de la activación.
Comprueba si vas a cambiar de proveedor de pagos
Pasarse a una nueva interfaz de facturación y cambiar a un nuevo proveedor de pagos son proyectos distintos. Mantener el mismo proveedor puede reducir algo de trabajo, pero no garantiza que dos integraciones puedan utilizar las mismas referencias de cliente y de pago.
Si la cuenta del proveedor sigue siendo la misma, pregunta a la integración de destino qué tipos de referencia acepta, cómo se verifica la titularidad y qué configuración se requiere. Confirma esto con un pequeño grupo de prueba autorizado. No sustituyas el nombre de una cuenta conocida por la compatibilidad real con la vía de cobro.
Si cambia el proveedor, pregunta a ambos proveedores sobre el proceso de migración admitido. Guía de Mollie para la importación de mandatos de tarjetas describe una transferencia coordinada de proveedores y la asignación a nuevas referencias. Separa explícitamente la migración de la información de la tarjeta de la lógica de suscripción. Esa distinción es fundamental para planificar el cambio de facturación.
El proceso de tarjetas de Mollie no es un método universal para todos los tipos de pago. Su documentación distingue la migración de tarjetas de las vías de mandato SEPA y PayPal. Planifica en función de tu método, cuenta e integración reales, en lugar de tratar cada fila de pago guardada como si fuera intercambiable.
Mantén la coordinación con los proveedores separada de cualquier promesa sobre la experiencia del cliente. Hasta que se verifiquen la asignación de destino y la primera ruta de cobro, el estado real es «en verificación». Una fecha de migración debe reflejar la preparación, no una suposición generalizada de que todos los métodos guardados se transferirán.
Decide cuándo la reautorización del cliente es la vía más clara
Cuando no se pueda confirmar que un acuerdo existente es válido, planifica una nueva autorización del cliente en lugar de intentar una copia de referencia no compatible. Explica al cliente qué acción es necesaria, qué servicio cubre y cuándo comenzará el cobro futuro.
La reautorización no debe pedir al cliente que envíe por correo electrónico los datos de la tarjeta. Diríjale a través del flujo configurado del método de pago seguro. El personal no debe recabar el número de tarjeta ni el código de seguridad en un ticket de asistencia para sortear una integración incompleta.
Utiliza mensajes diferentes para las cuentas confirmadas y las no confirmadas. Un cliente cuya asignación de pago esté lista no debería recibir una solicitud innecesaria para añadir otra tarjeta. Un cliente cuya asignación no esté lista no debería recibir un mensaje tranquilizador del tipo «no es necesario realizar ninguna acción» simplemente porque su dirección de correo electrónico se haya importado correctamente.
Un mensaje reutilizable es: «La facturación de [servicio] se trasladará a [portal] a partir del [periodo]. Necesitamos que autorices el método de pago a través de [enlace de configuración verificado] antes del [fecha]. Tu cobertura de pago actual finaliza el [fecha]. Confirmaremos el próximo importe programado antes de iniciar el nuevo cobro».
Sustituye cada campo por el dato real y utiliza la URL de destino verificada. Revisa quién puede responder a las preguntas de los clientes y cómo se gestiona una autorización incompleta. Los correos electrónicos de recordatorio repetidos no pueden hacer que un acuerdo de pago no respaldado sea válido.
Comprender la facturación automática y manual de suscripciones de PayRequest
La guía «Documentación sobre el pago de la suscripción» de PayRequest describe el cobro automático mediante un mandato válido asignado y la facturación recurrente manual. El flujo de trabajo de mandatos documentado utiliza Mollie. No interpretes la presencia de una conexión con Stripe en cualquier otro lugar como prueba de que cualquier referencia de WHMCS a Stripe pueda asignarse a este flujo.
Revisa el método de pago que figura en la suscripción real. Confirma la titularidad del cliente y el estado válido del mandato a través de la interfaz compatible. Una referencia conocida copiada en un campo no relacionado no demuestra que una vía de cobro funcione ni que el cliente la haya autorizado.
La facturación periódica manual puede servir a los clientes que pagan mediante transferencia bancaria, cuando el producto y la configuración lo permiten. Proporciona al cliente una factura pendiente de pago en lugar de realizar un cobro automático. Esto modifica el trabajo operativo: alguien debe supervisar la factura y el resultado del pago antes de dar por saldado el importe.
Elige el método de forma deliberada. La facturación manual no debe ser un recurso invisible al que recurrir cuando falla un cobro automático prometido. Indica a los clientes si se les cobrará automáticamente o si deben pagar la factura, y mantén esa instrucción coherente con el estado del portal.
El «portal del cliente» forma parte de la experiencia, pero el portal por sí solo no constituye una autorización de pago. Utiliza el «Demostración del portal» para evaluar las tareas de los clientes, mientras se revisa por separado la asignación de pagos.
Prueba la asignación de referencia antes de la primera renovación en producción
Prepara un breve registro de verificación para cada cuenta piloto. En él deben figurar la referencia del servicio anterior, el cliente de destino, el próximo periodo, la forma de pago y la persona que lo ha comprobado. Registra las observaciones y los resultados sin recopilar datos confidenciales sobre el pago.
En el caso de una ruta automática, confirma la modalidad de pago válida y el importe adeudado antes de realizar una comprobación de cobro autorizada. Observa el resultado real del proveedor y el estado de la factura. Que una suscripción aparezca como activa no sustituye a la verificación del pago correspondiente.
En el caso de una ruta manual, comprueba las instrucciones de la factura y cómo se concilia el pago. La ausencia de un mandato puede ser intencionada. La cuestión es si el flujo de trabajo seleccionado se ajusta a la configuración del producto y al compromiso adquirido con el cliente.
Comprueba también que el antiguo responsable del cobro no pueda facturar el mismo período. Un método de pago de destino correcto puede facilitar el cobro duplicado si la pasarela anterior sigue actuando de forma independiente. Lee el documento «Guía de migración para evitar la doble facturación» antes de reactivar cualquier tarea anterior tras una comprobación fallida.
Utilice una condición de puesta en marcha basada en pruebas: referencia validada, cliente correcto, importe y fecha correctos, un único responsable del cobro y un resultado revisado. «Todas las filas importadas» es un hito en el procesamiento de datos. No constituye la prueba completa de aceptación del pago.
Gestione la preparación de pagos incompletos sin perder el control
Mantenga las cuentas no confirmadas en un grupo separado. Asigna a cada una una acción: confirmación del proveedor, reautorización del cliente, una ruta de facturación manual acordada explícitamente o un traspaso pospuesto. Evita activar todo el grupo y esperar a que los pagos fallidos identifiquen las excepciones más adelante.
En el caso de renovaciones urgentes, mantén al antiguo responsable solo mientras siga siendo el titular de facturación acordado. Documenta la fecha de traspaso revisada. Si el nuevo sistema ya ha realizado un intento, comprueba el resultado antes de permitir que el sistema anterior vuelva a cobrar.
Conserva los registros históricos de pagos y las notas de asistencia. Una correspondencia de proveedores resulta útil para cotejar referencias, pero es posible que los clientes sigan preguntando por un reembolso, una factura o una descripción de extracto antiguos. Proporciona al personal una forma de rastrear esas consultas sin guardar copias innecesarias de credenciales.
Envía la hoja de trabajo de preparación cumplimentada al equipo de «Evaluación de la migración desde WHMCS». Describe tu proveedor, los métodos y la automatización del servicio. Esto proporciona al equipo una configuración concreta que revisar, en lugar de una solicitud para «trasladar todas las suscripciones» sin definir qué incluye.
PayRequest Business cuesta 20 € al mes e incluye el portal del cliente y la facturación recurrente. Las comisiones de pago estándar de la plataforma son del 0 % mientras el plan de pago esté activo. Las comisiones de procesamiento del proveedor se aplican por separado; los pagos de comisiones conservan su comisión independiente. Completa la configuración de la cuenta y activa el plan Business al finalizar la compra. Seleccionar Business durante el registro no activa las funciones de pago. Consulta Precios actuales antes de elegir tu configuración.
Nota editorial: La IA ha colaborado en la elaboración de este artículo y su portada ilustrativa. La documentación oficial se revisó el 7 de octubre de 2026. Las hojas de cálculo y los mensajes a los clientes son plantillas de planificación originales. Todos los ejemplos son ficticios; no se ha realizado ningún cargo real, migración de clientes ni cancelación de alojamiento para este artículo.
