Software de Captive Portal white label: o que os MSPs e revendedores devem verificar antes de assinar

O software de Captive Portal em white label permite que um MSP ou revendedor venda páginas de início de sessão de WiFi de convidados sob a sua própria marca. Antes de assinar contrato, confirme seis pontos: multi-tenancy real com administração delegada, personalização de marca no domínio, e-mail e relatórios, suporte para todos os fornecedores de pontos de acesso que instala, um modelo de faturação que proteja a sua margem, registos de consentimento do GDPR dos quais o seu cliente seja proprietário e APIs documentadas.

Que modelo de captive portal em white label deve escolher?

Um Captive Portal é a página web que um dispositivo vê antes de a rede conceder acesso à internet. A IETF estabelece a arquitetura na RFC 8952. A RFC 8908 define uma API que informa os dispositivos sobre a presença de um portal.

O software de Captive Portal em white label permite-lhe vender essa página de início de sessão sob a sua própria marca. A consola e os relatórios associados também apresentam a sua marca.

Três modelos comerciais dominam o mercado de revenda. Diferem em três pontos:

• quem detém o contrato com o cliente
• até onde se estende a sua marca
• quão bem isolados estão os dados de cada cliente

Escolha primeiro o modelo e, em seguida, avalie os fornecedores dentro desse modelo.

Modelo	A sua marca aparece em	Isolamento de dados do cliente	Quem detém o contrato com o cliente	Faturação típica	Indicado para
White label total, multi-tenant	Página de início de sessão, domínio personalizado, consola de administração, e-mails, SMS e relatórios	Tenant separado por cliente, com funções de administração e chaves de API delimitadas	A sua empresa	Grossista por local ou por ponto de acesso, a sua empresa define o preço de venda	MSPs com uma mesa de suporte e um portfólio de clientes com locais
Revendedor em co-branding	Apenas na página de início de sessão e nos e-mails; a consola e os relatórios mostram o fornecedor	Subcontas ou pastas dentro de uma conta partilhada	A sua empresa ou o fornecedor	Preço de tabela do fornecedor menos um desconto de revendedor	Revendedores que adicionam WiFi de convidados a uma venda de hardware
Recomendação ou contrato direto	Marca do fornecedor em todo o lado; a sua empresa aparece como instalador	Conta própria do cliente junto do fornecedor	O fornecedor	Preço de tabela do fornecedor; a sua empresa ganha uma comissão de recomendação ou receita de serviços	Parceiros que gerem projetos pontuais sem mesa de suporte

A maioria dos MSPs com uma mesa de suporte e vários clientes com locais opta pelo primeiro modelo. O resto deste guia pressupõe esse modelo e mostra-lhe como testar o que o fornecedor promete.

Onde as plataformas de captive portal em white label realmente diferem

Todas as demonstrações de fornecedores mostram uma página de início de sessão personalizada. As diferenças reais estão no fundo, em seis áreas. Em conjunto, elas determinam a sua margem, a sua exposição à conformidade legal e a sua carga de suporte.

Multi-tenancy real e administração delegada

Multi-tenancy real significa um cliente por tenant. Dados, definições, contas de administração e chaves de API estão isolados ao nível da plataforma. Uma pasta dentro de uma conta partilhada não é um tenant. Se uma função mal configurada expor a lista de convidados de um cliente a outro, a responsabilidade pela violação de dados é sua.

Teste a administração delegada num tenant de teste, não num slide. Precisa de pelo menos quatro funções:

• o seu próprio super admin
• um admin do cliente
• um gestor de espaço limitado a um local
• uma função de marketing apenas de leitura

Um diretor-geral de hotel deve ver o seu próprio hotel e nada mais.

Peça o início de sessão único através de SAML 2.0, o padrão OASIS para início de sessão federado. Deve funcionar com o Microsoft Entra ID, Okta e Google Workspace.

