Tu checkout no cambia. Lo que cambia es quién concede el acceso.

Tu página de ventas funciona. Tu checkout ya convierte. Tu tráfico está calibrado sobre él. Lo que duele no es la venta — es el porcentaje que la plataforma de hospedaje saca de cada una, todos los meses, para servir video.

Mentorflix no te pide que cambies eso. No sustituye tu gateway, no crea tu página de ventas y no se mete en medio de tu dinero. Vendes en Hotmart, en Kiwify, en Eduzz, en Monetizze, en Mercado Pago, en Stripe o en tu propio checkout. El dinero cae donde ya cae hoy, en tu plazo, en tu cuenta, con tu tasa de gateway.

Lo que entra aquí es el aviso de la venta. Tu gateway dispara un webhook, la plataforma verifica la firma, resuelve lo que ese producto libera y concede el acceso al alumno. Un riel para el dinero, otro para el acceso. Mentorflix solo existe en el segundo.

La cuenta es un precio fijo de suscripción al mes, y nada por venta. Dónde existe porcentaje dentro del producto — porque existe uno — está escrito al final de esta página.

Cada integración recibe una dirección propia: POST /api/webhooks/receive/<clave>. La clave identifica la integración y nada más — ella sola no es el control de seguridad. El control es la firma.

Cada proveedor tiene un lector escrito para su formato, y cada lector verifica la firma del modo en que ese proveedor firma. Hotmart acepta las dos formas: el token estático en el encabezado X-Hotmart-Hottok o el HMAC-SHA256 en X-Hotmart-Signature. Kiwify firma en HMAC-SHA1 en el encabezado X-Kiwify-Signature. Eduzz, en HMAC-SHA256. Monetizze no firma en el encabezado: envía la clave compartida dentro del cuerpo, en el campo chave, y la comparación se hace contra el secreto del endpoint. Stripe firma el par timestamp+cuerpo y la comparación acepta hasta 5 minutos de diferencia de reloj. Mercado Pago arma el manifiesto id;request-id;ts a partir de los encabezados y del cuerpo, y acepta hasta 10 minutos. Toda comparación se hace en tiempo constante, sobre el cuerpo crudo, byte a byte, sin reserializar el JSON.

Quien no usa ninguno de los seis usa el receptor genérico: indicas, en notación de punto, dónde están el correo, el nombre, el id de la transacción, el nombre del evento y el SKU dentro de tu JSON, y la firma es HMAC-SHA256 en el encabezado que elijas.

El contrato de respuesta es deliberadamente aburrido: 200 para todo — endpoint desconocido, integración apagada, evento no mapeado, producto sin ruta — y 401 solo cuando la firma no coincide. Ningún gateway entra en cola de reenvío porque un producto tuyo todavía no fue mapeado.

El aviso de venta llega con uno o más ids de producto. Necesitan convertirse en contenido liberado. Entre los dos está el paquete.

Un paquete se arma por reglas, no por lista fija. La regla puede ser un curso, una ruta o una categoría entera. Cada regla incluye o excluye, y la exclusión se aplica después de la inclusión — es decir, siempre gana. Se puede vender “todo de Marketing menos el intensivo” sin duplicar catálogo. La regla de categoría tiene dos modos. Activada en “incluir futuros”, se resuelve en el momento de la compra y devuelve todos los cursos publicados en esa categoría: lanzas un curso nuevo dentro de ella y quien compre después ya se lo lleva. Desactivada, congela la lista de cursos en el momento en que la regla fue creada y no cambia más.

El enrutamiento tiene dos capas. Con el mapa producto→paquete activado, el id que llegó en el payload decide qué paquete liberar — un mismo endpoint atiende todo el catálogo. Sin mapa, o cuando ningún id coincide con un mapeo activo, vale la asociación fija de ese endpoint. Si nada coincide, el evento se registra como sin ruta, la compra queda grabada y ningún acceso se concede por error.

El mismo paquete alimenta la vitrina interna: una oferta del tipo externa apunta a tu propia URL de checkout y expande, en el momento del clic, los marcadores {userId}, {email}, {name}, {bundleId} y {returnUrl}, cada uno con escape de URL. El alumno sale de aquí ya identificado en tu gateway, y vuelve por el mismo camino.

Hay dos caminos, y terminan diferente.

Cuando la compra empieza dentro de la comunidad, el alumno hace clic en la oferta, tu checkout abre en otra pestaña y él queda en una pantalla de espera. Esa pantalla le pregunta al servidor, cada 4 segundos, si el acceso ya salió. En cuanto el webhook del gateway llega y el acceso se concede, la pantalla lo detecta y lleva al alumno directo al destino: el curso, si el paquete resuelve a uno solo; la ruta, si resuelve a una sola; el área de productos, cuando es entrega de vendedor. El polling se pausa si la pestaña está en segundo plano y desiste después de 20 minutos, ofreciendo reabrir el checkout en vez de girar para siempre.

