Co to jest wbudowany widget sprzedaży biletów?

Gdy odwiedzający chce kupić bilet, istnieją dwie opcje: przekierować go na stronę systemu biletowego albo pokazać proces zakupu wbudowany we własną stronę. Ta z pozoru techniczna decyzja ma konsekwencje dla marki, analityki, a także prawne: wbudowany checkout to handel elektroniczny, a stosują się do niego trzy przepisy, które warto znać, zanim wkleisz skrypt.

Jakie problemy niesie przekierowanie użytkownika na inną stronę?

Przekierowanie użytkownika na inną stronę w celu dokończenia zakupu niesie ze sobą skryte koszty.

• Tarcie: każde dodatkowe kliknięcie to kolejny punkt, w którym użytkownik może zrezygnować (zobacz jak odzyskać opuszczone koszyki)
• Nieufność: opuszczenie Twojej strony wzbudza obawy o bezpieczeństwo
• Utrata marki: użytkownik widzi markę systemu biletowego, nie Twoją
• Przerwane śledzenie: tracisz wgląd w zachowanie użytkownika
• Doświadczenie mobilne: przekierowania działają gorzej na urządzeniach mobilnych, gdzie koncentruje się duża część zakupów z mediów społecznościowych

Jedna uwaga co do liczb. W branży powtarza się konkretne wskaźniki rezygnacji na kliknięcie i konkretne wzrosty konwersji, ale nie znaleźliśmy publicznego badania, z metodologią i próbą, które potwierdzałoby je dla sprzedaży biletów. Dlatego nie podajemy tu żadnej liczby: kierunek efektu jest znany, a jego wielkość zależy od Twojego ruchu, wydarzenia i sposobu wdrożenia integracji.

Jakie zalety ma wbudowany widget?

Widget sprzedaży zintegrowany z Twoją stroną rozwiązuje wszystkie te problemy.

• Brak tarcia: użytkownik nie opuszcza Twojej strony
• Twoja marka: kolory, typografia i spójne doświadczenie
• Lepsza konwersja: mniej kroków i mniej wyjść z domeny
• Pełne śledzenie: widzisz cały lejek w swoich narzędziach do analizy danych
• Zaufanie: użytkownik pozostaje w znanej mu domenie

Jest jeszcze jedna zaleta, rzadziej wymieniana, ale bardzo konkretna: atrybucja. Przy przekierowaniu sesja zmienia domenę, a zdarzenie zakupowe rejestrowane jest we własności systemu biletowego, nie Twojej. Przy wbudowanym checkoucie konwersja zachodzi w Twojej domenie, dzięki czemu możesz ją mierzyć względem swoich kampanii, bez konieczności opierania się na raportach zewnętrznych.

Jakie są rodzaje wdrożenia?

Istnieją różne sposoby wbudowania sprzedaży biletów, o różnym poziomie integracji.

• iFrame: najprostsza forma, wstawia checkout w ramkę
• Web component: bardziej elastyczny, lepiej dopasowuje się do designu
• API + własny frontend: pełna kontrola, więcej pracy programistycznej
• Popup/modal: otwiera zakup bez opuszczania aktualnej strony

Wybór nie jest tylko kwestią estetyki. iFrame kontroluje się za pomocą dyrektywy frame-ancestors z Content Security Policy, która, zgodnie z projektem roboczym CSP Level 3 W3C z 16 września 2026 r., «is used to control which origins may embed the current resource in a frame» (służy do kontrolowania, które źródła mogą wbudować dany zasób w ramkę). To nagłówek, który Twój dostawca musi zezwolić, aby jego checkout wczytywał się w Twojej domenie, i który Ty musisz sprawdzić, aby nikt nie wbudował Twojej strony bez zgody.

Uwaga dotycząca pozycjonowania. Google dokumentuje, że przetwarza aplikacje JavaScript w trzech fazach, «1. Crawling 2. Rendering 3. Indexing» (indeksowanie, renderowanie, indeksacja), za pomocą bezinterfejsowego Chromium, który wykonuje kod. Niezależnie od tego, warto, by dane, które chcesz pozycjonować — nazwa wydarzenia, data, miejsce, cena od — znajdowały się w kodzie HTML Twojej strony, a nie tylko wewnątrz widgetu.