O SCIM 2.0 (System for Cross-domain Identity Management, RFC 7643 e RFC 7644) automatiza a criação e remoção de contas de administrador. Sem ele, um colaborador que saia da empresa do seu cliente mantém o acesso à consola até que alguém se lembre. Verifique se os registos de auditoria são mantidos por cliente (tenant) e se podem ser exportados, para que possa mostrar a um cliente quem alterou o quê.

Profundidade de personalização de marca: domínio, e-mail do remetente, portal e relatórios

A profundidade da marca é onde a maioria das promessas de "white label" falha. Avalie cada superfície que um convidado ou cliente possa ver:

• Domínio da página de início de sessão. O Captive Portal deve ser carregado a partir do seu domínio ou do domínio do seu cliente. O fornecedor deve renovar o seu certificado TLS automaticamente.
• Consola de administração. O seu logótipo, cores e URL pertencem ao ecrã de início de sessão. Uma consola com a marca do fornecedor diz exatamente ao seu cliente para quem ligar na hora da renovação.
• E-mail do remetente. Os códigos de verificação e os e-mails de marketing têm de ser enviados a partir do seu domínio. Isso exige SPF (RFC 7208), DKIM (RFC 6376) e DMARC (RFC 7489) alinhados com o seu domínio, caso contrário as mensagens vão para o spam.
• ID do remetente de SMS. As mensagens de texto de verificação devem mostrar o seu nome ou o do espaço, nunca o do fornecedor.
• Relatórios. As exportações agendadas e os painéis de controlo devem conter a sua marca, sem qualquer marca de água do fornecedor. Se revender WiFi Analytics, o relatório mensal é o produto que o seu cliente realmente vê.
• Ligações de ajuda e páginas de estado. As ligações da consola devem apontar para a sua base de conhecimento, ou para lado nenhum.

Os modelos por cliente também contam. Um grupo de bares e uma câmara municipal querem fluxos de início de sessão, textos de consentimento e idiomas diferentes.

Cobertura de hardware em toda a sua base instalada

Os seus clientes já possuem pontos de acesso, e raramente vêm de um único fornecedor. Peça a lista de equipamentos suportados por nome e por plataforma de gestão: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. "Todos os principais fornecedores" é um sinal de alerta, não uma resposta.

Suporte significa mais do que um simples redirecionamento. Para cada fornecedor, confirme quatro capacidades:

• redirecionamento para Captive Portal externo
• autenticação RADIUS (Remote Authentication Dial-In User Service, RFC 2865)
• contabilização RADIUS (RFC 2866) para dados de sessão
• configuração de walled garden para inícios de sessão sociais e de pagamento

Peça um guia de integração publicado para cada fornecedor. Depois, teste no firmware que os seus clientes usam na prática.

A cobertura de hardware também o protege durante os ciclos de atualização. Uma sobreposição na nuvem funciona no topo da rede, para que um cliente possa mudar de fornecedor de pontos de acesso sem alterar a experiência do convidado. Isto é fundamental para qualquer infraestrutura a avaliar o artigo Planning a WiFi 6 to WiFi 7 access point refresh when Cisco Meraki WiFi 6 reaches end of sale.

O Guest WiFi da Purple funciona como uma sobreposição em nuvem agnóstica de hardware em todos os oito fabricantes acima. O contexto está em Por que a sua próxima atualização de WiFi não precisa de novo hardware.

Alguns clientes vão querer mais do que acesso de convidados. Pergunte se a plataforma suporta 802.1X, o padrão IEEE para controlo de acesso à rede baseado em portas. Pergunte também sobre iPSK (identity pre-shared key), que dá a cada dispositivo ou pessoa a sua própria chave WiFi. Se adicionar acesso para funcionários, mantenha o Guia de IT empresarial para resolução de problemas de autenticação 802.1X no Windows 11 à mão.

O Passpoint, também chamado Hotspot 2.0, permite que os convidados recorrentes se voltem a ligar automaticamente sem um portal. O OpenRoaming, a federação da Wireless Broadband Alliance, faz o mesmo em todas as redes participantes. Uma plataforma sem estas tecnologias limita o que poderá vender mais tarde.

Registos de consentimento GDPR pertencentes ao seu cliente

