Cuando un visitante quiere comprar una entrada, hay dos opciones: redirigirlo a la web de la ticketera o mostrar el proceso de compra embebido en tu propia web. Esta decisión, aparentemente técnica, tiene consecuencias de marca, de analítica y también legales: el checkout embebido es comercio electrónico y le aplican tres normas que conviene conocer antes de pegar el script.
¿Qué problemas tiene redirigir al usuario a otra web?
Redirigir al usuario a otra web para completar la compra tiene costes ocultos.
- Fricción: cada clic adicional añade un punto de abandono (ver cómo recuperar carritos abandonados)
- Desconfianza: salir de tu web genera dudas sobre seguridad
- Pérdida de marca: el usuario ve la marca de la ticketera, no la tuya
- Tracking roto: pierdes visibilidad sobre el comportamiento
- Experiencia móvil: los redirects funcionan peor en móvil, donde se concentra buena parte de las compras desde redes sociales
Una precisión sobre las cifras. El sector repite porcentajes de abandono por clic y mejoras de conversión concretas, pero no hemos encontrado un estudio público, con metodología y muestra, que los sostenga para la venta de entradas. Aquí no damos ninguno: la dirección del efecto es conocida, su magnitud depende de tu tráfico, de tu evento y de cómo esté hecha la integración.
¿Qué ventajas tiene un widget embebido?
Un widget de venta integrado en tu web resuelve todos estos problemas.
- Sin fricciones: el usuario no sale de tu web
- Tu marca: colores, tipografía y experiencia coherente
- Mejor conversión: menos pasos y menos salidas de dominio
- Tracking completo: ves todo el funnel en tus herramientas de análisis de datos
- Confianza: el usuario permanece en el dominio que conoce
Hay una ventaja menos citada y bastante concreta: la atribución. Con redirect, la sesión cambia de dominio y el evento de compra se registra en la propiedad de la ticketera, no en la tuya. Con el checkout embebido, la conversión ocurre en tu dominio y puedes medirla contra tus campañas sin depender de informes de terceros.
¿Qué tipos de implementación existen?
Hay diferentes formas de embeber la venta de entradas, con distintos niveles de integración.
- iFrame: la forma más simple, inserta el checkout en un frame
- Web component: más flexible, se adapta mejor al diseño
- API + frontend propio: control total, más trabajo de desarrollo
- Popup/modal: abre la compra sin salir de la página actual
| Modalidad | Esfuerzo de desarrollo | Control del diseño | Dónde vive el pago |
|---|---|---|---|
| iFrame | Bajo | Limitado al tema del proveedor | En el dominio del proveedor |
| Web component | Medio | Alto, con CSS propio | En el dominio del proveedor |
| API + frontend propio | Alto | Total | En tu dominio, salvo que delegues el campo de tarjeta |
| Popup o modal | Bajo | Medio | En el dominio del proveedor |
La elección no es solo estética. El iFrame se controla con la directiva frame-ancestors de Content Security Policy, que, según el borrador de trabajo CSP Level 3 del W3C de 16 de septiembre de 2026, «is used to control which origins may embed the current resource in a frame». Es la cabecera que tu proveedor debe permitir para que su checkout cargue dentro de tu dominio, y la que tú debes revisar para que nadie embeba tu web sin permiso.
Un aviso de posicionamiento. Google documenta que procesa las aplicaciones JavaScript en tres fases, «1. Crawling 2. Rendering 3. Indexing», con un Chromium sin interfaz que ejecuta el código. Aun así, conviene que los datos que quieres posicionar —nombre del evento, fecha, recinto, precio desde— estén en el HTML de tu página y no solo dentro del widget.
¿Qué exige la ley española al botón de compra?
Esta es la parte que más se pasa por alto, y la que puede dejar sin efecto una venta. El artículo 98.2 del texto refundido de la Ley General para la Defensa de los Consumidores y Usuarios es 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».
«Comprar», «Continuar» o «Finalizar» a secas no son formulaciones no ambiguas. La consecuencia que marca la norma no es una multa: es que el contrato no vincula al comprador.
El mismo artículo añade, justo antes, otra obligación: el empresario «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)». La letra e) es el precio: «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». Los gastos de gestión de la entrada no pueden aparecer después del clic.
Y el apartado 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». Si tu widget solo acepta ciertos métodos, se dice al principio, no en el último paso.
Dos cosas que conviene dejar atadas por contrato con el proveedor: quién controla el texto de ese botón y quién lo mantiene si el proveedor actualiza su checkout. Ante el comprador responde quien vende, y el artículo 97.8 del mismo texto coloca la carga de la prueba del cumplimiento informativo en el empresario.
¿Tiene que ser accesible el widget de venta?
Sí, y desde hace poco con una norma concreta detrás. La Ley 11/2023, de 8 de mayo, que traspone la Directiva (UE) 2019/882, incluye en su artículo 2.2 la lista de servicios obligados, y la letra f) es escueta: «Servicios de comercio electrónico».
El artículo 3.1 remite a los requisitos del anexo I: «todos los servicios deberán cumplir los requisitos de accesibilidad universal que figuran en las secciones III y IV del anexo I». La única exención general está en el artículo 3.3: «Las microempresas que presten servicios estarán exentas de cumplir los requisitos de accesibilidad».
La fecha de corte aparece en la propia ley: el artículo 2.4 deja fuera del ámbito los contenidos multimedia pregrabados y los formatos de archivo de ofimática «publicados antes del 28 de junio de 2025». Lo que se publique o actualice después, dentro.
El estándar técnico de referencia para cumplirlo son las Pautas de Accesibilidad para el Contenido Web. WCAG 2.2 es Recomendación del W3C desde el 12 de diciembre de 2024. En un checkout de entradas, lo que más suele fallar es concreto: el foco del teclado que se pierde al entrar en el iFrame, los mensajes de error que solo se señalan con color, el temporizador de reserva de butaca sin aviso ni prórroga, y los mapas de aforo sin alternativa en lista. Pide al proveedor su declaración de accesibilidad antes de firmar; el artículo 13.2 de la Ley 11/2023 obliga al prestador a incluir esa información «en las condiciones generales o documento equivalente».
¿Qué exige PCI DSS a la página de pago?
Si el widget pinta el formulario de pago en tu dominio, tu página entra en el perímetro del estándar. El PCI Security Standards Council publicó PCI DSS v4.0.1 en junio de 2024 y confirmó que esa revisión «does not impact the effective date of these new requirements»: los requisitos aplazados, entre ellos el 6.4.3 y el 11.6.1 sobre los scripts de la página de pago, pasaron a ser obligatorios el 31 de marzo de 2025.
En la práctica, esos dos requisitos piden inventariar y autorizar cada script que se ejecuta en la página de pago, justificar por qué está ahí y detectar cambios no autorizados en las cabeceras y en el contenido. Traducido a una web de eventos: el píxel de publicidad, el chat de soporte y el gestor de etiquetas que conviven con el checkout dejan de ser decisiones de marketing y pasan a ser decisiones de seguridad.
La forma más sencilla de reducir ese alcance es que el campo de tarjeta viva en un iFrame del proveedor, no en tu HTML. Pregúntale al tuyo qué modelo usa y qué documento de cumplimiento te entrega. El propio estándar y sus documentos están en la web del PCI Security Standards Council.
¿Cuánto puede pesar el widget sin hundir tus Core Web Vitals?
Un widget embebido es código de terceros que se ejecuta en tu página, y eso se nota en las métricas que Google usa como señal. Los umbrales están publicados: según web.dev, el LCP «should occur within 2.5 seconds», el CLS debe mantenerse «0.1 or less» y las páginas «should have a INP of 200 milliseconds or less», todo medido en el percentil 75 de las cargas.
El detalle de INP marca la frontera superior: «An INP above 500 milliseconds means a page has poor responsiveness». INP mide la latencia de todas las interacciones de la visita, y un selector de butacas o un calendario de sesiones es precisamente una sucesión de interacciones.
Tres medidas que funcionan sin tocar el proveedor:
- Carga el widget bajo demanda, al hacer clic en «Comprar entradas», en vez de en el
<head>de todas las páginas. - Reserva el alto del contenedor en CSS antes de que cargue, para que el bloque no empuje el contenido y dispare el CLS.
- Mide con datos de campo, no solo con un test de laboratorio: el percentil 75 de usuarios reales es el que cuenta.
¿Cómo personalizar el widget con tu marca?
El widget debe parecer parte de tu web, no un elemento extraño pegado.
- Colores: adapta la paleta a tu identidad visual
- Tipografía: usa tus propias fuentes si es posible
- Logo: tu marca visible durante todo el proceso
- Mensajes: textos personalizados (botones, confirmaciones)
Un límite que conviene conocer: el contraste de color no es negociable. Si la paleta de tu marca deja un botón o un mensaje de error por debajo del contraste mínimo de WCAG, el widget deja de cumplir, por mucho que se parezca a tu web. Lo mismo con el texto del botón de compra: la personalización no puede llevarse por delante la fórmula del artículo 98.2 del TRLGDCU.
Lista de comprobación antes de contratar un widget
Nueve preguntas al proveedor, todas con respuesta documental.
¿Puedo editar el texto del botón de pedido? Debe poder leerse «pedido con obligación de pago» o una fórmula análoga no ambigua. Si el texto es fijo y ambiguo, el problema es tuyo, no del proveedor.
¿Dónde se muestra el precio total con gastos de gestión? Tiene que estar antes del clic de compra, no en el resumen final.
¿Tenéis declaración de accesibilidad y resultado de auditoría WCAG? Pide el nivel y la fecha. El artículo 13.2 de la Ley 11/2023 obliga a informar de ello en las condiciones generales.
¿El campo de tarjeta se renderiza en vuestro dominio? De la respuesta depende cuánto alcance de PCI DSS asumes tú.
¿Qué documento de cumplimiento PCI DSS entregáis y de qué fecha? Con los requisitos 6.4.3 y 11.6.1 ya exigibles desde el 31 de marzo de 2025.
¿Qué cabeceras frame-ancestors o X-Frame-Options necesito configurar? Y en qué dominios autorizáis el embebido.
Responsive: el widget debe funcionar perfectamente en móvil. Pruébalo con una conexión lenta y con el teclado, no solo con el ratón.
Rendimiento: no debe ralentizar la carga de tu página. Pide el peso del script y comprueba LCP, CLS e INP con datos de campo antes y después de instalarlo.
SEO y lectores de pantalla: el widget no debe afectar negativamente al posicionamiento y tiene que ser usable con lector de pantalla. Mantén en tu HTML el nombre del evento, la fecha, el recinto y el precio desde.
Conclusión
El widget embebido es casi siempre la mejor opción para vender entradas desde tu web. Mantiene al usuario en tu dominio, refuerza tu marca y te devuelve el control de la medición. El esfuerzo de implementación es mínimo comparado con el beneficio, pero no es solo una decisión técnica: el botón del artículo 98.2 del TRLGDCU, la accesibilidad de la Ley 11/2023 y los requisitos de PCI DSS v4.0.1 exigibles desde el 31 de marzo de 2025 son condiciones de salida, no mejoras opcionales. Si tu proveedor de ticketing no ofrece un buen widget ni documenta esos tres puntos, quizás es momento de buscar otro. Consulta nuestra comparativa de plataformas de ticketing o compara directamente Futura Tickets vs Eventbrite.
Fuentes
- Texto refundido de la Ley General para la Defensa de los Consumidores y Usuarios, artículos 97 y 98 (RDL 1/2007, texto consolidado) — BOE
- Ley 11/2023, de 8 de mayo, artículos 2, 3 y 13 (texto consolidado) — BOE
- Web Content Accessibility Guidelines (WCAG) 2.2, Recomendación de 12 de diciembre de 2024 — W3C
- Content Security Policy Level 3, borrador de trabajo de 16 de septiembre de 2026 — W3C
- Just Published: PCI DSS v4.0.1 — PCI Security Standards Council
- PCI Security Standards Council: estándares y biblioteca de documentos — PCI SSC
- Web Vitals: umbrales de LCP, INP y CLS — web.dev, Google
- Interaction to Next Paint (INP) — web.dev, Google
- Conceptos básicos del SEO para JavaScript — Google Search Central