Co hiszpańskie prawo wymaga od przycisku zakupu?

To część najczęściej pomijana, a jednocześnie taka, która może pozbawić sprzedaż skuteczności prawnej. Artykuł 98.2 skonsolidowanego tekstu hiszpańskiej Ley General para la Defensa de los Consumidores y Usuarios brzmi dosłownie:

«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» (Jeśli złożenie zamówienia następuje poprzez aktywowanie przycisku lub podobnej funkcji, muszą one być oznaczone, w sposób łatwo czytelny, wyłącznie wyrażeniem „zamówienie z obowiązkiem zapłaty” lub inną analogiczną, niejednoznaczną formułą wskazującą, że złożenie zamówienia wiąże się z obowiązkiem zapłaty na rzecz przedsiębiorcy. W przeciwnym razie konsument lub użytkownik nie będzie związany umową lub zamówieniem).

Same słowa „Kup”, „Dalej” czy „Zakończ” nie stanowią jednoznacznych formuł. Konsekwencja przewidziana w przepisie to nie kara: to fakt, że umowa nie wiąże kupującego.

Ten sam artykuł dodaje, chwilę wcześniej, kolejny obowiązek: przedsiębiorca «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)» (poinformuje konsumenta w sposób jasny i widoczny, bezpośrednio przed złożeniem zamówienia, o informacjach określonych w artykule 97.1.a), e), p) i q)). Litera e) odnosi się do ceny: «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» (całkowita cena towarów lub usług, wraz z podatkami i opłatami (…) wszelkimi dodatkowymi kosztami transportu, dostawy lub przesyłki oraz innymi kosztami). Opłaty za obsługę biletu nie mogą pojawić się po kliknięciu.

I ustęp 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» (strony handlu elektronicznego muszą wskazać w sposób jasny i czytelny, najpóźniej na początku procesu zakupu, czy obowiązują jakieś ograniczenia dostawy oraz jakie metody płatności są akceptowane). Jeśli Twój widget przyjmuje tylko określone metody płatności, informację o tym podaje się na początku, nie w ostatnim kroku.

Dwie rzeczy warto jasno uregulować w umowie z dostawcą: kto kontroluje treść tego przycisku i kto odpowiada za jej aktualność, jeśli dostawca zmienia swój checkout. Przed kupującym odpowiada sprzedawca, a artykuł 97.8 tego samego tekstu nakłada na przedsiębiorcę ciężar dowodu wypełnienia obowiązków informacyjnych.

Czy widget sprzedaży musi być dostępny cyfrowo?

Tak, a od niedawna wsparte konkretnym przepisem. Ley 11/2023 z 8 maja, transponująca dyrektywę (UE) 2019/882, zawiera w artykule 2.2 listę usług objętych obowiązkiem, a litera f) jest krótka: «Servicios de comercio electrónico» (usługi handlu elektronicznego).

Artykuł 3.1 odsyła do wymogów zawartych w załączniku I: «todos los servicios deberán cumplir los requisitos de accesibilidad universal que figuran en las secciones III y IV del anexo I» (wszystkie usługi muszą spełniać wymogi powszechnej dostępności określone w sekcjach III i IV załącznika I). Jedyny ogólny wyjątek przewiduje artykuł 3.3: «Las microempresas que presten servicios estarán exentas de cumplir los requisitos de accesibilidad» (mikroprzedsiębiorstwa świadczące usługi są zwolnione z obowiązku spełniania wymogów dostępności).

Data odcięcia znajduje się w samej ustawie: artykuł 2.4 wyłącza z zakresu stosowania wcześniej nagrane treści multimedialne oraz formaty plików biurowych «publicados antes del 28 de junio de 2025» (opublikowane przed 28 czerwca 2025 r.). Wszystko, co opublikowano lub zaktualizowano później, jest już objęte przepisami.

