Was ist ein eingebettetes Widget für den Ticketverkauf?

Wenn ein Besucher ein Ticket kaufen möchte, gibt es zwei Möglichkeiten: ihn auf die Website der Ticketing-Plattform weiterzuleiten oder den Kaufprozess direkt in die eigene Website einzubetten. Diese scheinbar rein technische Entscheidung hat Folgen für die Marke, die Analyse und auch rechtliche Konsequenzen: Der eingebettete Checkout gilt als E-Commerce, und dafür gelten drei Vorschriften, die man kennen sollte, bevor man das Skript einbindet.

Welche Probleme bringt die Weiterleitung auf eine andere Website mit sich?

Eine Weiterleitung zum Abschluss des Kaufs auf eine andere Website hat versteckte Kosten.

• Reibung: Jeder zusätzliche Klick ist ein potenzieller Abbruchpunkt (siehe wie man abgebrochene Warenkörbe zurückgewinnt)
• Misstrauen: Das Verlassen deiner Website weckt Sicherheitsbedenken
• Markenverlust: Der Nutzer sieht die Marke der Ticketing-Plattform, nicht deine
• Unterbrochenes Tracking: Du verlierst den Einblick in das Nutzerverhalten
• Mobile Erfahrung: Weiterleitungen funktionieren auf Mobilgeräten schlechter, wo sich ein großer Teil der Käufe über soziale Netzwerke konzentriert

Eine Anmerkung zu den Zahlen. In der Branche kursieren immer wieder konkrete Abbruchquoten pro Klick und Konversionssteigerungen, doch wir haben keine öffentliche Studie mit Methodik und Stichprobe gefunden, die diese Angaben für den Ticketverkauf belegt. Deshalb nennen wir hier keine: Die Richtung des Effekts ist bekannt, seine Größenordnung hängt von deinem Traffic, deinem Event und der Qualität der Integration ab.

Welche Vorteile bietet ein eingebettetes Widget?

Ein in deine Website integriertes Verkaufswidget löst all diese Probleme.

• Reibungslos: Der Nutzer verlässt deine Website nicht
• Deine Marke: Farben, Typografie und ein stimmiges Erlebnis
• Bessere Konversion: Weniger Schritte und weniger Domainwechsel
• Vollständiges Tracking: Du siehst den gesamten Funnel in deinen Tools zur Datenanalyse
• Vertrauen: Der Nutzer bleibt auf der ihm bekannten Domain

Es gibt einen weniger erwähnten, aber sehr konkreten Vorteil: die Attribution. Bei einer Weiterleitung wechselt die Sitzung die Domain, und das Kaufevent wird in der Property der Ticketing-Plattform erfasst, nicht in deiner eigenen. Beim eingebetteten Checkout findet die Konversion auf deiner Domain statt, und du kannst sie direkt gegen deine Kampagnen messen, ohne auf Berichte Dritter angewiesen zu sein.

Welche Umsetzungsarten gibt es?

Es gibt verschiedene Wege, den Ticketverkauf einzubetten, mit unterschiedlichem Integrationsgrad.

• iFrame: die einfachste Variante, bindet den Checkout in einem Frame ein
• Web Component: flexibler, passt sich besser an das Design an
• API + eigenes Frontend: volle Kontrolle, mehr Entwicklungsaufwand
• Popup/Modal: öffnet den Kauf, ohne die aktuelle Seite zu verlassen

Die Wahl ist nicht nur eine Frage der Optik. Das iFrame wird über die Content-Security-Policy-Direktive frame-ancestors gesteuert, die laut dem W3C-Arbeitsentwurf CSP Level 3 vom 16. September 2026 „is used to control which origins may embed the current resource in a frame“ ist. Das ist der Header, den dein Anbieter zulassen muss, damit sein Checkout innerhalb deiner Domain lädt, und den du selbst prüfen musst, damit niemand deine Website ohne Erlaubnis einbettet.

Ein Hinweis zum Ranking. Google dokumentiert, dass JavaScript-Anwendungen in drei Phasen verarbeitet werden, „1. Crawling 2. Rendering 3. Indexing“, mithilfe eines Chromium ohne Oberfläche, das den Code ausführt. Trotzdem sollten die Daten, die du ranken möchtest – Name des Events, Datum, Veranstaltungsort, Preis ab – im HTML deiner Seite stehen und nicht nur innerhalb des Widgets.