Ao abrigo do GDPR, o seu cliente, o operador do local, é normalmente o responsável pelo tratamento dos dados dos convidados (Artigo 4.º, n.º 7). O parceiro atua como subcontratante, e o fornecedor da plataforma como seu subcontratante subsequente. O Artigo 28.º exige um contrato escrito em cada elo dessa cadeia. O Artigo 28.º, n.º 2, impede um subcontratante de recorrer a outro subcontratante sem a autorização prévia por escrito do responsável pelo tratamento.

O Artigo 7.º, n.º 1, exige que o responsável pelo tratamento demonstre o consentimento. Isso significa um registo completo por convidado:

• carimbo de data/hora
• o texto exato apresentado
• a versão do aviso de privacidade
• o canal
• as finalidades aceites

Uma marcação de "marketing consentido" não é suficiente. O Considerando 32 acrescenta que caixas pré-selecionadas não contam como consentimento. Para marketing por e-mail e SMS no Reino Unido, o consentimento também deve satisfazer os Privacy and Electronic Communications Regulations (PECR).

Verifique três pontos contratuais antes de assinar:

1. O fornecedor não reivindica a utilização dos dados dos convidados para fins próprios. Se o fizer, torna-se um responsável pelo tratamento, e o aviso de privacidade do seu cliente deve declará-lo.
2. O Artigo 28.º, n.º 3, alínea g), exige a devolução ou eliminação dos dados pessoais quando o contrato termina. Obtenha o formato de exportação, o prazo e o custo por escrito.
3. O fornecedor publica uma lista de subcontratantes subsequentes e notifica-o de alterações, para que possa passar essa notificação aos clientes.

A Purple integra adesões de escolha consciente no fluxo de início de sessão, para que cada convidado escolha ativamente o marketing. A Purple possui certificação ISO 27001 e conformidade com o GDPR.

Acesso a API e webhooks

As APIs decidem quanto do seu próprio serviço pode construir. Peça uma API REST documentada com chaves limitadas a um único cliente. Assim, uma chave comprometida não consegue aceder a todos os clientes. Endpoints em lote para clientes, locais e modelos de portal permitem-lhe criar scripts de integração em vez de ter de clicar manualmente.

Os webhooks enviam eventos, como o início de sessão de um convidado ou uma nova adesão, para o CRM do seu cliente à medida que acontecem. Verifique três coisas:

• os conteúdos são assinados, para que o recetor possa verificar o remetente
• as entregas com falha tentam novamente de forma automática
• os limites de taxa e qualquer custo extra pelo acesso à API são confirmados por escrito

Escalamento do suporte

Numa plataforma white label, você é o suporte de primeira linha. O local liga-lhe a si e o fornecedor nunca deve contactar o seu cliente diretamente. Isso torna o itinerário de segunda linha do fornecedor no seu termo de serviço mais importante.

Escreva o seguinte no contrato:

• níveis de gravidade definidos
• metas de resposta para cada nível
• um contacto do parceiro designado
• uma rota direta para a engenharia em caso de incidente de desativação do local (site-down)

O Artigo 33(2) exige que um subcontratante notifique o responsável pelo tratamento de uma violação sem demora injustificada. O contrato com o seu fornecedor deve dar-lhe uma notificação suficientemente rápida para cumprir esse dever perante o seu cliente.

Peça também provas de escala. A Purple geriu 440 milhões de sessões em 2024 em mais de 80 000 locais ativos em mais de 90 países (dados da própria Purple).

Quando uma plataforma white label totalmente multi-tenant é a decisão certa

Escolha o white label completo quando possui a relação com o cliente de ponta a ponta. Isso geralmente significa que três coisas são verdadeiras:

• opera uma service desk
• fatura os clientes mensalmente
• possui vários clientes de locais em diferentes setores

O WiFi de convidados torna-se assim uma linha recorrente na sua própria fatura.

Também se adequa a parques de hardware mistos. Uma plataforma agnóstica em relação ao hardware substitui várias consolas específicas de fornecedores. Os seus engenheiros aprendem um sistema e os relatórios de todos os clientes têm a mesma apresentação.

