O seu checkout não muda. O que muda é quem concede o acesso.

Sua página de vendas funciona. Seu checkout já converte. Seu tráfego está calibrado em cima dele. O que dói não é a venda — é o percentual que a plataforma de hospedagem tira de cada uma, todo mês, para servir vídeo.

A Mentorflix não pede para você mudar isso. Ela não substitui o seu gateway, não cria a sua página de vendas e não fica no meio do seu dinheiro. Você vende no Hotmart, no Kiwify, no Eduzz, no Monetizze, no Mercado Pago, no Stripe ou no seu próprio checkout. O dinheiro cai onde já cai hoje, no seu prazo, na sua conta, com a sua taxa de gateway.

O que entra aqui é o aviso da venda. O seu gateway dispara um webhook, a plataforma verifica a assinatura, resolve o que aquele produto libera e concede o acesso ao aluno. Um trilho para o dinheiro, outro para o acesso. A Mentorflix só existe no segundo.

A conta é um preço fixo de assinatura por mês, e nada por venda. Onde existe percentual dentro do produto — porque existe um — está escrito no fim desta página.

Cada integração ganha um endereço próprio: POST /api/webhooks/receive/<chave>. A chave identifica a integração e nada mais — ela sozinha não é o controle de segurança. O controle é a assinatura.

Cada provedor tem um leitor escrito para o formato dele, e cada leitor confere a assinatura do jeito que aquele provedor assina. Hotmart aceita as duas formas: o token estático no cabeçalho X-Hotmart-Hottok ou o HMAC-SHA256 em X-Hotmart-Signature. Kiwify assina em HMAC-SHA1 no cabeçalho X-Kiwify-Signature. Eduzz, em HMAC-SHA256. Monetizze não assina no cabeçalho: manda a chave compartilhada dentro do corpo, no campo chave, e a comparação é feita contra o segredo do endpoint. Stripe assina o par timestamp+corpo e a comparação aceita até 5 minutos de diferença de relógio. Mercado Pago monta o manifesto id;request-id;ts a partir dos cabeçalhos e do corpo, e aceita até 10 minutos. Toda comparação é feita em tempo constante, sobre o corpo cru, byte a byte, sem reserializar o JSON.

Quem não usa nenhum dos seis usa o recebedor genérico: você aponta, em notação de ponto, onde estão o e-mail, o nome, o id da transação, o nome do evento e o SKU dentro do seu JSON, e a assinatura é HMAC-SHA256 no cabeçalho que você escolher.

O contrato de resposta é deliberadamente chato: 200 para tudo — endpoint desconhecido, integração desligada, evento não mapeado, produto sem rota — e 401 só quando a assinatura não bate. Gateway nenhum entra em fila de reentrega porque um produto seu ainda não foi mapeado.

O aviso de venda chega com um ou mais ids de produto. Eles precisam virar conteúdo liberado. Entre os dois há o pacote.

Um pacote é montado por regras, não por lista fixa. A regra pode ser um curso, uma trilha ou uma categoria inteira. Cada regra inclui ou exclui, e a exclusão é aplicada depois da inclusão — ou seja, sempre ganha. Dá para vender “tudo de Marketing menos o intensivo” sem duplicar catálogo. A regra de categoria tem dois modos. Ligada em “incluir futuros”, ela é resolvida no momento da compra e devolve todos os cursos publicados naquela categoria: você lança um curso novo dentro dela e quem comprar depois já leva. Desligada, ela congela a lista de cursos no momento em que a regra foi criada e não muda mais.

O roteamento tem duas camadas. Com o mapa produto→pacote ligado, o id que veio no payload decide qual pacote liberar — um mesmo endpoint atende catálogo inteiro. Sem mapa, ou quando nenhum id casa com um mapeamento ativo, vale a associação fixa daquele endpoint. Se nada casar, o evento é registrado como sem rota, a compra fica gravada e nenhum acesso é concedido por engano.

O mesmo pacote alimenta a vitrine interna: uma oferta do tipo externa aponta para a sua própria URL de checkout e expande, na hora do clique, os marcadores {userId}, {email}, {name}, {bundleId} e {returnUrl}, cada um com escape de URL. O aluno sai daqui já identificado no seu gateway, e volta pelo mesmo caminho.

Há dois caminhos, e eles terminam diferente.

Quando a compra começa dentro da comunidade, o aluno clica na oferta, o seu checkout abre em outra aba e ele fica numa tela de espera. Essa tela pergunta ao servidor, a cada 4 segundos, se o acesso já saiu. Assim que o webhook do gateway chega e o acesso é concedido, a tela detecta e leva o aluno direto ao destino: o curso, se o pacote resolver para um só; a trilha, se resolver para uma só; a área de produtos, quando for entrega de vendedor. O polling pausa se a aba estiver em segundo plano e desiste depois de 20 minutos, oferecendo reabrir o checkout em vez de girar para sempre.

