Wanneer een bezoeker een ticket wil kopen, zijn er twee opties: hem doorverwijzen naar de website van de ticketdienst of het aankoopproces geïntegreerd tonen op je eigen website. Deze op het eerste gezicht technische keuze heeft gevolgen voor je merk, je analytics en ook juridisch: de geïntegreerde checkout is e-commerce en daarop zijn drie regels van toepassing die je beter kent voordat je het script plakt.
Welke problemen levert het doorverwijzen van de gebruiker op?
Een gebruiker doorverwijzen naar een andere website om de aankoop af te ronden heeft verborgen kosten.
- Frictie: elke extra klik is een extra afhaakpunt (zie hoe je verlaten winkelwagentjes terugwint)
- Onzekerheid: het verlaten van je website roept twijfels op over veiligheid
- Verlies van merkidentiteit: de gebruiker ziet het merk van de ticketdienst, niet het jouwe
- Kapotte tracking: je verliest zicht op het gedrag van de bezoeker
- Mobiele ervaring: doorverwijzingen werken slechter op mobiel, waar een groot deel van de verkoop via sociale media plaatsvindt
Een kanttekening over de cijfers. In de sector worden vaak percentages voor afhaken per klik en concrete conversieverbeteringen genoemd, maar we hebben geen openbaar onderzoek gevonden, met methodologie en steekproef, dat deze onderbouwt voor ticketverkoop. Hier geven we er dan ook geen: de richting van het effect is bekend, de omvang hangt af van je verkeer, je evenement en de manier waarop de integratie is gebouwd.
Welke voordelen heeft een geïntegreerde widget?
Een verkoopwidget die geïntegreerd is in je website lost al deze problemen op.
- Geen frictie: de gebruiker verlaat je website niet
- Je merk: kleuren, typografie en een consistente ervaring
- Betere conversie: minder stappen en minder domeinwisselingen
- Volledige tracking: je ziet de hele funnel in je analysetools
- Vertrouwen: de gebruiker blijft op het domein dat hij kent
Er is een minder genoemd, maar vrij concreet voordeel: attributie. Bij een doorverwijzing verandert de sessie van domein en wordt de aankoopgebeurtenis geregistreerd in de analytics van de ticketdienst, niet in de jouwe. Met een geïntegreerde checkout vindt de conversie plaats op je eigen domein en kun je deze afzetten tegen je campagnes zonder afhankelijk te zijn van rapportages van derden.
Welke implementatievormen zijn er?
Er zijn verschillende manieren om de ticketverkoop te integreren, met uiteenlopende integratieniveaus.
- iFrame: de eenvoudigste vorm, plaatst de checkout in een frame
- Web component: flexibeler, past zich beter aan het ontwerp aan
- API + eigen frontend: volledige controle, meer ontwikkelwerk
- Popup/modal: opent de aankoop zonder de huidige pagina te verlaten
| Vorm | Ontwikkelinspanning | Controle over ontwerp | Waar vindt de betaling plaats |
|---|---|---|---|
| iFrame | Laag | Beperkt tot het thema van de leverancier | Op het domein van de leverancier |
| Web component | Gemiddeld | Hoog, met eigen CSS | Op het domein van de leverancier |
| API + eigen frontend | Hoog | Volledig | Op je eigen domein, behalve als je het kaartveld delegeert |
| Popup of modal | Laag | Gemiddeld | Op het domein van de leverancier |
De keuze is niet alleen esthetisch. De iFrame wordt beheerd via de directive frame-ancestors van Content Security Policy, die volgens het werkdocument CSP Level 3 van het W3C van 16 september 2026 "is used to control which origins may embed the current resource in a frame" (wordt gebruikt om te bepalen welke origins de huidige bron in een frame mogen insluiten). Dit is de header die je leverancier moet toestaan zodat zijn checkout binnen jouw domein kan laden, en die jij moet controleren zodat niemand je website zonder toestemming insluit.
Een opmerking over positionering. Google documenteert dat het JavaScript-toepassingen in drie fasen verwerkt, "1. Crawling 2. Rendering 3. Indexing", met een headless Chromium dat de code uitvoert. Toch is het verstandig dat de gegevens die je wilt laten ranken — naam van het evenement, datum, locatie, prijs vanaf — in de HTML van je pagina staan en niet alleen binnen de widget.
Wat vereist de Spaanse wet van de aankoopknop?
Dit is het onderdeel dat het meest over het hoofd wordt gezien, en dat een verkoop ongeldig kan maken. Artikel 98.2 van de geconsolideerde tekst van de Spaanse Algemene Wet ter Bescherming van Consumenten en Gebruikers luidt letterlijk:
"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" (Als een bestelling wordt geplaatst door een knop of vergelijkbare functie te activeren, moet deze op een duidelijk leesbare manier uitsluitend worden gelabeld met de uitdrukking "bestelling met betalingsverplichting" of een vergelijkbare, ondubbelzinnige formulering die aangeeft dat het plaatsen van de bestelling de verplichting inhoudt om een betaling aan de ondernemer te verrichten. Zo niet, dan is de consument of gebruiker niet gebonden aan de overeenkomst of bestelling).
"Kopen", "Doorgaan" of "Afronden" zonder meer zijn geen ondubbelzinnige formuleringen. Het gevolg dat de wet voorschrijft, is geen boete: het is dat de overeenkomst de koper niet bindt.
Datzelfde artikel voegt, net ervoor, nog een verplichting toe: de ondernemer "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)" (brengt deze op een duidelijke en prominente manier, en vlak voordat de bestelling wordt geplaatst, de informatie vastgelegd in artikel 97.1.a), e), p) en q) onder de aandacht). Punt e) betreft de prijs: "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" (De totale prijs van de goederen of diensten, inclusief belastingen en heffingen (…) alle extra kosten voor transport, levering of verzending en elke andere kostenpost). De servicekosten van het ticket mogen niet pas na de klik zichtbaar worden.
En lid 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-commercewebsites moeten op een duidelijke en leesbare manier aangeven, uiterlijk bij de start van het aankoopproces, of er leveringsbeperkingen gelden en welke betaalmethoden worden geaccepteerd). Als je widget maar bepaalde betaalmethoden accepteert, moet dat aan het begin worden vermeld, niet in de laatste stap.
Twee zaken die het verdienen contractueel te worden vastgelegd met de leverancier: wie bepaalt de tekst van die knop en wie onderhoudt deze als de leverancier zijn checkout bijwerkt. Ten opzichte van de koper is degene die verkoopt verantwoordelijk, en artikel 97.8 van diezelfde wet legt de bewijslast voor de informatieplicht bij de ondernemer.
Moet de verkoopwidget toegankelijk zijn?
Ja, en sinds kort met een concrete regel erachter. De Spaanse Wet 11/2023 van 8 mei, die de Richtlijn (EU) 2019/882 omzet, somt in artikel 2.2 de verplichte diensten op, en punt f) is kort: "Servicios de comercio electrónico" (e-commercediensten).
Artikel 3.1 verwijst naar de eisen van bijlage I: "todos los servicios deberán cumplir los requisitos de accesibilidad universal que figuran en las secciones III y IV del anexo I" (alle diensten moeten voldoen aan de eisen van universele toegankelijkheid in de secties III en IV van bijlage I). De enige algemene uitzondering staat in artikel 3.3: "Las microempresas que presten servicios estarán exentas de cumplir los requisitos de accesibilidad" (Micro-ondernemingen die diensten verlenen zijn vrijgesteld van de toegankelijkheidseisen).
De einddatum staat in de wet zelf: artikel 2.4 sluit vooraf opgenomen multimediacontent en officebestandsformaten uit van de werkingssfeer "publicados antes del 28 de junio de 2025" (gepubliceerd vóór 28 juni 2025). Wat daarna wordt gepubliceerd of bijgewerkt, valt erbinnen.
De technische referentienorm om hieraan te voldoen zijn de Web Content Accessibility Guidelines. WCAG 2.2 is een W3C-aanbeveling sinds 12 december 2024. Bij een ticketcheckout gaat het meestal mis op concrete punten: de toetsenbordfocus die verloren gaat bij het binnengaan van de iFrame, foutmeldingen die alleen met kleur worden aangegeven, de reserveringstimer voor een stoel zonder waarschuwing of verlenging, en capaciteitskaarten zonder alternatief in lijstvorm. Vraag de leverancier om zijn toegankelijkheidsverklaring voordat je tekent; artikel 13.2 van Wet 11/2023 verplicht de aanbieder om deze informatie op te nemen "en las condiciones generales o documento equivalente" (in de algemene voorwaarden of een gelijkwaardig document).
Wat vereist PCI DSS van de betaalpagina?
Als de widget het betaalformulier op je eigen domein toont, valt je pagina binnen het toepassingsgebied van de norm. De PCI Security Standards Council publiceerde PCI DSS v4.0.1 in juni 2024 en bevestigde dat deze herziening "does not impact the effective date of these new requirements" (geen invloed heeft op de ingangsdatum van deze nieuwe vereisten): de uitgestelde vereisten, waaronder 6.4.3 en 11.6.1 over de scripts van de betaalpagina, werden op 31 maart 2025 verplicht.
In de praktijk verplichten deze twee vereisten om elk script dat op de betaalpagina wordt uitgevoerd te inventariseren en te autoriseren, te verantwoorden waarom het er staat en niet-geautoriseerde wijzigingen in headers en inhoud te detecteren. Vertaald naar een evenementenwebsite: de advertentiepixel, de supportchat en de tagmanager die naast de checkout draaien, zijn niet langer marketingbeslissingen maar beveiligingsbeslissingen.
De eenvoudigste manier om dat toepassingsgebied te beperken, is dat het kaartveld in een iFrame van de leverancier staat, niet in je eigen HTML. Vraag je leverancier welk model hij gebruikt en welk conformiteitsdocument hij aanlevert. De norm zelf en de bijbehorende documenten staan op de website van de PCI Security Standards Council.
Hoeveel mag de widget wegen zonder je Core Web Vitals te schaden?
Een geïntegreerde widget is code van derden die op je pagina draait, en dat is merkbaar in de meetgegevens die Google als signaal gebruikt. De drempelwaarden zijn gepubliceerd: volgens web.dev moet de LCP "should occur within 2.5 seconds" (binnen 2,5 seconden plaatsvinden), moet de CLS "0.1 or less" (0,1 of minder) blijven en moeten pagina's "should have a INP of 200 milliseconds or less" (een INP van 200 milliseconden of minder hebben), alles gemeten op het 75e percentiel van de pageviews.
Het detail over INP stelt de bovengrens vast: "An INP above 500 milliseconds means a page has poor responsiveness" (Een INP boven 500 milliseconden betekent dat een pagina slecht reageert). INP meet de latentie van alle interacties tijdens het bezoek, en een stoelenkiezer of een agenda met sessies is precies een reeks interacties.
Drie maatregelen die werken zonder aan de leverancier te raken:
- Laad de widget op aanvraag, bij het klikken op "Tickets koopen", in plaats van in de
<head>van elke pagina. - Reserveer de hoogte van de container in CSS voordat deze laadt, zodat het blok de inhoud niet verschuift en de CLS niet verhoogt.
- Meet met veldgegevens, niet alleen met een labtest: het 75e percentiel van echte gebruikers is wat telt.
Hoe personaliseer je de widget met je eigen huisstijl?
De widget moet deel lijken van je website, geen vreemd geplakt element.
- Kleuren: pas het palet aan je visuele identiteit aan
- Typografie: gebruik waar mogelijk je eigen lettertypen
- Logo: je merk zichtbaar gedurende het hele proces
- Berichten: gepersonaliseerde teksten (knoppen, bevestigingen)
Een grens die je moet kennen: kleurcontrast is niet onderhandelbaar. Als het kleurenpalet van je merk een knop of foutmelding onder het minimale WCAG-contrast brengt, voldoet de widget niet meer, hoe goed hij ook op je website lijkt. Datzelfde geldt voor de tekst van de aankoopknop: personalisatie mag niet ten koste gaan van de formule uit artikel 98.2 van de TRLGDCU.
Checklist voordat je een widget aanschaft
Negen vragen aan de leverancier, allemaal met een documenteerbaar antwoord.
Kan ik de tekst van de bestelknop bewerken? Er moet "bestelling met betalingsverplichting" of een vergelijkbare, ondubbelzinnige formulering te lezen zijn. Als de tekst vast en ambigu is, is het probleem van jou, niet van de leverancier.
Waar wordt de totaalprijs met servicekosten weergegeven? Dat moet vóór de aankoopklik zijn, niet in de uiteindelijke samenvatting.
Hebben jullie een toegankelijkheidsverklaring en WCAG-auditresultaat? Vraag naar het niveau en de datum. Artikel 13.2 van Wet 11/2023 verplicht om dit te vermelden in de algemene voorwaarden.
Wordt het kaartveld gerenderd op jullie domein? Van dit antwoord hangt af hoeveel PCI DSS-toepassingsgebied jij op je nemen moet.
Welk PCI DSS-conformiteitsdocument leveren jullie aan en van welke datum? Met de vereisten 6.4.3 en 11.6.1 al verplicht sinds 31 maart 2025.
Welke frame-ancestors- of X-Frame-Options-headers moet ik instellen? En op welke domeinen jullie het insluiten toestaan.
Responsive: de widget moet perfect werken op mobiel. Test met een trage verbinding en met het toetsenbord, niet alleen met de muis.
Prestaties: mag de laadtijd van je pagina niet vertragen. Vraag naar de omvang van het script en controleer LCP, CLS en INP met veldgegevens voor en na installatie.
SEO en schermlezers: de widget mag de positionering niet negatief beïnvloeden en moet bruikbaar zijn met een schermlezer. Houd de naam van het evenement, de datum, de locatie en de prijs vanaf in je eigen HTML.
Conclusie
De geïntegreerde widget is bijna altijd de beste keuze om tickets vanaf je eigen website te verkopen. Hij houdt de gebruiker op je domein, versterkt je merk en geeft je de controle over de metingen terug. De implementatie-inspanning is minimaal vergeleken met het voordeel, maar het is niet alleen een technische beslissing: de knop van artikel 98.2 van de TRLGDCU, de toegankelijkheid van Wet 11/2023 en de vereisten van PCI DSS v4.0.1 die sinds 31 maart 2025 verplicht zijn, zijn randvoorwaarden, geen optionele verbeteringen. Als je ticketingleverancier geen goede widget biedt of deze drie punten niet documenteert, is het misschien tijd om een andere te zoeken. Bekijk onze vergelijking van ticketingplatforms of vergelijk direct Futura Tickets versus Eventbrite.
Bronnen
- Geconsolideerde tekst van de Spaanse Algemene Wet ter Bescherming van Consumenten en Gebruikers, artikelen 97 en 98 (RDL 1/2007, geconsolideerde tekst) — BOE
- Spaanse Wet 11/2023 van 8 mei, artikelen 2, 3 en 13 (geconsolideerde tekst) — BOE
- Web Content Accessibility Guidelines (WCAG) 2.2, aanbeveling van 12 december 2024 — W3C
- Content Security Policy Level 3, werkdocument van 16 september 2026 — W3C
- Just Published: PCI DSS v4.0.1 — PCI Security Standards Council
- PCI Security Standards Council: normen en documentbibliotheek — PCI SSC
- Web Vitals: drempelwaarden voor LCP, INP en CLS — web.dev, Google
- Interaction to Next Paint (INP) — web.dev, Google
- Basisprincipes van SEO voor JavaScript — Google Search Central