O que é um widget de venda de bilhetes embutido?

Quando um visitante quer comprar um bilhete, há duas opções: redirecioná-lo para o site da bilheteira ou mostrar o processo de compra embutido no seu próprio site. Esta decisão, aparentemente técnica, tem consequências de marca, de análise de dados e também legais: o checkout embutido é comércio eletrónico e aplicam-se-lhe três normas que convém conhecer antes de colar o script.

Que problemas tem redirecionar o utilizador para outro site?

Redirecionar o utilizador para outro site para concluir a compra tem custos ocultos.

• Fricção: cada clique adicional soma um ponto de abandono (ver como recuperar carrinhos abandonados)
• Desconfiança: saír do seu site gera dúvidas sobre segurança
• Perda de marca: o utilizador vê a marca da bilheteira, não a sua
• Tracking quebrado: perde visibilidade sobre o comportamento
• Experiência móvel: os redirects funcionam peor em dispositivos móveis, onde se concentra boa parte das compras a partir das redes sociais

Uma precisão sobre os números. O setor repete percentagens de abandono por clique e melhorias de conversão concretas, mas não encontrámos nenhum estudo público, com metodologia e amostra, que as sustente para a venda de bilhetes. Aqui não damos nenhuma: a direção do efeito é conhecida, a sua magnitude depende do seu tráfego, do seu evento e de como está feita a integração.

Que vantagens tem um widget embutido?

Um widget de venda integrado no seu site resolve todos estes problemas.

• Sem fricções: o utilizador não sai do seu site
• A sua marca: cores, tipografia e experiência coerente
• Melhor conversão: menos passos e menos saídas de domínio
• Tracking completo: vê todo o funil nas suas ferramentas de análise de dados
• Confiança: o utilizador permanece no domínio que conhece

Há uma vantagem menos citada e bastante concreta: a atribuição. Com redirect, a sessão muda de domínio e o evento de compra regista-se na propriedade da bilheteira, não na sua. Com o checkout embutido, a conversão ocorre no seu domínio e pode medi-la face às suas campanhas sem depender de relatórios de terceiros.

Que tipos de implementação existem?

Há diferentes formas de embutir a venda de bilhetes, com níveis de integração distintos.

• iFrame: a forma mais simples, insere o checkout numa frame
• Web component: mais flexível, adapta-se melhor ao design
• API + frontend próprio: controlo total, mais trabalho de desenvolvimento
• Popup/modal: abre a compra sem saída da página atual

A escolha não é apenas estética. O iFrame controla-se com a diretiva frame-ancestors da Content Security Policy, que, segundo o esboço de trabalho CSP Level 3 do W3C de 16 de setembro de 2026, «is used to control which origins may embed the current resource in a frame» (é usada para controlar quais as origens que podem incorporar o recurso atual numa frame). É o cabeçalho que o seu fornecedor deve permitir para que o checkout carregue dentro do seu domínio, e aquele que deve rever para que ninguém incorpore o seu site sem autorização.

Um aviso sobre posicionamento. A Google documenta que processa as aplicações JavaScript em três fases, «1. Crawling 2. Rendering 3. Indexing», com um Chromium sem interface que executa o código. Mesmo assim, convém que os dados que quer posicionar — nome do evento, data, recinto, preço a partir de — estejam no HTML da sua página e não só dentro do widget.

O que exige a lei espanhola ao botão de compra?

Esta é a parte que mais se descura, e a que pode invalidar uma venda. O artigo 98.2 do texto consolidado da Lei Geral para a Defesa dos Consumidores e Utilizadores é literal:

«Si la realización de un pedido se hace activando un botón o una función similar, estos deberán etiquetarse, de manera que sea fácilmente legible, únicamente con la expresión "pedido con obligación de pago" o una formulación análoga no ambigua que indique que la realización del pedido implica la obligación de realizar un pago al empresario. En caso contrario, el consumidor o usuario no quedará obligado por el contrato o pedido» (Se a realização de uma encomenda se fizer ativando um botão ou função semelhante, estes deverão ser identificados, de forma facilmente legível, unicamente com a expressão "encomenda com obrigação de pagamento" ou uma formulação análoga não ambígua que indique que a realização da encomenda implica a obrigação de efetuar um pagamento ao empresário. Caso contrário, o consumidor ou utilizador não ficará vinculado pelo contrato ou encomenda).

«Comprar», «Continuar» ou «Finalizar» isoladamente não são formulações não ambíguas. A consequência prevista na norma não é uma multa: é que o contrato não vincula o comprador.

