Por qué. Cada socio tiene cortes y horas de cabina del plan del mes, más créditos sueltos que no vencen. Cada reserva descuenta primero del plan y después de los créditos, en una sola transacción, y deja una fila en el libro: renovación, crédito, consumo, uso de invitado o ajuste manual. Una reserva de cabina puede mezclar las dos cosas: horas de la cartera y el resto pago, y las horas se descuentan recién cuando MercadoPago aprueba el pago.

El costo. Las membresías vencen al leerlas, no con una tarea programada. El deploy queda simple, pero cada consulta que cuenta socios activos tiene que repetir el filtro por fecha de fin.

Por qué. Había socios que pagaban y se quedaban sin membresía porque el webhook rechazaba todos los avisos: el secreto de firma del servidor no era el de la integración. Ahora el webhook vuelve a leer cada pago o suscripción desde la API de MercadoPago, y una reconciliación busca las suscripciones por nuestra referencia (usuario y plan). Corre cuando el socio vuelve del checkout y desde un botón "Sincronizar MP" en el panel.

El costo. Un aviso con firma inválida se registra y se procesa igual. Uno falso sólo puede hacernos reprocesar datos nuestros, y eso es idempotente, pero es un control más débil que rechazarlo.

Por qué. El panel de admin dejó de renderizarse en el servidor. Sus páginas se prerenderizan y el middleware pide rol de admin antes de que carguen. Las páginas públicas se cachean un mes y el panel las invalida cuando el dueño guarda un cambio. Como las páginas ya no miran la sesión, cada handler de la API verifica sus propios permisos.

El costo. Los permisos se verifican dos veces, en el middleware y en el handler, y es más código para mantener a la par. Un cambio hecho por fuera del panel, directo en la base, no aparece en el sitio público hasta que vence el caché.