Was verlangt das spanische Gesetz vom Kaufbutton?

Das ist der Teil, der am häufigsten übersehen wird – und der einen Verkauf unwirksam machen kann. Artikel 98.2 des konsolidierten spanischen Verbraucherschutzgesetzes (TRLGDCU) ist unmissverständlich:

«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» („Wird eine Bestellung durch Betätigen eines Buttons oder einer ähnlichen Funktion ausgelöst, muss dieser gut lesbar ausschließlich mit dem Ausdruck ‚Bestellung mit Zahlungsverpflichtung‘ oder einer vergleichbaren, eindeutigen Formulierung beschriftet sein, die anzeigt, dass die Bestellung die Verpflichtung zur Zahlung an den Unternehmer bedeutet. Andernfalls ist der Verbraucher nicht an den Vertrag oder die Bestellung gebunden“).

„Comprar“ („Kaufen“), „Continuar“ („Weiter“) oder „Finalizar“ („Abschließen“) allein sind keine eindeutigen Formulierungen. Die Konsequenz, die das Gesetz vorsieht, ist keine Geldbuße: Der Vertrag bindet den Käufer nicht.

Derselbe Artikel fügt kurz davor eine weitere Pflicht hinzu: Der Unternehmer «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)» (muss den Verbraucher klar und hervorgehoben und unmittelbar vor der Bestellung über die in Artikel 97.1 Buchstaben a), e), p) und q) festgelegten Informationen in Kenntnis setzen). Buchstabe e) betrifft den Preis: «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» (der Gesamtpreis der Waren oder Dienstleistungen einschließlich Steuern und Abgaben [...] sämtliche zusätzlichen Kosten für Versand, Lieferung oder Porto sowie alle weiteren Kosten). Die Gebühren für die Ticketbearbeitung dürfen nicht erst nach dem Klick erscheinen.

Und Absatz 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» (E-Commerce-Websites müssen klar und lesbar spätestens zu Beginn des Kaufvorgangs angeben, ob Lieferbeschränkungen bestehen und welche Zahlungsarten akzeptiert werden). Wenn dein Widget nur bestimmte Methoden akzeptiert, muss das am Anfang stehen, nicht im letzten Schritt.

Zwei Punkte sollten vertraglich mit dem Anbieter geklärt werden: Wer kontrolliert den Text dieses Buttons, und wer pflegt ihn, wenn der Anbieter seinen Checkout aktualisiert? Gegenüber dem Käufer haftet derjenige, der verkauft, und Artikel 97.8 desselben Gesetzes legt die Beweislast für die Erfüllung der Informationspflichten beim Unternehmer.

Muss das Verkaufswidget barrierefrei sein?

Ja, und seit kurzem gibt es dafür eine konkrete Rechtsgrundlage. Das Gesetz 11/2023 vom 8. Mai, das die Richtlinie (EU) 2019/882 umsetzt, enthält in Artikel 2.2 die Liste der verpflichteten Dienste, und Buchstabe f) ist knapp: «Servicios de comercio electrónico» (E-Commerce-Dienste).

Artikel 3.1 verweist auf die Anforderungen aus Anhang I: «todos los servicios deberán cumplir los requisitos de accesibilidad universal que figuran en las secciones III y IV del anexo I» (alle Dienste müssen die Anforderungen an die allgemeine Barrierefreiheit aus den Abschnitten III und IV von Anhang I erfüllen). Die einzige allgemeine Ausnahme findet sich in Artikel 3.3: «Las microempresas que presten servicios estarán exentas de cumplir los requisitos de accesibilidad» (Kleinstunternehmen, die Dienstleistungen erbringen, sind von der Erfüllung der Barrierefreiheitsanforderungen ausgenommen).

Der Stichtag ergibt sich aus dem Gesetz selbst: Artikel 2.4 nimmt vorab aufgezeichnete Multimedia-Inhalte und Office-Dateiformate vom Anwendungsbereich aus, die «publicados antes del 28 de junio de 2025» (vor dem 28. Juni 2025 veröffentlicht) wurden. Was danach veröffentlicht oder aktualisiert wird, fällt darunter.

