Votre checkout ne change pas. Ce qui change, c’est qui accorde l’accès.

Votre page de vente fonctionne. Votre checkout convertit déjà. Votre trafic est calibré dessus. Ce qui fait mal, ce n’est pas la vente — c’est le pourcentage que la plateforme d’hébergement prélève sur chacune, chaque mois, pour servir la vidéo.

Mentorflix ne vous demande pas de changer ça. Elle ne remplace pas votre passerelle, ne crée pas votre page de vente et ne se place pas au milieu de votre argent. Vous vendez sur Hotmart, Kiwify, Eduzz, Monetizze, Mercado Pago, Stripe ou votre propre checkout. L’argent arrive là où il arrive déjà aujourd’hui, à votre échéance, sur votre compte, avec les frais de votre passerelle.

Ce qui entre ici, c’est l’avis de vente. Votre passerelle déclenche un webhook, la plateforme vérifie la signature, résout ce que ce produit libère et accorde l’accès à l’élève. Un rail pour l’argent, un autre pour l’accès. Mentorflix n’existe que sur le second.

Le calcul, c’est un prix fixe d’abonnement par mois, rien par vente. Où il existe un pourcentage à l’intérieur du produit — car il en existe un — c’est écrit à la fin de cette page.

Chaque intégration reçoit sa propre adresse : POST /api/webhooks/receive/<cle>. La clé identifie l’intégration et rien de plus — elle seule n’est pas le contrôle de sécurité. Le contrôle, c’est la signature.

Chaque fournisseur a un lecteur écrit pour son format, et chaque lecteur vérifie la signature à la façon dont ce fournisseur signe. Hotmart accepte les deux formes : le jeton statique dans l’en-tête X-Hotmart-Hottok ou le HMAC-SHA256 dans X-Hotmart-Signature. Kiwify signe en HMAC-SHA1 dans l’en-tête X-Kiwify-Signature. Eduzz, en HMAC-SHA256. Monetizze ne signe pas dans l’en-tête : il envoie la clé partagée dans le corps, dans le champ chave, et la comparaison se fait contre le secret de l’endpoint. Stripe signe la paire timestamp+corps et la comparaison accepte jusqu’à 5 minutes de décalage d’horloge. Mercado Pago compose le manifeste id;request-id;ts à partir des en-têtes et du corps, et accepte jusqu’à 10 minutes. Chaque comparaison se fait en temps constant, sur le corps brut, octet par octet, sans resérialiser le JSON.

Qui n’utilise aucun des six utilise le récepteur générique : vous indiquez, en notation par points, où se trouvent l’e-mail, le nom, l’id de la transaction, le nom de l’événement et le SKU dans votre JSON, et la signature est en HMAC-SHA256 dans l’en-tête que vous choisissez.

Le contrat de réponse est volontairement ennuyeux : 200 pour tout — endpoint inconnu, intégration désactivée, événement non mappé, produit sans route — et 401 seulement quand la signature ne correspond pas. Aucune passerelle n’entre en file de renvoi parce qu’un de vos produits n’a pas encore été mappé.

L’avis de vente arrive avec un ou plusieurs ids de produit. Ils doivent devenir du contenu libéré. Entre les deux, il y a le pack.

Un pack se construit par règles, pas par liste fixe. La règle peut être un cours, un parcours ou une catégorie entière. Chaque règle inclut ou exclut, et l’exclusion s’applique après l’inclusion — c’est-à-dire qu’elle gagne toujours. Vous pouvez vendre « tout Marketing sauf l’intensif » sans dupliquer le catalogue. La règle de catégorie a deux modes. Activée en « inclure les futurs », elle se résout au moment de l’achat et renvoie tous les cours publiés dans cette catégorie : vous lancez un nouveau cours dedans et qui achète ensuite l’obtient déjà. Désactivée, elle gèle la liste des cours au moment où la règle a été créée et ne change plus.

Le routage a deux couches. Avec la carte produit→pack activée, l’id venu dans le payload décide quel pack libérer — un seul endpoint sert tout le catalogue. Sans carte, ou quand aucun id ne correspond à un mappage actif, l’association fixe de cet endpoint s’applique. Si rien ne correspond, l’événement est enregistré comme sans route, l’achat reste consigné et aucun accès n’est accordé par erreur.

Le même pack alimente la vitrine interne : une offre de type externe pointe vers votre propre URL de checkout et développe, au moment du clic, les marqueurs {userId}, {email}, {name}, {bundleId} et {returnUrl}, chacun avec échappement d’URL. L’élève part d’ici déjà identifié sur votre passerelle, et revient par le même chemin.

Il y a deux chemins, et ils se terminent différemment.

Quand l’achat commence dans la communauté, l’élève clique sur l’offre, votre checkout s’ouvre dans un autre onglet et il se retrouve sur un écran d’attente. Cet écran demande au serveur, toutes les 4 secondes, si l’accès est déjà sorti. Dès que le webhook de la passerelle arrive et que l’accès est accordé, l’écran le détecte et emmène l’élève directement à destination : le cours, si le pack se résout à un seul ; le parcours, s’il se résout à un seul ; la zone de produits, quand c’est une livraison de vendeur. Le polling se met en pause si l’onglet est en arrière-plan et abandonne après 20 minutes, en proposant de rouvrir le checkout plutôt que de tourner indéfiniment.

Quand l’achat a lieu ailleurs — sur votre page de vente, dans votre tunnel, dans votre lien de publicité — l’élève ne s’est jamais connecté ici. Le webhook arrive avec son e-mail. Si un compte existe déjà avec cet e-mail dans la communauté, l’accès est rattaché au compte existant. S’il n’existe pas, le compte est créé sur-le-champ, avec le nom venu dans le payload et un mot de passe aléatoire que personne ne connaît — nous non plus.