Cuando la compra ocurre fuera — en tu página de ventas, en tu embudo, en tu link de anuncio — el alumno nunca inició sesión aquí. El webhook llega con su correo. Si ya existe una cuenta con ese correo en la comunidad, el acceso se anexa a la cuenta existente. Si no existe, la cuenta se crea en el momento, con el nombre que llegó en el payload y una contraseña aleatoria que nadie conoce — nosotros incluidos.

Y aquí viene el límite, dicho sin rodeos: la plataforma no envía correo de bienvenida en ese momento. No existe disparo automático de credencial en la liberación por webhook. El primer acceso es responsabilidad de tu comunicación: el correo que ya envías después de la compra, con la dirección de la comunidad y la instrucción de definir la contraseña en “olvidé mi contraseña”. El panel también genera el enlace de restablecimiento por alumno, y devuelve ese enlace al admin incluso cuando el envío de correo no está configurado, para que resuelvas un caso a mano.

Lo que sucede solo es el resto: además del curso y de la ruta, el alumno entra automáticamente en los espacios privados vinculados a ese curso cuyo vínculo esté activo y con liberación automática encendida. La entrada queda marcada con el origen — el acceso al curso que la produjo — y el alumno recibe una notificación dentro de la plataforma avisando del nuevo espacio.

Cada liberación lleva tres marcas: el origen (webhook), qué integración la produjo y el id de la transacción en el gateway.

Cuando llega el evento de reembolso, cancelación, contracargo o fin de suscripción, el sistema desactiva solo los accesos que esa integración concedió — la consulta filtra por origen y por id del endpoint antes de cambiar cualquier fila. Acceso que diste a mano, o que vino de otro paquete, no se toca. La compra queda grabada con el estado correcto, derivado del nombre del evento: contracargo, cancelado, expirado o reembolsado.

Acceso con plazo tiene un verificador horario: una rutina recorre los accesos de curso y de ruta que ya vencieron, cambia el estado a expirado y dispara la salida de los espacios vinculados que estén configurados para eso. Quien llena ese plazo, hoy, es el lector de Hotmart, que lee la fecha del próximo cobro de la suscripción y la graba como vigencia del acceso. Los otros seis lectores no extraen fecha de expiración del payload — en ellos la vigencia queda en blanco y el acceso no expira solo.

Evento repetido no se vuelve acceso duplicado. La clave es proveedor + transacción + tipo de evento, protegida por un bloqueo de Postgres dentro de la transacción y por una restricción de unicidad en la base: el reenvío del gateway responde 200 y no hace nada dos veces.

Cuando algo falla, el evento queda registrado entero. Cada evento se vuelve un registro con el payload completo, el estado, el correo, el id de la transacción, si la firma coincidió, los encabezados filtrados por una allowlist y cuánto tiempo tardó el procesamiento — buscable por el id de la transacción. Se puede reprocesar un evento antiguo con un clic, después de corregir el mapa. Se puede disparar un evento de prueba, eligiendo el tipo y el correo de destino, antes de anunciar. Se puede activar el modo sandbox, que registra todo y no concede nada. Y hay un panel de salud por integración: eventos en las últimas 24 horas, tasa de error, latencia p95 y último evento recibido, con la integración marcada como degradada cuando la tasa de error supera lo tolerado y como caída cuando la mayor parte de los eventos falla.

Existe un porcentaje en el producto. No toca tu venta.

Vive en el marketplace: cuando un miembro de tu comunidad le vende algo a otro miembro, el pago pasa por dentro, con cuenta de vendedor en Stripe Connect. En ese caso, y solo en ese, la plataforma retiene una porción del bruto y tu comunidad se queda con la comisión que definas, dentro del límite que el sistema acepta. El vendedor absorbe la tasa de Stripe. La oferta de servicio entra en retención hasta la confirmación del comprador, con disputa arbitrada por ti. Es otro flujo, otro tipo de oferta y otro código: cuando la venta es externa, el sistema solo expande la URL de tu checkout y no se crea ninguna venta interna.

Ahora lo que la plataforma no hace, para que no lo descubras después.

No procesa pagos en tu venta. No genera cobro, no fracciona en cuotas, no cobra recurrencia, no hace split, no emite factura y no gestiona la parte financiera de un contracargo — eso sigue con tu gateway.

No recupera ventas. No hay regla de carrito abandonado ni cobro de suscripción vencida; lo que existe es la lectura de lo que tu gateway decida avisar.

No reporta facturación. Cada compra queda registrada con valor, moneda y estado, y aparece en la ficha del alumno. No hay panel de ingresos: la analítica de la plataforma cubre crecimiento, engagement, retención, contenido y gamificación, no ventas.

La compra dentro de la comunidad exige cuenta. La vitrina de cursos puede mostrarse a visitantes, según el modo de visitante configurado en la comunidad, pero el catálogo de ofertas y el botón de checkout exigen usuario identificado — quien compra por tu embudo externo no tiene ese límite.

Y una configuración que no vamos a fingir que es automática: una integración sin secreto de firma configurado pasa a aceptar eventos sin verificación, y eso queda registrado en el log del evento. El paso de generar el secreto y pegarlo en el panel del gateway es tuyo, y es el paso que importa.