Cenário prático: um grupo hoteleiro regional com dois fornecedores de hardware

Situação. Um MSP geria o WiFi de convidados de um grupo regional de 14 hotéis. Nove hotéis utilizavam Cisco Meraki. Cinco hotéis, adquiridos no ano anterior, utilizavam Ruckus com 210 pontos de acesso entre eles. O Captive Portal pré-selecionado pelo MSP apenas suportava Meraki.

O que foi feito. O MSP alterou a sua seleção para plataformas agnósticas em relação ao hardware e realizou um piloto em dois hotéis cobrindo ambos os fornecedores. Criou um tenant para o grupo, com cada hotel a funcionar como um local. Os diretores-gerais receberam funções restritas ao local. O responsável de marketing do grupo recebeu acesso de leitura aos relatórios de todos os 14 hotéis.

Resultado (valores ilustrativos). Todos os 210 pontos de acesso Ruckus mantiveram-se em serviço em vez de serem substituídos. O grupo passou a ter um único design de início de sessão, um texto de consentimento único e um relatório mensal único para todas as propriedades.

Para saber mais sobre o setor, consulte Hotéis e WiFi em restaurantes: um guia do Reino Unido para cobertura e segurança.

Quando um contrato direto ou com co-branding é a decisão certa

O white label completo nem sempre compensa os custos de gestão. Pode vender o WiFi de convidados como um suplemento pontual para um projeto de hardware. Nesse caso, uma conta com co-branding ou de recomendação é mais simples, e evita o suporte de primeira linha para um produto que não deseja gerir.

Um contrato direto adequa-se a grandes clientes individuais com IT interno, como uma cadeia nacional de Comércio a retalho. A sua equipa de compras pode preferir contratar diretamente o fornecedor. Clientes em setores regulados, como a Saúde, também realizam frequentemente a sua própria garantia de fornecedores.

Continua a faturar com a instalação, gestão de rede e levantamentos no local (site surveys). O nosso Guia Prático de Planeamento de Levantamentos no Local para WiFi aborda todo esse trabalho de base.

Como é calculado o preço do software de portal cativo em marca branca

Existem três unidades de faturação dominantes: por local, por ponto de acesso e por convidado. A maioria dos fornecedores vende a preços de revenda e cabe a si definir o preço final ao cliente. A sua margem depende menos do desconto do que do alinhamento da sua unidade de faturação com a do fornecedor.

Modelo de faturação	Paga por	Previsibilidade de custos	Principal risco para si	Ideal para
Por local	Cada local, independentemente da dimensão	Elevada: só muda quando um local adere ou sai	Locais pequenos custam o mesmo que locais grandes	Cadeias de locais semelhantes: pubs, restaurantes de serviço rápido, comércio tradicional
Por ponto de acesso	Cada ponto de acesso gerido	Elevada: só muda com projetos de hardware	A densificação ou uma atualização para WiFi 7 adiciona licenças	Estádios, centros de conferências e outros locais com picos de afluência
Por convidado	Cada convidado autenticado por mês	Baixa: varia consoante a afluência	Picos de eventos geram faturas surpreendentes, salvo se houver um limite	Projetos-piloto, locais sazonais e locais com pouco tráfego

A estrutura mais segura fatura ao seu cliente na mesma unidade em que o fornecedor lhe fatura a si. Se pagar por ponto de acesso mas cobrar por local, cada projeto de densificação reduz a sua margem.

Antes de assinar, verifique mais quatro custos adicionais:

• prazos mínimos de fidelização
• cláusulas de atualização anual
• taxas de acesso à API ou instâncias adicionais
• verificação por SMS, que frequentemente fica fora da licença

Cenário prático: um centro de conferências com picos associados a eventos

Situação. Um revendedor apresentou uma proposta de WiFi para convidados num centro de conferências com 120 pontos de acesso. A afluência mensal variava entre cerca de 3 000 visitantes nos meses mais calmos e 45 000 durante uma grande feira comercial.