Et voici la limite, dite sans détour : la plateforme n’envoie pas d’e-mail de bienvenue à ce moment-là. Il n’existe pas d’envoi automatique d’identifiants lors de la libération par webhook. Le premier accès relève de votre propre communication : l’e-mail que vous envoyez déjà après l’achat, avec l’adresse de la communauté et l’instruction de définir le mot de passe via « mot de passe oublié ». Le tableau de bord génère aussi le lien de réinitialisation par élève, et le renvoie à l’admin même quand l’envoi d’e-mail n’est pas configuré, pour que vous régliez un cas à la main.

Ce qui se passe seul, c’est le reste : au-delà du cours et du parcours, l’élève entre automatiquement dans les espaces privés liés à ce cours dont le lien est actif et la libération automatique activée. L’entrée est marquée avec son origine — l’accès au cours qui l’a produite — et l’élève reçoit une notification dans la plateforme l’informant du nouvel espace.

Chaque libération porte trois marques : l’origine (webhook), quelle intégration l’a produite, et l’id de la transaction sur la passerelle.

Quand l’événement de remboursement, annulation, rétrofacturation ou fin d’abonnement arrive, le système désactive uniquement les accès que cette intégration a accordés — la requête filtre par origine et par id d’endpoint avant de modifier la moindre ligne. L’accès que vous avez donné à la main, ou qui vient d’un autre pack, n’est pas touché. L’achat reste consigné avec le bon état, dérivé du nom de l’événement : rétrofacturation, annulé, expiré ou remboursé.

L’accès à durée limitée a un vérificateur horaire : une routine parcourt les accès de cours et de parcours déjà arrivés à échéance, change l’état en expiré et déclenche la sortie des espaces liés configurés pour ça. Qui renseigne cette échéance, aujourd’hui, c’est le lecteur Hotmart, qui lit la date de la prochaine facturation de l’abonnement et l’enregistre comme validité de l’accès. Les six autres lecteurs n’extraient pas de date d’expiration du payload — chez eux, la validité reste vide et l’accès n’expire pas seul.

Un événement répété ne devient pas un accès dupliqué. La clé est fournisseur + transaction + type d’événement, protégée par un verrou Postgres à l’intérieur de la transaction et par une contrainte d’unicité en base : un renvoi de la passerelle répond 200 et ne fait rien deux fois.

Quand quelque chose échoue, l’événement reste enregistré en entier. Chaque événement devient un registre avec le payload complet, l’état, l’e-mail, l’id de la transaction, si la signature a été vérifiée, les en-têtes filtrés par une liste blanche et le temps qu’a pris le traitement — recherchable par l’id de la transaction. Vous pouvez retraiter un ancien événement en un clic, après avoir corrigé la carte. Vous pouvez déclencher un événement de test, en choisissant le type et l’e-mail de destination, avant d’annoncer. Vous pouvez activer le mode sandbox, qui enregistre tout et n’accorde rien. Et il existe un tableau de santé par intégration : événements des dernières 24 heures, taux d’erreur, latence p95 et dernier événement reçu, avec l’intégration marquée comme dégradée quand le taux d’erreur dépasse le seuil toléré, et comme hors service quand la majorité des événements échoue.

Il existe un pourcentage dans le produit. Il ne touche pas votre vente.

Il vit dans le marketplace : quand un membre de votre communauté vend quelque chose à un autre membre, le paiement passe par l’intérieur, avec un compte vendeur sur Stripe Connect. Dans ce cas, et seulement dans ce cas, la plateforme retient une part du brut et votre communauté garde la commission que vous définissez, dans la limite que le système accepte. Le vendeur absorbe les frais Stripe. L’offre de service entre en retenue jusqu’à la confirmation de l’acheteur, avec un litige arbitré par vous. C’est un autre flux, un autre type d’offre et un autre code : quand la vente est externe, le système se contente de développer l’URL de votre checkout et aucune vente interne n’est créée.

Voici maintenant ce que la plateforme ne fait pas, pour que vous ne le découvriez pas plus tard.

Elle ne traite pas le paiement de votre vente. Elle ne génère pas de facture, ne fractionne pas en plusieurs fois, ne prélève pas de récurrence, ne fait pas de répartition (split), n’émet pas de facture fiscale et ne traite pas le volet financier d’une rétrofacturation — cela reste du côté de votre passerelle.

Elle ne récupère pas de vente. Il n’y a pas de relance de panier abandonné ni de prélèvement d’abonnement échu ; ce qui existe, c’est la lecture de ce que votre passerelle décide de signaler.

Elle ne rapporte pas de chiffre d’affaires. Chaque achat est consigné avec montant, devise et état, et apparaît dans la fiche de l’élève. Il n’y a pas de tableau de revenus : l’analytique de la plateforme couvre croissance, engagement, rétention, contenu et gamification, pas les ventes.

L’achat à l’intérieur de la communauté exige un compte. La vitrine de cours peut être affichée aux visiteurs, selon le mode visiteur configuré dans la communauté, mais le catalogue d’offres et le bouton de checkout exigent un utilisateur identifié — qui achète via votre tunnel externe n’a pas cette limite.

Et un réglage que nous n’allons pas prétendre automatique : une intégration sans secret de signature configuré se met à accepter des événements sans vérification, et cela reste enregistré dans le journal de l’événement. L’étape de générer le secret et de le coller dans le tableau de bord de la passerelle est la vôtre, et c’est l’étape qui compte.