Plataforma de suscripciones y pagos recurrentes para OTT y SaaS en LATAM

En mayo de 2026, Bitobee entregó la plataforma de suscripciones de LPF Play —el portal de streaming de la Liga Profesional de Fútbol Argentina. El requisito no era construir una landing page bonita. Era construir un sistema que soporte más de un millón de visitas mensuales el día que Boca juega con River, que gestione suscriptores en múltiples países con medios de pago distintos, que no pierda un solo cobro recurrente, y que tenga el nivel de seguridad de identity que exige una operación de esa escala.

La plataforma se auditó bajo condiciones reales por el Senior TAM de Pressable (Automattic) antes del lanzamiento. El resultado: 0 errores en test de stress, base de datos en Grade A, 99,63% de hit ratio de object cache, y capacidad certificada para manejar el pico de un partido de alta audiencia.

Ese mismo sistema —la arquitectura de identity, la gestión de suscriptores, la integración multi-pasarela y la infraestructura que lo sostiene— está disponible para cualquier empresa de tecnología, media, OTT o servicios que tenga el mismo problema: suscriptores a escala, cobranza recurrente que no puede fallar, y múltiples medios de pago en distintos países.

Este artículo describe la plataforma, cómo funciona, qué problemas resuelve y para qué perfiles de empresa tiene sentido.

📊 Dato clave: El mercado global de billing y gestión de suscripciones supera los USD 7.800 millones en 2025, con un CAGR proyectado del 16,8% hasta 2030. El 67% de las empresas SaaS y OTT identifica la gestión de cobranza recurrente y la recuperación de pagos fallidos como su principal cuello de botella operativo a escala. (Fuente: Grand View Research Subscription Management Market 2025 / Zuora State of the Subscription Economy)

El problema que la mayoría de las plataformas de suscripción no resuelven bien

Cuando una empresa escala su base de suscriptores, los problemas que aparecen no son los que se anticiparon en el diseño inicial. El formulario de pago funciona. El usuario puede crear su cuenta. La primera cobranza sale bien.

Los problemas aparecen después. En la segunda cobranza del cliente que cambió de tarjeta. En el pico de tráfico del día del partido o del lanzamiento del nuevo plan. En el usuario que quiere pagar desde México con OXXO mientras otro paga desde Argentina con Mercado Pago. En el suscriptor que se dio de baja hace tres meses y todavía aparece como activo en el sistema porque la sincronización entre el IdP y el CRM falló silenciosamente.

Esos problemas no son técnicos en el sentido de que requieran ingeniería extraordinaria. Son problemas de arquitectura: de cómo están conectados los componentes del sistema y qué pasa cuando una parte falla.

⚠ El error más frecuente en plataformas de suscripción es tratar el identity, la cobranza y la gestión de suscriptores como sistemas separados que se comunican por API. Cuando uno de los tres falla, el estado del suscriptor se vuelve inconsistente —y recuperar esa consistencia requiere intervención manual. La arquitectura de Bitobee los trata como un sistema unificado desde el diseño.

📊 Dato clave: El 9% de los suscriptores de una plataforma típica tiene algún problema de cobranza en un mes dado. Sin recuperación automática, ese 9% se convierte en churn. Las plataformas que implementan recuperación automática de pagos fallidos (dunning) recuperan entre el 40% y el 70% de esos suscriptores antes de la baja. (Fuente: Recurly State of Subscriptions 2025 / Chargebee Subscription Metrics Report)

La arquitectura: cómo está construida la plataforma

La plataforma se construye sobre tres capas que operan de forma integrada.

Capa 1: Identity Service — AuthSys

El identity service es el componente más crítico y el más frecuentemente subestimado. En la mayoría de las implementaciones, el manejo de identidad vive dentro del mismo sistema que el ecommerce o la plataforma de contenido —con passwords en la misma base de datos, sin tokens de corta duración y sin separación entre la identidad del usuario final y la del administrador.

AuthSys es un portal hosted separado, completamente independiente del sitio principal. El usuario es redirigido a login.lpfplay.com (o al dominio de la empresa), ingresa sus credenciales, y vuelve al sitio ya autenticado. Es el mismo patrón que usan Google, GitHub y Auth0: separar la responsabilidad de “manejar identidad” de la responsabilidad de “ser un sitio”.