Der technische Referenzstandard zur Erfüllung sind die Web Content Accessibility Guidelines. WCAG 2.2 ist seit dem 12. Dezember 2024 eine W3C-Empfehlung. Bei einem Ticket-Checkout sind es meist konkrete Punkte, die scheitern: der Tastaturfokus, der beim Betreten des iFrames verloren geht, Fehlermeldungen, die nur über Farbe gekennzeichnet sind, der Timer für die Sitzplatzreservierung ohne Warnung oder Verlängerung, und Saalpläne ohne Listenalternative. Fordere vom Anbieter vor der Unterzeichnung seine Erklärung zur Barrierefreiheit an; Artikel 13.2 des Gesetzes 11/2023 verpflichtet den Dienstleister, diese Information «en las condiciones generales o documento equivalente» (in den allgemeinen Geschäftsbedingungen oder einem gleichwertigen Dokument) anzugeben.

Was verlangt PCI DSS von der Zahlungsseite?

Wenn das Widget das Zahlungsformular auf deiner Domain rendert, fällt deine Seite in den Geltungsbereich des Standards. Der PCI Security Standards Council veröffentlichte PCI DSS v4.0.1 im Juni 2024 und bestätigte, dass diese Überarbeitung „does not impact the effective date of these new requirements“ (keine Auswirkung auf das Inkrafttreten dieser neuen Anforderungen hat): Die aufgeschobenen Anforderungen, darunter 6.4.3 und 11.6.1 zu den Skripten der Zahlungsseite, wurden am 31. März 2025 verbindlich.

In der Praxis verlangen diese beiden Anforderungen, jedes Skript, das auf der Zahlungsseite ausgeführt wird, zu inventarisieren und zu autorisieren, zu begründen, warum es dort ist, und unbefugte Änderungen an Headern und Inhalten zu erkennen. Übersetzt auf eine Event-Website: Das Werbepixel, der Support-Chat und der Tag-Manager, die neben dem Checkout laufen, sind nicht mehr nur Marketingentscheidungen, sondern Sicherheitsentscheidungen.

Der einfachste Weg, diesen Geltungsbereich zu verringern, besteht darin, dass das Kartenfeld in einem iFrame des Anbieters liegt, nicht in deinem HTML. Frag deinen Anbieter, welches Modell er verwendet und welches Compliance-Dokument er dir ausstellt. Der Standard selbst und die zugehörigen Dokumente findest du auf der Website des PCI Security Standards Council.

Wie schwer darf das Widget sein, ohne deine Core Web Vitals zu beeinträchtigen?

Ein eingebettetes Widget ist Drittanbieter-Code, der auf deiner Seite ausgeführt wird, und das macht sich in den Metriken bemerkbar, die Google als Signal nutzt. Die Schwellenwerte sind veröffentlicht: Laut web.dev sollte der LCP „should occur within 2.5 seconds“ (innerhalb von 2,5 Sekunden eintreten), der CLS sollte bei „0.1 or less“ (0,1 oder darunter) bleiben, und Seiten „should have a INP of 200 milliseconds or less“ (sollten einen INP von 200 Millisekunden oder weniger haben) – jeweils gemessen am 75. Perzentil der Ladevorgänge.

Die Detailseite zum INP markiert die obere Grenze: „An INP above 500 milliseconds means a page has poor responsiveness“ (ein INP über 500 Millisekunden bedeutet, dass eine Seite eine schlechte Reaktionsfähigkeit hat). INP misst die Latenz sämtlicher Interaktionen während des Besuchs, und ein Sitzplatzwähler oder ein Terminkalender ist genau das: eine Abfolge von Interaktionen.

Drei Maßnahmen, die ohne Eingriff beim Anbieter funktionieren:

• Lade das Widget bei Bedarf, also beim Klick auf „Tickets kaufen“, statt es im <head> jeder Seite einzubinden.
• Reserviere die Höhe des Containers per CSS, bevor er lädt, damit der Block den Inhalt nicht verschiebt und den CLS nicht verschlechtert.
• Messe mit Felddaten, nicht nur mit einem Labortest: Das 75. Perzentil der echten Nutzer ist das, was zählt.

Wie passt du das Widget an deine Marke an?

Das Widget sollte wie ein Teil deiner Website wirken, nicht wie ein aufgeklebtes Fremdelement.

• Farben: Passe die Palette an dein visuelles Erscheinungsbild an
• Typografie: Verwende, wenn möglich, deine eigenen Schriftarten
• Logo: Deine Marke bleibt während des gesamten Prozesses sichtbar
• Texte: Individuelle Formulierungen (Buttons, Bestätigungen)