O que foi feito. O primeiro fornecedor cobrava por convidado. O revendedor simulou 12 meses de afluência e descobriu que o valor da fatura variava por um fator de 15. Mudou para um fornecedor que faturava por ponto de acesso e cobrou ao local uma taxa mensal fixa.

Resultado (valores ilustrativos). A linha de licenciamento manteve-se nos 120 pontos de acesso todos os meses, reduzindo a zero a variação mensal de custos. O local orçamentou um valor anual fixo. A margem do revendedor deixou de depender do calendário de eventos.

Como decidir para a sua rede: perguntas para RFP e sinais de alarme

Envie a todos os fornecedores pré-selecionados as mesmas perguntas e solicite respostas por escrito. Depois, confirme as mais importantes numa instância de teste.

Perguntas a incluir na RFP

1. Cada cliente é uma instância independente com dados, definições, contas de administrador e chaves de API isolados?
2. Que funções de administração existem e é possível restringir uma função a apenas um local?
3. Suportam autenticação única (SSO) SAML 2.0 com Microsoft Entra ID, Okta e Google Workspace, além de aprovisionamento SCIM?
4. O portal cativo, a consola, o e-mail de remetente, o ID do remetente de SMS e os relatórios podem ter todos a nossa marca?
5. Quem emite e renova os certificados TLS para domínios personalizados?
6. Quais são os fabricantes de pontos de acesso suportados e publicam um guia de integração para cada um?
7. Suportam autenticação e accounting RADIUS, 802.1X, iPSK, Passpoint e OpenRoaming?
8. Qual é a unidade de faturação, o prazo mínimo e o aumento anual?
9. Quanto cobram por SMS, acesso à API ou instâncias adicionais?
10. Utilizam os dados dos convidados para qualquer finalidade própria?
11. O que contém um registo de consentimento e em que formatos o nosso cliente o pode exportar?
12. Como e quando devolvem ou eliminam os dados no final do contrato?
13. Onde está a vossa lista de sub-encarregados do tratamento e como notificam as alterações?
14. Quais são os vossos níveis de gravidade e metas de resposta, e com que rapidez nos notificarão de uma violação?
15. Qual é o âmbito do vosso certificado ISO 27001?

Sinais de alerta que devem impedir a assinatura

Área	O que é um bom indicador	Sinal de alerta
Multitenancy	Instância separada por cliente com dados e chaves de API isolados	Os clientes estão em pastas dentro de uma conta partilhada
Imagem de marca	O seu domínio no portal, consola, e-mails, SMS e relatórios	Nome do fornecedor nos e-mails, URL da consola ou rodapés dos relatórios
Hardware	Fabricantes identificados, cada um com um guia de integração publicado	"Todos os principais fabricantes" sem uma lista detalhada
Faturação	A unidade de faturação corresponde à forma como cobra aos clientes, com aumento limitado	Preço por convidado sem limite, ou acesso à API apenas no nível mais elevado
Dados de convidados	O cliente é o responsável pelo tratamento; o fornecedor trata apenas mediante instrução	O fornecedor reserva-se o direito de utilizar ele próprio os dados dos convidados
Saída	Registos de consentimento exportados em CSV ou JSON num prazo acordado	Exportação apenas mediante pedido, mediante taxa ou num formato proprietário
Suporte	Níveis de gravidade, metas de resposta e um contacto de escalamento identificado	Apenas formulário de suporte, sem tempos de resposta definidos

Cenário prático: um município a mudar de revendedor

Situação. Um revendedor geria o WiFi de convidados para um município em 22 bibliotecas e centros desportivos. Na nova consulta de mercado, o município escolheu um fornecedor diferente. A sua equipa de eventos tinha o consentimento de cerca de 38 000 visitantes para receber atualizações.

O que foi feito. O contrato do revendedor com o fornecedor incluía uma cláusula de saída ao abrigo do Artigo 28.º(3)(g). A cláusula exigia uma exportação em JSON de cada registo de consentimento no prazo de 30 dias, com marca temporal, versão do texto e canal.