Protocolo OAuth 2.0 Authorization Code + PKCE (S256) —el estándar moderno para apps web públicas
JWT access_token (vida ~1h) + id_token (claims del usuario) + opaque refresh_token para renovación silenciosa
Sesiones PHP separadas de wp-admin —los suscriptores no son usuarios de WordPress
Multi-device: el usuario puede tener múltiples sesiones simultáneas con gestión individual desde su cuenta
Anti-enumeración en el flujo de recuperación de contraseña: protección contra ataques de descubrimiento de emails registrados
Compatible con cualquier IdP del mercado: Auth0, AWS Cognito, Azure AD B2C, Okta

AuthSys en LPF Play — datos de la auditoría Pressable (mayo 2026). El authsys-bridge fue calificado como “bien diseñado” por el Senior TAM de Pressable. El flow completo —desde el click en “Iniciar sesión” hasta el dashboard de cuenta— opera con 9 plugins activos totales (vs. 20-40 en una instalación típica). 0 queries adicionales por plugin innecesario. La separación de identity del sitio principal permite que el portal aguante un pico de logins simultáneos sin degradar la experiencia del usuario logueado en el sitio.

Capa 2: Gestión de suscripciones y cobranza recurrente

La gestión de suscripciones no es solo registrar que un usuario tiene un plan. Es el motor que determina qué puede ver el usuario, cuándo se renueva su plan, qué pasa cuando el cobro falla, cómo se gestiona un upgrade desde el plan gratuito al premium, y cómo se sincroniza ese estado en tiempo real entre el procesador de pago, el identity service y el frontend que muestra los contenidos.

Planes configurables por producto: free, premium, multi-tier, facturación mensual/anual
Integración nativa con Mercado Pago (Argentina/LATAM), Toku (México) y Stripe (global)
Arquitectura agnóstica de pasarela: el mismo flujo de suscripción funciona con cualquier procesador que soporte webhooks
Flujo de dunning configurable: detección de pago fallido → reintento automático → notificación al usuario → período de gracia → baja
Sincronización del estado del suscriptor entre el procesador de pago y el identity service en tiempo real
Dashboard de cuenta del usuario: plan activo, datos personales, historial de pagos, cambio de contraseña, cerrar sesión en dispositivos específicos

Capa 3: Infraestructura enterprise de Automattic

La infraestructura no es un detalle de implementación —es la condición que hace que todo lo anterior funcione bajo carga real. LPF Play tiene un patrón de tráfico que pocas plataformas replican: tráfico base moderado durante la semana y picos masivos durante los 90 minutos de un partido con alta audiencia. La infraestructura tiene que manejar ambos escenarios sin degradación y sin escalar manualmente antes de cada evento.

Pressable (Automattic) —la misma infraestructura que usa la Casa Blanca, NASA, CNN y Bloomberg— es la base del stack. Si querés ver el detalle de esa infraestructura aplicada a ecommerce B2B, mirá infraestructura ecommerce B2B sobre WordPress, WooCommerce y Pressable. La auditoría pre-lanzamiento realizada por Phillip Clapham, Senior TAM de Pressable, validó los siguientes parámetros:

Auditoría de performance Pressable — LPF Play (14 mayo 2026)

Test de stress en condición más exigente posible (100% cache-bypass — portal de autenticación):

135 requests totales — 0 errores — Tasa de éxito 100%
Response time promedio: 807ms | Mediana: 794ms | Banda principal (82%): 760–890ms
CPU pico: ~0,027 cores — sin saturación
Memoria: 85,29MB → 85,33MB en 2 minutos — sin leak
Hit ratio object cache: 99,63% — excepcional
Base de datos: Grade A — 10,6MB, 110KB autoload, 100% InnoDB, 35 queries por render
Calificación del TAM: “uno de los estados pre-lanzamiento más limpios observados en este tipo de auditorías”

Capacidad certificada: 17 workers / 1M visitas/mes en Plan Premium 6 (USD 1.317/mes anual). Post quick-wins: capacidad efectiva +50%. Post-optimización completa: +100%.

Las 7 capacidades críticas de la plataforma

