Upgrade self-service

Stripe checkout pendiente

La UI de /upgrade (app/upgrade/page.tsx) está mergeada y servida en producción. El handler GET /api/stripe/checkout no existe en el repo — bajo app/api/stripe/ solo hay webhook/. El botón “Elegir PROFESIONAL” apunta a /api/stripe/checkout?plan=pro (ver app/upgrade/page.tsx:253) y devuelve 404. Para activar el flow hace falta: implementar el handler + configurar STRIPE_PRICE_ID_PRO y STRIPE_PRICE_ID_ENTERPRISE en Workers Secrets. El webhook de ingreso (/api/stripe/webhook) ya está operativo con idempotencia (tabla stripe_processed_events).

TL;DR

/upgrade es la página pública de planes. Muestra los tres tiers (Esencial, Profesional, Enterprise) con precios anuales, features comparadas y CTAs. La página acepta ?expired=true para mostrar un banner cuando el plan del club venció.

Para comercial

• Problema que resuelve: dar de alta o upgradear un club sin necesidad de pasar por sales (Esencial y Profesional). Enterprise sigue por mail.
• Casos de uso típicos:
  • Club en período de prueba que decide comprar Esencial.
  • Club Esencial que llega al límite de 40 jugadores y necesita Profesional.
  • Club cuyo plan venció y vuelve desde el redirect /upgrade?expired=true.
• Diferenciador: precio anual sin permanencia, datos disponibles 5 años post-contrato (commitment público).

Planes y precios

Plan	Precio anual	Límite
Esencial	US$ 10.000	Hasta 30 jugadores (UI) — 40 en PLAN_LIMITS
Profesional	US$ 18.000	Jugadores ilimitados
Enterprise	Desde US$ 25.000	A medida del club

Los textos de features dentro de la página son la fuente de verdad pública. Para la matriz técnica de feature flags por plan, ver Planes.

Drift Esencial: 30 vs 40

La UI de /upgrade (app/upgrade/page.tsx:13,15) muestra “Hasta 30 jugadores”, pero el enforcement real lo hace lib/plans.ts con PLAN_LIMITS.esencial.athletes = 40. Hay que unificar: bajar el limit a 30 (más barato comercialmente) o subir el copy a 40. Hoy un cliente esencial puede cargar hasta 40 sin chocar el límite, pese a haber leído “30” al firmar.

Cómo lo usa el staff

Acceso y permisos

Página pública — accesible sin login. Si hay sesión activa, la página detecta el plan actual (user_profiles.plan) y marca “Tu plan actual” en la card correspondiente para evitar que el usuario compre lo mismo dos veces.

Flujos paso a paso

1. Visitante entra a /upgrade (directo, desde ?expired=true, o desde el footer del dashboard).
2. Ve las tres cards con precio, límite, features y CTA.
3. Click “Elegir PROFESIONAL” → /api/stripe/checkout?plan=pro (404 hoy: el handler no existe). Cuando se construya, debe redirigir a Stripe Checkout y, tras pago, a /upgrade/success (cancelación → /upgrade/cancel).
4. Enterprise: la CTA es mailto:r.mirandacostas18@gmail.com directo, no checkout.

Banner de plan vencido

Si la URL trae ?expired=true, se muestra un banner rojo: “Tu período de prueba venció. Elegí un plan para recuperar el acceso.” Este parámetro lo agrega el redirect del dashboard cuando detecta plan = 'expired'.

FAQ / casos límite

• Enterprise: la CTA es mailto: directo a ventas, no checkout.
• Plan vigente == card seleccionada: la card del plan actual muestra “Plan activo” en gris en vez de la CTA — evita que el usuario re-compre.
• Sin sesión: se muestran las cards sin “Tu plan actual”.

Cómo lo ve el jugador

Player surface: N/A. La página /upgrade está pensada para staff y leads; los jugadores no toman decisiones de billing.

Integraciones

• Stripe Checkout vía /api/stripe/checkout — handler inexistente (app/api/stripe/checkout/ no existe). Pendiente de implementación + config de STRIPE_PRICE_ID_*.
• Webhook Stripe (app/api/stripe/webhook/) ya operativo con idempotencia (tabla stripe_processed_events) — actualiza user_profiles.plan al recibir checkout.session.completed.
• Tabla user_profiles lee plan para personalizar la card “Tu plan actual”.

Limitaciones / roadmap

• Checkout no implementado: sin handler /api/stripe/checkout ni STRIPE_PRICE_ID_PRO / STRIPE_PRICE_ID_ENTERPRISE en Workers Secrets, el botón “Elegir” devuelve 404. Activación requiere construir el handler + config.
• Pro vs Enterprise: en código (lib/plans.ts) ambos planes tienen exactamente las mismas features. Si Enterprise va a justificar su upcharge con SSO, audit logs, soporte dedicado o white-label fase 2, requiere decisión de producto. La diferenciación de la página de /upgrade es solo de copy y precio.
• Features prometidas inexistentes: 7 features listadas (custom_dashboard, excel_export, ai_post_injury_analysis, ai_anomaly_detection, ai_natural_language_insights, wearables_integration, api_read) no están implementadas. Ver Planes para el detalle.