Techniczną normą referencyjną do spełnienia tych wymogów są Wytyczne dla dostępności treści internetowych. WCAG 2.2 jest Rekomendacją W3C od 12 grudnia 2024 r. W checkoucie biletowym najczęściej zawodzi konkretna rzecz: fokus klawiatury, który gubi się po wejściu w iFrame, komunikaty o błędach oznaczone jedynie kolorem, licznik rezerwacji miejsca bez ostrzeżenia czy możliwości wydłużenia, oraz mapy sektorów bez alternatywy w formie listy. Poproś dostawcę o deklarację dostępności przed podpisaniem umowy; artykuł 13.2 Ley 11/2023 zobowiązuje usługodawcę do zawarcia tej informacji «en las condiciones generales o documento equivalente» (w warunkach ogólnych lub dokumencie równoważnym).

Co PCI DSS wymaga od strony płatności?

Jeśli widget renderuje formularz płatności w Twojej domenie, Twoja strona wchodzi w zakres standardu. PCI Security Standards Council opublikowało PCI DSS v4.0.1 w czerwcu 2024 r. i potwierdziło, że ta rewizja «does not impact the effective date of these new requirements» (nie wpływa na datę wejścia w życie tych nowych wymogów): odroczone wymogi, w tym 6.4.3 i 11.6.1 dotyczące skryptów na stronie płatności, stały się obowiązkowe 31 marca 2025 r.

W praktyce te dwa wymogi nakazują inwentaryzować i autoryzować każdy skrypt wykonywany na stronie płatności, uzasadniać jego obecność oraz wykrywać nieautoryzowane zmiany w nagłówkach i treści. Przełożone na stronę wydarzenia: piksel reklamowy, czat wsparcia i menedżer tagów działające razem z checkoutem przestają być decyzjami marketingowymi i stają się decyzjami z zakresu bezpieczeństwa.

Najprostszym sposobem na zmniejszenie tego zakresu jest umieszczenie pola karty w iFramie dostawcy, a nie w Twoim HTML. Zapytaj swojego dostawcę, jaki model stosuje i jaki dokument zgodności Ci przekazuje. Sam standard i jego dokumentacja znajdują się na stronie PCI Security Standards Council.

Jak dużo może „ważyć” widget, by nie zaniżyć Twoich Core Web Vitals?

Wbudowany widget to kod zewnętrznego dostawcy wykonywany na Twojej stronie, co odbija się na metrykach, które Google traktuje jako sygnał rankingowy. Progi są opublikowane: według web.dev, LCP «should occur within 2.5 seconds» (powinien wystąpić w ciągu 2,5 sekundy), CLS musi utrzymać się na poziomie «0.1 or less» (0,1 lub mniej), a strony «should have a INP of 200 milliseconds or less» (powinny mieć INP wynoszący 200 milisekund lub mniej), wszystko mierzone w 75. percentylu wczytań.

Opis INP wyznacza górną granicę: «An INP above 500 milliseconds means a page has poor responsiveness» (INP powyżej 500 milisekund oznacza, że strona ma słabą responsywność). INP mierzy opóźnienie wszystkich interakcji w czasie wizyty, a selektor miejsc czy kalendarz terminów to właśnie ciąg interakcji.

Trzy działania, które można wdrożyć bez ingerowania w kod dostawcy:

• Wczytuj widget na żądanie, po kliknięciu „Kup bilety”, a nie w <head> wszystkich stron.
• Zarezerwuj wysokość kontenera w CSS przed jego wczytaniem, aby blok nie przesuwał treści i nie podnosił CLS.
• Mierz na danych z pola, nie tylko testami laboratoryjnymi: liczy się 75. percentyl rzeczywistych użytkowników.

Jak spersonalizować widget pod swoją marką?

Widget powinien wyglądać jak część Twojej strony, nie jak doklejony, obcy element.

• Kolory: dopasuj paletę do swojej identyfikacji wizualnej
• Typografia: używaj własnych czcionek, o ile to możliwe
• Logo: Twoja marka widoczna przez cały proces
• Komunikaty: spersonalizowane treści (przyciski, potwierdzenia)