Eine Grenze, die man kennen sollte: Der Farbkontrast ist nicht verhandelbar. Wenn die Farbpalette deiner Marke einen Button oder eine Fehlermeldung unter den Mindestkontrast der WCAG drückt, erfüllt das Widget die Vorgaben nicht mehr, egal wie gut es zu deiner Website passt. Dasselbe gilt für den Text des Kaufbuttons: Die individuelle Gestaltung darf nicht über die Formel aus Artikel 98.2 des TRLGDCU hinweggehen.

Checkliste, bevor du ein Widget beauftragst

Neun Fragen an den Anbieter, alle mit dokumentierter Antwort.

Kann ich den Text des Bestellbuttons bearbeiten? Es muss „Bestellung mit Zahlungsverpflichtung“ oder eine vergleichbare, eindeutige Formulierung zu lesen sein. Ist der Text fest vorgegeben und mehrdeutig, liegt das Problem bei dir, nicht beim Anbieter.

Wo wird der Gesamtpreis inklusive Bearbeitungsgebühren angezeigt? Er muss vor dem Kaufklick erscheinen, nicht erst in der abschließenden Zusammenfassung.

Gibt es eine Erklärung zur Barrierefreiheit und ein WCAG-Audit-Ergebnis? Frag nach Stufe und Datum. Artikel 13.2 des Gesetzes 11/2023 verpflichtet dazu, diese Information in den allgemeinen Geschäftsbedingungen anzugeben.

Wird das Kartenfeld auf eurer Domain gerendert? Von der Antwort hängt ab, welchen PCI-DSS-Geltungsbereich du selbst übernimmst.

Welches PCI-DSS-Compliance-Dokument stellt ihr aus, und von welchem Datum? Die Anforderungen 6.4.3 und 11.6.1 sind bereits seit dem 31. März 2025 verbindlich.

Welche frame-ancestors- oder X-Frame-Options-Header muss ich konfigurieren? Und auf welchen Domains ihr die Einbettung erlaubt.

Responsive: Das Widget muss auf Mobilgeräten einwandfrei funktionieren. Teste es mit einer langsamen Verbindung und mit der Tastatur, nicht nur mit der Maus.

Performance: Es darf die Ladezeit deiner Seite nicht verlangsamen. Frag nach der Größe des Skripts und prüfe LCP, CLS und INP mit Felddaten vor und nach der Installation.

SEO und Screenreader: Das Widget darf das Ranking nicht negativ beeinflussen und muss mit Screenreadern nutzbar sein. Behalte Name des Events, Datum, Veranstaltungsort und Preis ab in deinem HTML.

Fazit

Das eingebettete Widget ist fast immer die beste Option, um Tickets über die eigene Website zu verkaufen. Es hält den Nutzer auf deiner Domain, stärkt deine Marke und gibt dir die Kontrolle über die Messung zurück. Der Implementierungsaufwand ist im Vergleich zum Nutzen gering, aber es ist nicht nur eine technische Entscheidung: Der Button aus Artikel 98.2 des TRLGDCU, die Barrierefreiheit nach dem Gesetz 11/2023 und die seit dem 31. März 2025 verbindlichen Anforderungen von PCI DSS v4.0.1 sind Grundvoraussetzungen, keine optionalen Verbesserungen. Wenn dein Ticketing-Anbieter kein gutes Widget bietet oder diese drei Punkte nicht dokumentiert, ist vielleicht der richtige Zeitpunkt, einen anderen zu suchen. Sieh dir unseren Vergleich von Ticketing-Plattformen an oder vergleiche direkt Futura Tickets mit Eventbrite.

Quellen

• Konsolidiertes spanisches Verbraucherschutzgesetz, Artikel 97 und 98 (RDL 1/2007, konsolidierte Fassung) — BOE
• Gesetz 11/2023 vom 8. Mai, Artikel 2, 3 und 13 (konsolidierte Fassung) — BOE
• Web Content Accessibility Guidelines (WCAG) 2.2, Empfehlung vom 12. Dezember 2024 — W3C
• Content Security Policy Level 3, Arbeitsentwurf vom 16. September 2026 — W3C
• Just Published: PCI DSS v4.0.1 — PCI Security Standards Council
• PCI Security Standards Council: Standards und Dokumentenbibliothek — PCI SSC
• Web Vitals: Schwellenwerte für LCP, INP und CLS — web.dev, Google
• Interaction to Next Paint (INP) — web.dev, Google
• Grundlagen der SEO für JavaScript — Google Search Central