Capacidad	Qué hace	Por qué importa
Identity Service (AuthSys)	Autenticación OAuth 2.0 + PKCE. Portal hosted separado del sitio principal. JWT access/id/refresh tokens. Multi-device con gestión de sesiones individuales. Compatible con cualquier IdP.	Todo el flujo de identidad vive fuera del sitio —no hay passwords en la base de datos del ecommerce. El mismo Identity Service puede conectarse a múltiples productos de la misma empresa.
Gestión de suscripciones	Planes y tiers configurables. Upgrades/downgrades automáticos. Estado de suscripción en tiempo real por usuario. Dashboard de cuenta integrado.	Un usuario puede tener múltiples suscripciones activas. La plataforma gestiona el estado y las notificaciones sin intervención manual del equipo.
Pasarelas de pago multi-país	Arquitectura agnóstica de medio de pago. Mercado Pago (LATAM), Toku (México), Stripe y otros. Lógica de intento y reintento configurable.	El mismo producto puede cobrar en Argentina con Mercado Pago, en México con Toku y en otros mercados con Stripe —sin duplicar la lógica de negocio.
Infraestructura Automattic	Pressable / WordPress VIP. Uptime 100% SLA. CDN global 28+ data centers. Auto-escalado automático. Certificado para 1M+ visitas/mes.	Auditada por el Senior TAM de Pressable: 0 errores en 135 requests bajo test de stress, 100% tasa de éxito, sin leak de memoria, 82% de requests en banda principal.
Performance y escalabilidad	Respuesta promedio 807ms bajo carga máxima de cache-bypass. Capacidad derivada: 17 workers / ~4,25 RPS sostenido pre-optimización. Post quick-wins: ~6,5 RPS (+50%). Post-optimización completa: ~8,5 RPS (+100%).	Stack con 9 plugins activos vs. 20-40 típicos. Base de datos Grade A (10,6 MB, 110 KB autoload, 99,63% hit ratio). “Uno de los estados pre-lanzamiento más limpios observados” según el TAM.
Gestión de dispositivos y sesiones	Registro de cada login con event en active_devices. El usuario ve todas sus sesiones activas y puede cerrar cada una individualmente. Multi-device simultáneo soportado de base.	Crítico para plataformas OTT y media donde el usuario accede desde TV, celular y web al mismo tiempo.
Recuperación de cobranza	Detección de estado de pago fallido. Flujos de reintento configurables. Notificaciones automáticas al usuario. Lógica de gracia antes de baja de suscripción.	El sistema no necesita intervención humana para los ciclos de reintento —detecta, reintenta y notifica de forma autónoma.

Para qué empresas fue construida esta plataforma

La arquitectura de LPF Play no es una solución a medida para una liga de fútbol. Es una plataforma de propósito general para cualquier empresa que tenga estas características: suscriptores a escala, cobranza recurrente que no puede fallar, múltiples medios de pago, y picos de tráfico que requieren infraestructura elástica.

Perfil de empresa	Problema específico	Cómo aplica la plataforma
Plataformas OTT y streaming	Múltiples planes, múltiples países, pico de tráfico en eventos en vivo. El mismo problema que LPF Play.	El mismo stack de AuthSys + gestión de suscripciones funciona para cualquier plataforma de video o audio con acceso por suscripción.
Medios digitales y publishers	Paywalls con planes freemium y premium, cobro recurrente, acceso diferenciado por contenido.	La lógica de acceso por suscripción y el portal de cuenta del usuario final son los mismos componentes, configurados para contenido editorial.
SaaS y plataformas de software	Tiers de funcionalidad (free / pro / enterprise), facturación mensual o anual, gestión de upgrades, cobranza en distintos países.	La plataforma gestiona el ciclo de vida del suscriptor sin desarrollo a medida para cada nueva pasarela o plan.
Clubes, ligas y federaciones deportivas	Membresías digitales, acceso a contenido exclusivo, suscripciones anuales con renovación automática.	Arquitectura probada bajo el nivel de exigencia de una liga profesional de fútbol con audiencia masiva.
Empresas de servicios con cobranza recurrente	Seguros, salud, utilities digitales, gimnasios online — cualquier modelo donde el usuario paga mensualmente y la mora impacta el flujo de caja.	La lógica de reintento de cobranza y recuperación de suscriptores morosos es la misma independientemente del rubro.
Empresas en expansión multi-país	Operaciones en Argentina + México + Colombia + otros mercados, con medios de pago distintos en cada uno.	Una sola plataforma de identity y suscripciones, múltiples procesadores de pago configurados por país —sin duplicar la lógica.