O mesmo artigo acrescenta, pouco antes, outra obrigação: o empresário «pondrá en conocimiento de éste de una manera clara y destacada, y justo antes de que efectúe el pedido, la información establecida en el artículo 97.1.a), e), p) y q)» (dará a conhecer, de forma clara e destacada, e imediatamente antes de o consumidor efetuar a encomenda, a informação estabelecida no artigo 97.1.a), e), p) e q)). A alínea e) é o preço: «El precio total de los bienes o servicios, incluidos los impuestos y tasas (…) todos los gastos adicionales de transporte, entrega o postales y cualquier otro gasto» (O preço total dos bens ou serviços, incluindo impostos e taxas (…) todos os custos adicionais de transporte, entrega ou postais e qualquer outro custo). As taxas de gestão do bilhete não podem aparecer depois do clique.

E o número 3: «Los sitios web de comercio deberán indicar de modo claro y legible, a más tardar al inicio del procedimiento de compra, si se aplica alguna restricción de entrega y cuáles son las modalidades de pago aceptadas» (Os sites de comércio deverão indicar de forma clara e legível, no mais tardar no início do procedimento de compra, se se aplica alguma restrição de entrega e quais são as modalidades de pagamento aceites). Se o seu widget só aceita determinados métodos, isso diz-se no início, não no último passo.

Duas coisas que convém deixar acordadas por contrato com o fornecedor: quem controla o texto desse botão e quem o mantém se o fornecedor atualizar o seu checkout. Perante o comprador responde quem vende, e o artigo 97.8 do mesmo texto coloca o ónus da prova do cumprimento informativo sobre o empresário.

O widget de venda tem de ser acessível?

Sim, e desde há pouco com uma norma concreta por detrás. A Lei 11/2023, de 8 de maio, que transpõe a Diretiva (UE) 2019/882, inclui no seu artigo 2.2 a lista de serviços obrigados, e a alínea f) é sucinta: «Servicios de comercio electrónico» (Serviços de comércio eletrónico).

O artigo 3.1 remete para os requisitos do anexo I: «todos los servicios deberán cumplir los requisitos de accesibilidad universal que figuran en las secciones III y IV del anexo I» (todos os serviços deverão cumprir os requisitos de acessibilidade universal que figuram nas secções III e IV do anexo I). A única isenção geral está no artigo 3.3: «Las microempresas que presten servicios estarán exentas de cumplir los requisitos de accesibilidad» (As microempresas que prestem serviços estarão isentas de cumprir os requisitos de acessibilidade).

A data de corte aparece na própria lei: o artigo 2.4 deixa fora do âmbito os conteúdos multimédia pré-gravados e os formatos de ficheiro de ofimática «publicados antes del 28 de junio de 2025» (publicados antes de 28 de junho de 2025). O que for publicado ou atualizado depois, entra no âmbito.

O padrão técnico de referência para o cumprir são as Pautas de Acessibilidade para o Conteúdo Web. O WCAG 2.2 é Recomendação do W3C desde 12 de dezembro de 2024. Num checkout de bilhetes, o que mais costuma falhar é concreto: o foco do teclado que se perde ao entrar no iFrame, as mensagens de erro que só se assinalam com cor, o temporizador de reserva de lugar sem aviso nem prorrogação, e os mapas de lotação sem alternativa em lista. Pergunte ao fornecedor pela sua declaração de acessibilidade antes de assinar; o artigo 13.2 da Lei 11/2023 obriga o prestador a incluir essa informação «en las condiciones generales o documento equivalente» (nas condições gerais ou documento equivalente).

O que exige o PCI DSS à página de pagamento?

Se o widget renderiza o formulário de pagamento no seu domínio, a sua página entra no perímetro do padrão. O PCI Security Standards Council publicou o PCI DSS v4.0.1 em junho de 2024 e confirmou que essa revisão «does not impact the effective date of these new requirements» (não afeta a data de entrada em vigor destes novos requisitos): os requisitos diferidos, entre eles o 6.4.3 e o 11.6.1 sobre os scripts da página de pagamento, passaram a ser obrigatórios a 31 de março de 2025.

Na prática, estes dois requisitos pedem para inventariar e autorizar cada script executado na página de pagamento, justificar por que motivo está ali e detetar alterações não autorizadas nos cabeçalhos e no conteúdo. Traduzido para um site de eventos: o pixel de publicidade, o chat de suporte e o gestor de etiquetas que convivem com o checkout deixam de ser decisões de marketing e passam a ser decisões de segurança.

A forma mais simples de reduzir esse âmbito é que o campo do cartão esteja alojado num iFrame do fornecedor, não no seu HTML. Pergunte ao seu que modelo utiliza e que documento de conformidade entrega. O próprio padrão e os seus documentos estão no site do PCI Security Standards Council.

Quanto pode pesar o widget sem prejudicar os seus Core Web Vitals?

Um widget embutido é código de terceiros que é executado na sua página, e isso nota-se nas métricas que a Google usa como sinal. Os limiares estão publicados: segundo web.dev, o LCP «should occur within 2.5 seconds» (deve ocorrer dentro de 2,5 segundos), o CLS deve manter-se «0.1 or less» (0,1 ou menos) e as páginas «should have a INP of 200 milliseconds or less» (devem ter um INP de 200 milissegundos ou menos), tudo medido no percentil 75 dos carregamentos.