Quando a compra acontece fora — na sua página de vendas, no seu funil, no seu link de anúncio — o aluno nunca esteve logado aqui. O webhook chega com o e-mail dele. Se já existir conta com aquele e-mail na comunidade, o acesso é anexado à conta existente. Se não existir, a conta é criada na hora, com o nome que veio no payload e uma senha aleatória que ninguém conhece — inclusive nós.

E aqui vem o limite, dito sem rodeio: a plataforma não envia e-mail de boas-vindas nesse momento. Não existe disparo automático de credencial na liberação por webhook. O primeiro acesso é responsabilidade da sua comunicação: o e-mail que você já manda depois da compra, com o endereço da comunidade e a instrução de definir a senha em “esqueci minha senha”. O painel também gera o link de redefinição por aluno, e devolve esse link ao admin mesmo quando o envio de e-mail não está configurado, para você resolver um caso na mão.

O que acontece sozinho é o resto: além do curso e da trilha, o aluno entra automaticamente nos espaços privados vinculados àquele curso cujo vínculo esteja ativo e com liberação automática ligada. A entrada fica marcada com a origem — o acesso ao curso que a produziu — e o aluno recebe uma notificação dentro da plataforma avisando do novo espaço.

Cada liberação carrega três marcas: a origem (webhook), qual integração a produziu e o id da transação no gateway.

Quando o evento de reembolso, cancelamento, chargeback ou fim de assinatura chega, o sistema desativa apenas os acessos que aquela integração concedeu — a consulta filtra por origem e por id do endpoint antes de mudar qualquer linha. Acesso que você deu na mão, ou que veio de outro pacote, não é tocado. A compra fica gravada com o estado certo, derivado do nome do evento: chargeback, cancelado, expirado ou reembolsado.

Acesso com prazo tem um verificador horário: uma rotina percorre os acessos de curso e de trilha que já venceram, muda o estado para expirado e dispara a saída dos espaços vinculados que estiverem configurados para isso. Quem preenche esse prazo, hoje, é o leitor do Hotmart, que lê a data da próxima cobrança da assinatura e a grava como validade do acesso. Os outros seis leitores não extraem data de expiração do payload — neles a validade fica em branco e o acesso não expira sozinho.

Evento repetido não vira acesso duplicado. A chave é provedor + transação + tipo de evento, protegida por uma trava do Postgres dentro da transação e por uma restrição de unicidade no banco: reenvio do gateway responde 200 e não faz nada duas vezes.

Quando algo falha, o evento fica registrado inteiro. Cada evento vira um registro com o payload completo, o estado, o e-mail, o id da transação, se a assinatura conferiu, os cabeçalhos filtrados por uma allowlist e quanto tempo o processamento levou — pesquisável pelo id da transação. Dá para reprocessar um evento antigo com um clique, depois de corrigir o mapa. Dá para disparar um evento de teste, escolhendo o tipo e o e-mail de destino, antes de anunciar. Dá para ligar o modo sandbox, que registra tudo e não concede nada. E há um painel de saúde por integração: eventos nas últimas 24 horas, taxa de erro, latência p95 e último evento recebido, com a integração marcada como degradada quando a taxa de erro passa do tolerado e como fora quando a maior parte dos eventos falha.

Existe um percentual no produto. Ele não toca a sua venda.

Ele vive no marketplace: quando um membro da sua comunidade vende algo para outro membro, o pagamento passa por dentro, com conta de vendedor no Stripe Connect. Nesse caso, e só nesse, a plataforma retém uma fatia do bruto e a sua comunidade fica com a comissão que você definir, dentro do limite que o sistema aceita. O vendedor absorve a taxa do Stripe. Oferta de serviço entra em retenção até a confirmação do comprador, com disputa arbitrada por você. É outro fluxo, outro tipo de oferta e outro código: quando a venda é externa, o sistema apenas expande a URL do seu checkout e nenhuma venda interna é criada.

Agora o que a plataforma não faz, para você não descobrir depois.

Ela não processa pagamento na sua venda. Não gera cobrança, não parcela, não cobra recorrência, não faz split, não emite nota fiscal e não trata a parte financeira de um chargeback — isso continua com o seu gateway.

Ela não recupera venda. Não há régua de carrinho abandonado nem cobrança de assinatura vencida; o que existe é a leitura do que o seu gateway decidir avisar.

Ela não relata faturamento. Cada compra fica registrada com valor, moeda e estado, e aparece na ficha do aluno. Não há painel de receita: a analítica da plataforma cobre crescimento, engajamento, retenção, conteúdo e gamificação, não vendas.

A compra dentro da comunidade exige conta. A vitrine de cursos pode ser exibida para visitante, conforme o modo de visitante configurado na comunidade, mas o catálogo de ofertas e o botão de checkout exigem usuário identificado — quem compra pelo seu funil externo não tem esse limite.

E uma configuração que a gente não vai fingir que é automática: uma integração sem segredo de assinatura configurado passa a aceitar eventos sem verificação, e isso fica registrado no log do evento. O passo de gerar o segredo e colá-lo no painel do gateway é seu, e é o passo que importa.