📊 Dato clave: El mercado de OTT en América Latina alcanzó USD 5.100 millones en 2024, con más de 270 millones de suscriptores activos. El 35% de las empresas SaaS en LATAM opera en 3 o más países con medios de pago distintos. La gestión de identidad deficiente y los pagos fallidos no recuperados son las dos causas principales de churn involuntario. (Fuente: Digital TV Research LATAM OTT Report 2024 / Zuora Subscription Economy Index)

El problema de la cobranza que más dinero cuesta y menos se habla

Hay un tipo de churn que la mayoría de las empresas de suscripción no tiene bien medido: el churn involuntario. Es el suscriptor que no quiso darse de baja, pero cuyo cobro falló y el sistema no supo recuperarlo.

Puede ser una tarjeta vencida. Un límite de crédito temporalmente excedido. Un error de autorización del banco que al día siguiente se hubiera aprobado. En todos esos casos, el suscriptor seguía queriendo pagar. El problema fue que el sistema no tenía la lógica para reintentarlo en el momento correcto.

📊 Dato clave: El churn involuntario representa entre el 20% y el 40% del churn total de una plataforma de suscripción típica. Un sistema de dunning correctamente configurado (detección → reintento inteligente → comunicación al usuario → período de gracia) recupera entre el 40% y el 70% de los cobros fallidos antes de la baja definitiva. (Fuente: Recurly State of Subscriptions 2025 / ProfitWell Subscription Metrics)

La plataforma de Bitobee incorpora un flujo de dunning configurable que gestiona el ciclo completo de forma autónoma:

Detección inmediata del evento de pago fallido vía webhook del procesador
Reintento automático en ventanas configurables (24h, 48h, 72h —según el patrón de aprobación del procesador)
Notificación al usuario con CTA directo para actualizar método de pago
Período de gracia configurable antes de la baja de acceso
Sincronización del estado de la suscripción en AuthSys en tiempo real

⚠ Sin un sistema de dunning bien configurado, un error de pago en el día 1 del ciclo se convierte en una baja permanente el día 3. Con dunning activo, ese mismo error se convierte en un pago exitoso el día 2 o 3 en más del 50% de los casos —sin que nadie en el equipo haya intervenido.

La diferencia con armar la misma solución desde cero

La primera pregunta que hacen los CTOs cuando ven esta plataforma es: ¿por qué no lo construimos internamente?

La respuesta no es que no puedan. Es que el tiempo que lleva construirlo desde cero —con el mismo nivel de seguridad, la misma robustez de dunning, la misma infraestructura certificada y las mismas integraciones de pasarela— es tiempo que la empresa no está adquiriendo suscriptores.

Componente	Tiempo típico de construcción desde cero
Identity service propio con OAuth 2.0 + PKCE y manejo de tokens	3-6 meses
Integraciones de pasarela	2-4 semanas por pasarela + mantenimiento ante cambios de API
Flujo de dunning con reintentos, notificaciones y sincronización	4-8 semanas
Infraestructura enterprise con SLA y certificación 1M+ visitas	Meses de evaluación, onboarding y configuración
Auditoría de performance pre-lanzamiento	Semanas con equipo técnico especializado

La plataforma de Bitobee entrega todo eso ya construido, auditado y en producción —validado bajo el nivel de exigencia de una liga profesional de fútbol con audiencia masiva.

📊 Dato clave: El costo promedio de construir un sistema de gestión de suscripciones desde cero para una empresa SaaS o OTT mediana oscila entre USD 150.000 y USD 400.000 en el primer año (desarrollo + infraestructura + integraciones). El time-to-market es de 6-12 meses. Plataformas especializadas reducen ese costo a una fracción y el tiempo de implementación a semanas. (Fuente: Zuora / Recurly / Chargebee Implementation Cost Benchmarks 2025)

Si querés evaluar el TCO completo frente a alternativas enterprise como VTEX o Shopify Plus, leé alternativa enterprise a VTEX y Shopify Plus en LATAM.

Cómo Bitobee acompaña la implementación

La plataforma no se entrega como un producto que el cliente configura solo. Se implementa con el acompañamiento técnico de Bitobee en cada etapa: desde la definición de la arquitectura de identity hasta la configuración de los planes, la integración con las pasarelas de pago, y la auditoría de performance pre-lanzamiento.

