Para evitar la doble facturación durante una migración desde WHMCS, asigna un sistema al próximo periodo de servicio de cada cliente. Registra la última factura del sistema antiguo, la primera renovación en el nuevo sistema y cualquier pago que ya esté en cola antes de activar la facturación sustitutiva. Trasladar los registros de los clientes no transfiere la responsabilidad de la facturación ni suspende un acuerdo de pago existente.
Esta guía está dirigida a proveedores de alojamiento que trasladan la facturación recurrente de clientes a un nuevo portal, manteniendo al mismo tiempo cierta automatización del alojamiento. Se centra en la fecha de traspaso. Para obtener información más amplia sobre los datos y el inventario de módulos, utiliza la «Lista de comprobación para la migración desde WHMCS». La hoja de cálculo que aparece a continuación es una herramienta de planificación manual, no un importador automático de WHMCS.
¿Qué puede provocar un cargo duplicado durante una migración de WHMCS?
Un duplicado puede deberse a facturas que se solapan, a dos acuerdos recurrentes independientes o a un nuevo intento cuyo resultado aún no se ha recibido. La cuestión importante es qué sistema puede seguir solicitando el pago por el mismo periodo de servicio. Una exportación correcta no responde a esa pregunta.
Lógica de facturación de WHMCS documenta la generación de facturas, las fechas de vencimiento y los intentos de pago automáticos. Revisa la versión instalada y tu configuración antes de seleccionar la fecha de traspaso. Puede que ya exista una factura para un periodo futuro, incluso cuando el cliente aún no haya alcanzado su fecha de renovación.
Distinga entre una factura y un intento de pago. Dos facturas no demuestran que se hayan realizado dos cobros con éxito, y una factura visible no garantiza que solo un sistema pueda cobrar. Compruebe ambas aplicaciones de facturación y el estado real de la transacción del proveedor. Un cobro pendiente, un pago completado y un pago fallido requieren, cada uno, una acción siguiente diferente.
Los acuerdos recurrentes externos merecen una comprobación específica. WHMCS describe una pasarela opcional gestión de suscripciones para acuerdos recurrentes procesados fuera de WHMCS. La compatibilidad con los módulos y la configuración son importantes. No des por sentado que cambiar un registro de servicio cancela automáticamente todos los acuerdos por parte del proveedor.
Incluye también los recordatorios, los reintentos y las tareas de suspensión. Incluso cuando solo un sistema cobra, ambos pueden enviar un correo electrónico al cliente o iniciar una acción por servicio vencido. Un traspaso que evite movimientos de dinero duplicados puede seguir confundiendo a los clientes si dos portales distintos muestran saldos diferentes.
Crea un registro de traspaso de renovación por cada servicio
Utiliza una fila para cada servicio recurrente, en lugar de una fila para toda la cuenta de un cliente. El alojamiento, el mantenimiento y la renovación de un dominio pueden tener fechas y responsabilidades diferentes. Los datos de contacto compartidos son útiles para verificar la identidad, pero no hacen que los servicios sean intercambiables.
Descargar el archivo CSV de traspaso de renovaciones. Contiene encabezados de columna en inglés y filas de ejemplo ficticias. Sustituye los ejemplos en tu copia privada. No es un formato de importación para ninguna de las plataformas y no contiene credenciales de pago.
| Campo | Ejemplo ficticio | Comprobar antes de la activación |
|---|---|---|
| Referencia del cliente y del servicio | Ejemplo A / alojamiento gestionado | Comprueba que coincide con el servicio real, no solo con un correo electrónico |
| Periodo pagado hasta | 31 de octubre de 2026 | Confirma el periodo en la factura completada |
| Última factura del sistema antiguo | Factura de alojamiento de octubre | Separa los saldos pagados, pendientes de pago y en litigio |
| Primer periodo del nuevo servicio | 1-30 de noviembre de 2026 | Asegúrate de que este periodo no tenga ningún otro responsable de facturación |
| Primera fecha de facturación del nuevo servicio | 1 de noviembre de 2026 | Revisa los plazos del proveedor y los intentos pendientes |
| Preparación para el pago automático | Por confirmar | Verificar la autorización antes del cobro |
| Responsable del ciclo de vida del alojamiento | Flujo de trabajo de alojamiento existente | Definir quién se encarga de los fallos y las cancelaciones |
Añade el importe, la moneda, el tratamiento fiscal y la persona responsable de aprobar la línea. Estos campos evitan una migración que sea correcta en las fechas pero errónea en los totales. Un contrato de alojamiento anual facturado mensualmente también requiere que su información contractual y sobre el periodo de servicio se registre por separado.
Conserva las referencias de las facturas históricas. La sustitución de un portal no debe borrar el registro de lo que se facturó y se pagó. Decide dónde pueden los clientes recuperar documentos antiguos y cómo responderá el personal a las preguntas sobre periodos que pertenecen al sistema anterior.
Conciliar las facturas existentes antes de iniciar la facturación tras la sustitución
Empieza con un grupo reducido cuyos registros puedas revisar individualmente. Separa la deuda histórica pendiente de pago de la próxima renovación. Trasladar un saldo pendiente a un nuevo portal y crear un nuevo cargo por ese mismo saldo no es un método de conciliación.
Para cada cliente, compara la factura antigua, la transacción del proveedor y el periodo de servicio. Registra los abonos y los reembolsos por separado. Un saldo acreedor puede compensar la siguiente factura; transferir únicamente el importe bruto recurrente puede hacer que se pierda esa relación. Deja que la persona responsable de la facturación decida cómo se traslada el saldo.
Comprueba los plazos de generación de facturas, no solo las fechas de vencimiento. Si ya se ha emitido una factura de renovación anterior, decide si esa factura sigue siendo el documento cobrable o si necesita una corrección adecuada. Sigue tu proceso contable y los requisitos aplicables en lugar de eliminar registros simplemente para que el nuevo panel de control parezca limpio.
Antes de modificar un intento pendiente, consulta su estado actual con el proveedor. Una confirmación lenta puede parecer un fallo cuando el dinero aún está en tránsito. No envíes al cliente una segunda factura pagadera simplemente porque la visualización de la primera solicitud no se haya actualizado.
Mantén las excepciones fuera del primer grupo. Los pagos en disputa, los saldos en varias divisas y los servicios con prorrateos inusuales requieren una revisión por separado. El objetivo de una prueba piloto es establecer un traspaso repetible, no ocultar cuentas complicadas dentro de un total de migración más amplio.
Repaso de un traspaso mensual ficticio de alojamiento web
Supongamos que «Example Hosting» vende alojamiento gestionado por 29 € al mes. El cliente A ha pagado octubre y debería pagar a continuación noviembre. El registro de planificación indica que WHMCS gestiona octubre; PayRequest gestionará noviembre solo una vez que se hayan completado la configuración y las comprobaciones de pago.
Confirma que el sistema antiguo no haya solicitado ya el pago de noviembre. Si lo ha hecho, resuelve esa factura o intento existente antes de autorizar la nueva facturación. No cambies la primera fecha nueva a hoy simplemente porque el cliente se haya importado hoy. La fecha de importación y la fecha de fin del periodo pagado cumplen funciones diferentes.
En el caso del cliente B, supongamos que noviembre ya se ha pagado por adelantado. El primer nuevo periodo debería, por tanto, seguir esa cobertura pagada, con sujeción a las condiciones reales del servicio. Una regla general del tipo «todos los clientes empiezan el 1 de noviembre» cobraría a B por un periodo que ya estaba cubierto.
En el caso del cliente C, supongamos que octubre sigue sin pagarse. Mantén esa deuda identificable como correspondiente a octubre. Establece por separado el responsable de la facturación de noviembre y decide cómo comunicar el saldo pendiente. Activar la suscripción en un nuevo portal no implica que la factura anterior se haya pagado.
Se trata de ejemplos originales, no de informes de migraciones completadas de PayRequest. Su valor radica en la regla de decisión: cada período de servicio pagadero necesita un titular documentado, y la cobertura pagada anteriormente debe seguir siendo visible en el nuevo calendario.
Mantén los cambios de facturación separados de la cancelación del alojamiento
No utilices la cancelación del servicio como atajo para desactivar la facturación anterior sin revisar sus efectos. El documento de WHMCS documentación de cancelación explica que la cancelación del servicio puede implicar un módulo de aprovisionamiento y el acceso asociado. Una migración de facturación no debe convertirse accidentalmente en un cierre del alojamiento.
Anota qué sistema se encarga de aprovisionar las cuentas, gestionar las renovaciones de dominios y procesar las acciones relacionadas con los servicios vencidos. Si utilizas WHMCS para estas tareas, confirma cómo le llegan los resultados de facturación. La presencia de una API o un webhook no garantiza una integración funcional; alguien debe implementar y comprobar el ciclo de vida real.
Limita cada cambio de automatización al grupo autorizado. Desactivar una tarea global puede afectar a clientes a los que todavía se les factura en WHMCS. Mantén un registro de los ajustes modificados y del alcance previsto, y haz que un operador verifique qué permanece activo para las cuentas no migradas.
Utiliza la función «Guía de traspaso en caso de cancelación» cuando los clientes tengan solicitudes de cancelación pendientes. Un cliente que ya haya solicitado darse de baja no debería recibir sin previo aviso una nueva suscripción activa durante la migración.
Indica a los clientes qué factura y qué portal deben utilizar
Envía un mensaje breve en el que se indique el nuevo portal de facturación, el primer periodo afectado y cualquier acción que sea realmente necesaria. Evita prometer que se transferirán todos los métodos de pago almacenados. Utiliza la herramienta Guía de preparación para las órdenes de pago antes de decidir si es necesario que el cliente vuelva a autorizar el pago.
Un mensaje reutilizable es: «A partir del [primer periodo de servicio afectado], la facturación de [servicio] se traslada a [nuevo portal]. Tus facturas anteriores permanecen en [ubicación del documento]. Tu próximo importe programado es de [importe y moneda] el [fecha]. [Indica la acción de pago confirmada]. Si recibe dos facturas correspondientes a ese periodo, póngase en contacto con [canal de atención al cliente] antes de realizar otro pago».
Sustituya cada campo entre corchetes por el dato verificado. No envíe la plantilla como un anuncio genérico cuando los clientes tengan fechas de pago diferentes. Agrupe las comunicaciones según el periodo de transición real y explique las renovaciones de dominios por separado cuando estas permanezcan en el sistema antiguo.
Revisa la página del portal público desde la perspectiva de un cliente. Comprueba el nombre del servicio, la moneda, la próxima fecha y el acceso a la factura. Una hoja de cálculo interna correcta solo es útil si el cliente ve la información correspondiente y sabe a qué canal de asistencia debe dirigir una pregunta sobre el cambio.
Verificar la primera renovación y definir cuándo revertir el proceso
La primera renovación es el momento en el que la planificación se enfrenta a un resultado de facturación real. Comprueba conjuntamente el periodo de facturación, la transacción del proveedor, el saldo del cliente y el estado del alojamiento. Si hay un intento del proveedor pendiente, espera a obtener un resultado fiable antes de decidir volver a cobrar.
Define una condición de parada antes de ampliar el grupo: facturas duplicadas sin explicación, importes que no coinciden, autorización faltante o acceso incorrecto al servicio. Asigna a una persona para que resuelva la excepción. Una migración más pequeña y comprobada es más fácil de gestionar que un lote grande cuyos errores descubren los clientes.
La reversión requiere la misma disciplina de responsabilidad que el lanzamiento. Comprueba los intentos pendientes y completados en el nuevo sistema antes de volver a habilitar el cobro anterior. Restaurar el trabajo anterior mientras un nuevo intento sigue pendiente puede recrear el duplicado que intentabas evitar.
La «Documentación sobre el pago de la suscripción» de PayRequest distingue entre las facturas recurrentes pagadas manualmente y el cobro automático mediante un mandato válido. Revisa esa distinción y la «Demostración del portal» y, a continuación, envía la hoja de trabajo completada a «evaluación de la migración».
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 Business al finalizar la compra. Seleccionar Business durante el registro no garantiza por sí solo el acceso 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.