Resultado (valores ilustrativos). O município importou todos os 38 000 registos de consentimento para a sua nova plataforma. Continuou a enviar e-mails aos visitantes sem necessidade de uma campanha de pedido de novo consentimento. O revendedor cessou a prestação do serviço com a confirmação por escrito de que a sua cópia dos dados tinha sido eliminada.

Perguntas frequentes

O que é um Captive Portal white label?

Um Captive Portal white label é um software de início de sessão em WiFi de convidados que um MSP ou revendedor vende sob a sua própria marca. O fornecedor gere a plataforma, enquanto o seu logótipo, domínio, e-mail do remetente e relatórios estão visíveis para o cliente. As plataformas mais robustas incluem multitenancy real. Cada cliente fica assim alojado na sua própria instância isolada, com funções de administração delegadas para gestores do local e equipas de marketing.

Um MSP pode personalizar um Captive Portal com a sua própria marca?

Sim, desde que a plataforma ofereça personalização total de marca. A página de início de sessão deve carregar a partir do seu domínio com um certificado TLS válido. Os e-mails devem ser enviados a partir do seu domínio com alinhamento SPF, DKIM e DMARC. A consola de administração e os relatórios não devem conter qualquer referência ao fornecedor. Se a personalização de marca se ficar apenas pela página de início de sessão, o seu cliente continuará a ver o nome do fornecedor todos os meses.

Como é definido o preço do software de Captive Portal white label?

A maioria dos fornecedores cobra por local, por ponto de acesso ou por convidado, vendendo por grosso para que possa definir o preço de venda ao público. O modelo por local adequa-se a cadeias de espaços semelhantes. O modelo por ponto de acesso adequa-se a espaços com grandes picos de afluência. O modelo por convidado adequa-se a projetos piloto e locais com pouco tráfego, mas oscila consoante a procura. Para proteger a sua margem, meça a faturação ao seu cliente na mesma unidade em que o fornecedor lhe fatura a si.

Que pontos de acesso deve um portal white label suportar?

Deve suportar todos os fornecedores presentes na infraestrutura dos seus clientes, nomeados individualmente: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Para cada um deles, confirme o redirecionamento de Captive Portal externo, autenticação e accounting RADIUS e suporte para walled garden, sustentados por um guia de integração publicado. O Guest WiFi da Purple funciona em todos os oito como uma sobreposição na nuvem agnóstica em relação ao hardware.

Quem é o proprietário dos dados dos convidados numa plataforma de revendedor?

O seu cliente, o operador do espaço, deve ser o proprietário dos dados dos convidados como responsável pelo tratamento ao abrigo do GDPR. O revendedor atua como subcontratante e o fornecedor da plataforma como sub-subcontratante, cada um vinculado por um contrato ao abrigo do Artigo 28.º. Rejeite termos do fornecedor que lhe permitam utilizar os dados dos convidados para fins próprios. Os registos de consentimento devem ser exportados sob consulta e devolvidos ao seu cliente quando o contrato terminar.

Os clientes precisam de novo hardware para migrar para uma nova plataforma de Captive Portal?

Não, desde que a plataforma seja agnóstica em relação ao hardware. Uma sobreposição na nuvem liga-se aos pontos de acesso que o seu cliente já utiliza, recorrendo ao redirecionamento de Captive Portal externo e RADIUS. Reconfigura a rede para apontar para a nova plataforma em vez de substituir o equipamento. Teste nas versões de firmware que os seus clientes realmente utilizam antes de agendar a transição.

É possível migrar clientes existentes de outra plataforma de Captive Portal?

Sim, se o seu fornecedor atual exportar os registos de consentimento e os dados dos convidados de cada cliente num formato utilizável. Solicite uma exportação em CSV ou JSON com marca temporal, texto do consentimento e canal, citando o Artigo 28.º, n.º 3, alínea g) do GDPR. Reconstrua os modelos de portal no novo locatário e execute ambas as plataformas num espaço piloto. Em seguida, mude os restantes locais em lotes para limitar o risco.