VenPM: Plataforma de facturación y gestión de suscriptores a medida para un ISP venezolano

El problema

VenPM opera un proveedor de servicios de internet en Venezuela. Administrar un ISP en cualquier lugar implica gestionar suscriptores, planes de servicio, facturación recurrente y conciliación de pagos. Operarlo en Venezuela agrega restricciones para las que las plataformas de facturación estándar no fueron diseñadas.

La infraestructura de pago local no se ajusta al modelo de tarjetas y transferencias bancarias que asumen plataformas como Stripe Billing, Chargebee o Recurly. Los métodos de pago incluyen transferencias móviles, sistemas bancarios locales y puntos de cobro en efectivo que no tienen integración API con ninguna herramienta de facturación convencional. La inestabilidad cambiaria significa que los precios de los planes necesitan ajustarse frecuentemente sin romper suscripciones activas ni registros históricos. Los niveles de servicio cambian según la disponibilidad de infraestructura en áreas de cobertura específicas.

El ISP estaba manejando todo esto en hojas de cálculo y conciliación manual. Cada ciclo de facturación significaba días de cruzar registros de pago contra listas de suscriptores, perseguir montos sin conciliar y actualizar manualmente el estado de las cuentas. A medida que la base de suscriptores crecía, el proceso manual dejó de escalar, y los errores de facturación erosionan directamente la confianza del cliente en un mercado donde cambiar de proveedor es fácil.

Qué construimos

Gestión de suscriptores

Seguimiento completo del ciclo de vida desde el alta hasta el servicio activo, suspensión y cancelación. Cada registro de suscriptor se vincula a un plan de servicio, historial de facturación, historial de pagos y un estado de cuenta que refleja la realidad en tiempo real en lugar de esperar un pase de conciliación mensual. El flujo de alta captura lo que el ISP realmente necesita (dirección de servicio, selección de plan, preferencia de método de pago) sin la sobrecarga de un modelo de contacto genérico de CRM.

Arquitectura de planes de servicio

Definiciones de planes flexibles que soportan cómo los ISPs venezolanos realmente fijan precios: por nivel de ancho de banda, por zona, con precios que pueden ajustarse sin romper suscripciones existentes. Los cambios de plan toman efecto en el próximo ciclo de facturación con registros claros de cuánto pagaba cada suscriptor y cuándo. Los precios históricos se preservan para que las disputas de facturación puedan resolverse contra los términos que estaban vigentes, no las tarifas actuales.

Motor de facturación recurrente

Generación automatizada de ciclos de facturación que reemplaza el trabajo manual: generando facturas por suscriptor por ciclo, aplicando la tarifa correcta del plan al momento de la generación, rastreando el estado de pago y marcando cuentas vencidas. El motor maneja pagos parciales (comunes en el mercado local), asignación de pagos entre múltiples facturas pendientes y actualizaciones automáticas del estado de cuenta basadas en la situación de pago.

Conciliación de pagos

La parte más difícil de la construcción. Los pagos llegan por múltiples canales con niveles variables de datos estructurados. El sistema de conciliación empareja pagos entrantes contra facturas pendientes usando números de referencia, montos e identificadores de suscriptor. Los pagos sin emparejar aparecen en una cola de revisión en lugar de fallar silenciosamente o esconderse en una hoja de cálculo hasta que alguien nota que los números no cuadran.

Panel de operaciones

Una vista centralizada de la salud de la base de suscriptores, rendimiento de facturación, tasas de cobro y estados de cuenta. El panel le da a los operadores del ISP las métricas que importan: suscriptores activos por plan, ingreso por ciclo, cuentas vencidas, tasa de abandono y distribución de métodos de pago. Diseñado para que el equipo pueda ver de un vistazo si el negocio está saludable en lugar de pasar horas extrayendo datos de múltiples archivos.

Cómo está construido

El backend es Node.js con PostgreSQL. PostgreSQL fue elegido específicamente por la integridad transaccional en operaciones de facturación: generación de facturas, registro de pagos y actualizaciones de estado de cuenta corren dentro de transacciones de base de datos para que las fallas parciales no puedan dejar el sistema en un estado inconsistente. Los datos financieros no toleran consistencia eventual.

El frontend es React, construido como una interfaz administrativa limpia enfocada en los flujos de trabajo que el equipo del ISP ejecuta diariamente: búsqueda de suscriptores, registro de pagos, gestión de ciclos de facturación y reportes. La interfaz fue diseñada alrededor de las tareas reales diarias, no un panel de administración genérico con cada operación CRUD posible expuesta.

La arquitectura mantiene una separación limpia entre los conceptos de cara al cliente (planes, facturas, estado de cuenta) y el backend administrativo (motor de facturación, conciliación, reportes). Esta separación significa que el ISP puede exponer un portal de autoservicio para clientes más adelante sin reestructurar el backend.

Qué cambió para el equipo

El ISP dejó de manejar la facturación en hojas de cálculo. Estado de suscriptores, historial de facturación y registros de pago viven en un solo sistema con garantías transaccionales, no dispersos en archivos que una sola persona entiende.

El ciclo de conciliación mensual, antes un esfuerzo manual de varios días, se movió a un flujo de revisión estructurado donde los pagos sin emparejar aparecen para revisión humana en lugar de esconderse hasta que los números del fin de mes no cuadran.

La plataforma maneja las restricciones que hicieron que las herramientas de facturación estándar fueran inviables. Métodos de pago locales, ajustes flexibles de precios, pagos parciales y conciliación multicanal son funcionalidades de primera clase, no parches sobre un sistema diseñado para un mercado diferente.

El stack en resumen

• Frontend: React
• Backend: Node.js
• Base de datos: PostgreSQL (integridad transaccional de facturación)
• Funcionalidades clave: Motor de facturación recurrente, conciliación de pagos multicanal, gestión del ciclo de vida de suscriptores
• Arquitectura: Separación limpia entre capas administrativa y de cara al cliente

Este es el tipo de proyecto que no puede correr en Stripe Billing, no puede correr en Chargebee, y no puede correr en ninguna plataforma construida alrededor de infraestructura de pago estadounidense. Construido a medida para un mercado y flujo de trabajo que las herramientas estándar no sirven.