O detalhe do INP marca a fronteira superior: «An INP above 500 milliseconds means a page has poor responsiveness» (Um INP superior a 500 milissegundos significa que uma página tem uma capacidade de resposta deficiente). O INP mede a latência de todas as interações da visita, e um seletor de lugares ou um calendário de sessões é precisamente uma sucessão de interações.

Três medidas que funcionam sem tocar no fornecedor:

• Carregue o widget sob demanda, ao clicar em «Comprar bilhetes», em vez de no <head> de todas as páginas.
• Reserve a altura do contentor em CSS antes de carregar, para que o bloco não empurre o conteúdo e dispare o CLS.
• Meça com dados de campo, não só com um teste de laboratório: o percentil 75 de utilizadores reais é o que conta.

Como personalizar o widget com a sua marca?

O widget deve parecer parte do seu site, não um elemento estranho colado.

• Cores: adapte a paleta à sua identidade visual
• Tipografia: use as suas próprias fontes, se possível
• Logótipo: a sua marca visível durante todo o processo
• Mensagens: textos personalizados (botões, confirmações)

Um limite que convém conhecer: o contraste de cor não é negociável. Se a paleta da sua marca deixar um botão ou uma mensagem de erro abaixo do contraste mínimo do WCAG, o widget deixa de cumprir, mesmo que se pareça com o seu site. O mesmo se aplica ao texto do botão de compra: a personalização não pode sobrepor-se à fórmula do artigo 98.2 do TRLGDCU.

Lista de verificação antes de contratar um widget

Nove perguntas ao fornecedor, todas com resposta documental.

Posso editar o texto do botão de encomenda? Deve poder ler-se «encomenda com obrigação de pagamento» ou uma fórmula análoga não ambígua. Se o texto for fixo e ambíguo, o problema é seu, não do fornecedor.

Onde se mostra o preço total com as taxas de gestão? Tem de estar antes do clique de compra, não no resumo final.

Têm declaração de acessibilidade e resultado de auditoria WCAG? Pergunte pelo nível e pela data. O artigo 13.2 da Lei 11/2023 obriga a informar disso nas condições gerais.

O campo do cartão é renderizado no vosso domínio? Da resposta depende quanto âmbito de PCI DSS assume.

Que documento de conformidade PCI DSS entregam e de que data? Com os requisitos 6.4.3 e 11.6.1 já exigíveis desde 31 de março de 2025.

Que cabeçalhos frame-ancestors ou X-Frame-Options preciso de configurar? E em que domínios autorizam o embutimento.

Responsivo: o widget deve funcionar perfeitamente em dispositivos móveis. Teste-o com uma ligação lenta e com o teclado, não só com o rato.

Desempenho: não deve atrasar o carregamento da sua página. Peça o peso do script e verifique o LCP, o CLS e o INP com dados de campo antes e depois de o instalar.

SEO e leitores de ecrã: o widget não deve afetar negativamente o posicionamento e tem de ser utilizável com leitor de ecrã. Mantenha no seu HTML o nome do evento, a data, o recinto e o preço a partir de.

Conclusão

O widget embutido é quase sempre a melhor opção para vender bilhetes a partir do seu site. Mantém o utilizador no seu domínio, reforça a sua marca e devolve-lhe o controlo da medição. O esforço de implementação é mínimo em comparação com o benefício, mas não é apenas uma decisão técnica: o botão do artigo 98.2 do TRLGDCU, a acessibilidade da Lei 11/2023 e os requisitos do PCI DSS v4.0.1 exigíveis desde 31 de março de 2025 são condições de saída, não melhorias opcionais. Se o seu fornecedor de ticketing não oferecer um bom widget nem documentar estes três pontos, talvez seja o momento de procurar outro. Consulte a nossa comparação de plataformas de ticketing ou compare diretamente Futura Tickets vs Eventbrite.

Fontes

• Texto consolidado da Lei Geral para a Defesa dos Consumidores e Utilizadores, artigos 97 e 98 (RDL 1/2007, texto consolidado) — BOE
• Lei 11/2023, de 8 de maio, artigos 2, 3 e 13 (texto consolidado) — BOE
• Web Content Accessibility Guidelines (WCAG) 2.2, Recomendação de 12 de dezembro de 2024 — W3C
• Content Security Policy Level 3, esboço de trabalho de 16 de setembro de 2026 — W3C
• Just Published: PCI DSS v4.0.1 — PCI Security Standards Council
• PCI Security Standards Council: padrões e biblioteca de documentos — PCI SSC
• Web Vitals: limiares de LCP, INP e CLS — web.dev, Google
• Interaction to Next Paint (INP) — web.dev, Google
• Conceitos básicos do SEO para JavaScript — Google Search Central