Jest jedno ograniczenie, które warto znać: kontrast kolorów nie podlega negocjacji. Jeśli paleta Twojej marki powoduje, że przycisk lub komunikat o błędzie spada poniżej minimalnego kontrastu WCAG, widget przestaje być zgodny z wymogami, niezależnie od tego, jak dobrze wpasowuje się w Twoją stronę. To samo dotyczy tekstu przycisku zakupu: personalizacja nie może zastąpić formuły wymaganej przez artykuł 98.2 TRLGDCU.

Lista kontrolna przed wyborem widgetu

Dziewięć pytań do dostawcy, na każde z nich powinna istnieć odpowiedź w formie dokumentu.

Czy mogę edytować tekst przycisku zamówienia? Musi być można odczytać „zamówienie z obowiązkiem zapłaty” lub inną analogiczną, niejednoznaczną formułę. Jeśli tekst jest ustalony na stałe i niejednoznaczny, problem jest Twój, nie dostawcy.

Gdzie wyświetlana jest cena całkowita wraz z opłatami za obsługę? Musi być widoczna przed kliknięciem zakupu, nie w ostatecznym podsumowaniu.

Czy macie deklarację dostępności i wynik audytu WCAG? Zapytaj o poziom i datę. Artykuł 13.2 Ley 11/2023 zobowiązuje do podania tej informacji w warunkach ogólnych.

Czy pole karty renderowane jest w waszej domenie? Od odpowiedzi zależy, jaki zakres PCI DSS przejmujesz na siebie.

Jaki dokument zgodności z PCI DSS przekazujecie i z jaką datą? Pamiętając, że wymogi 6.4.3 i 11.6.1 są obowiązkowe już od 31 marca 2025 r.

Jakie nagłówki frame-ancestors lub X-Frame-Options muszę skonfigurować? I na jakich domenach zezwalacie na wbudowanie widgetu.

Responsywność: widget musi działać bezbłędnie na urządzeniach mobilnych. Przetestuj go na wolnym połączeniu i za pomocą klawiatury, nie tylko myszki.

Wydajność: nie może spowalniać wczytywania Twojej strony. Zapytaj o wagę skryptu i sprawdź LCP, CLS oraz INP na danych z pola przed i po jego instalacji.

SEO i czytniki ekranu: widget nie może negatywnie wpływać na pozycjonowanie i musi być obsługiwany przez czytnik ekranu. Zachowaj w swoim HTML nazwę wydarzenia, datę, miejsce i cenę od.

Podsumowanie

Wbudowany widget to niemal zawsze najlepsza opcja sprzedaży biletów na własnej stronie. Utrzymuje użytkownika w Twojej domenie, wzmacnia Twoją markę i oddaje Ci kontrolę nad pomiarami. Nakład pracy na wdrożenie jest minimalny w porównaniu z korzyściami, ale to nie tylko decyzja techniczna: przycisk z artykułu 98.2 TRLGDCU, dostępność cyfrowa wynikająca z Ley 11/2023 oraz wymogi PCI DSS v4.0.1 obowiązujące od 31 marca 2025 r. to warunki wejścia, a nie opcjonalne usprawnienia. Jeśli Twój dostawca systemu biletowego nie oferuje dobrego widgetu i nie dokumentuje tych trzech punktów, być może warto poszukać innego. Zajrzyj do naszego porównania platform do sprzedaży biletów albo porównaj bezpośrednio Futura Tickets z Eventbrite.

Źródła

• Skonsolidowany tekst hiszpańskiej Ley General para la Defensa de los Consumidores y Usuarios, artykuły 97 i 98 (RDL 1/2007, tekst skonsolidowany) — BOE
• Ley 11/2023 z 8 maja, artykuły 2, 3 i 13 (tekst skonsolidowany) — BOE
• Web Content Accessibility Guidelines (WCAG) 2.2, Rekomendacja z 12 grudnia 2024 r. — W3C
• Content Security Policy Level 3, projekt roboczy z 16 września 2026 r. — W3C
• Just Published: PCI DSS v4.0.1 — PCI Security Standards Council
• PCI Security Standards Council: standardy i biblioteka dokumentów — PCI SSC
• Web Vitals: progi LCP, INP i CLS — web.dev, Google
• Interaction to Next Paint (INP) — web.dev, Google
• Podstawy SEO dla JavaScript — Google Search Central