Para empresas que ya tienen una plataforma existente, el trabajo incluye el análisis de migración: cómo trasladar la base de suscriptores existente al nuevo sistema sin interrupción del servicio y sin requerir que los usuarios re-ingresen sus datos de pago.

Definición de la arquitectura de identity y mapeo de los flujos de autenticación
Configuración de planes y lógica de acceso por tier
Integración con las pasarelas de pago del mercado objetivo
Configuración del flujo de dunning y recuperación de cobranza
Auditoría de performance pre-lanzamiento sobre infraestructura Pressable o WordPress VIP
Monitoreo de la base de datos y los patrones de tráfico post-lanzamiento

Conclusión

La plataforma de suscripciones de LPF Play no se construyó como un proyecto de nicho para una liga de fútbol. Se construyó como una arquitectura de propósito general para el problema más frecuente de las empresas que escalan con suscriptores: hacer que la cobranza no falle, que el identity sea seguro, que la plataforma no caiga el día del pico de tráfico, y que los suscriptores de cinco países distintos puedan pagar con el medio de pago que tienen disponible.

La validación de ese sistema bajo condiciones reales —0 errores en test de stress, base de datos en Grade A, certificación de 1M visitas/mes por el equipo técnico de Pressable/Automattic— no es un argumento de marketing. Es evidencia técnica documentada de que la plataforma hace lo que dice hacer.

Para cualquier empresa de tecnología, media, OTT o servicios que tenga ese mismo problema, el sistema ya está construido, auditado y disponible.

¿Tu empresa tiene suscriptores a escala y problemas con la cobranza recurrente o los picos de tráfico? Agendá una sesión técnica con Bitobee →

Preguntas frecuentes

¿La plataforma funciona para empresas fuera del sector deportivo?

Sí. La plataforma de LPF Play es la misma arquitectura que puede usarse para cualquier empresa con suscriptores: SaaS, OTT de video/audio, medios digitales, servicios de salud, clubes y membresías, o cualquier modelo donde el usuario pague de forma recurrente y necesite un portal de cuenta.

¿Se puede integrar con un procesador de pago que no sea Mercado Pago o Toku?

La arquitectura es agnóstica de pasarela. Cualquier procesador que soporte webhooks para eventos de pago puede integrarse. La plataforma tiene conectores nativos para Mercado Pago (Argentina/LATAM), Toku (México) y Stripe (global). Para otros procesadores se evalúa el desarrollo del conector.

¿Qué pasa si la empresa ya tiene una base de suscriptores en otro sistema?

La migración es parte del proceso de implementación. Se diseña un plan de migración que traslada la base de suscriptores al nuevo sistema de identity y cobranza sin interrupción del servicio. Los usuarios no necesitan re-registrarse ni re-ingresar datos de pago si el procesador soporta la portabilidad de tokens.

¿La plataforma puede manejar múltiples países con medios de pago distintos?

Sí. Es exactamente el caso de uso para el que fue diseñada. Un mismo producto puede tener Mercado Pago como procesador en Argentina, Toku en México y Stripe en otros mercados —con la misma lógica de suscripción y el mismo portal de cuenta del usuario, sin duplicar el desarrollo.

¿Qué nivel de tráfico puede manejar?

En configuración pre-optimización: ~4,25 RPS sostenidos (~1M visitas/mes). Post quick-wins de configuración (2 semanas): ~6,5 RPS (+50%). Post-optimización completa: ~8,5 RPS (+100%). Todos los valores fueron certificados por el Senior TAM de Pressable en auditoría técnica de mayo 2026.

¿Cómo funciona la recuperación de cobros fallidos?

El sistema detecta automáticamente el evento de pago fallido vía webhook del procesador, ejecuta un flujo de reintento en ventanas configurables, notifica al usuario con CTA para actualizar su método de pago, y mantiene un período de gracia antes de la baja definitiva. Todo el ciclo es autónomo —no requiere intervención manual del equipo.

¿Tu empresa tiene suscriptores a escala y necesita una plataforma que no falle el día del pico? Agendá una sesión técnica con Bitobee y evaluamos juntos cómo migrar al sistema que ya está en producción para LPF Play.