When a visitor wants to buy a ticket, there are two options: redirect them to the ticketing platform's website, or show the purchase process embedded within your own site. This seemingly technical decision has brand, analytics and legal consequences: an embedded checkout counts as e-commerce, and three rules apply that are worth knowing before you paste in the script.
What's wrong with redirecting the user to another website?
Redirecting users elsewhere to complete a purchase has hidden costs.
- Friction: every extra click adds a point of abandonment (see how to recover abandoned carts)
- Distrust: leaving your website raises doubts about security
- Lost branding: the user sees the ticketing platform's brand, not yours
- Broken tracking: you lose visibility into user behaviour
- Mobile experience: redirects work worse on mobile, where a good share of sales from social media happens
A note on the numbers. The industry repeats specific abandonment-per-click percentages and conversion improvements, but we haven't found a public study, with methodology and sample size, that backs these up for ticket sales. We won't quote any here: the direction of the effect is well established, but its size depends on your traffic, your event and how the integration is built.
What are the advantages of an embedded widget?
A sales widget integrated into your website solves all these problems.
- No friction: the user never leaves your website
- Your brand: consistent colours, typography and experience
- Better conversion: fewer steps and no domain switches
- Full tracking: you see the whole funnel in your own data analysis tools
- Trust: the user stays on a domain they already know
There's a less-cited but quite concrete advantage: attribution. With a redirect, the session moves to a different domain and the purchase event is logged under the ticketing platform's property, not yours. With an embedded checkout, the conversion happens on your domain, so you can measure it against your campaigns without relying on third-party reports.
What implementation options exist?
There are several ways to embed ticket sales, with different levels of integration.
- iFrame: the simplest approach, inserts the checkout in a frame
- Web component: more flexible, adapts better to your design
- API + custom frontend: full control, more development work
- Popup/modal: opens the purchase flow without leaving the current page
| Approach | Development effort | Design control | Where payment happens |
|---|---|---|---|
| iFrame | Low | Limited to the provider's theme | On the provider's domain |
| Web component | Medium | High, with your own CSS | On the provider's domain |
| API + custom frontend | High | Full | On your domain, unless you delegate the card field |
| Popup or modal | Low | Medium | On the provider's domain |
The choice isn't just cosmetic. The iFrame is governed by the frame-ancestors directive of Content Security Policy, which, according to the W3C's CSP Level 3 working draft of 16 September 2026, "is used to control which origins may embed the current resource in a frame". It's the header your provider must allow so their checkout can load inside your domain, and the one you should review so nobody embeds your site without permission.
A word on SEO. Google documents that it processes JavaScript applications in three phases, "1. Crawling 2. Rendering 3. Indexing", using a headless Chromium instance that runs the code. Even so, the data you want to rank for — event name, date, venue, price from — should sit in your page's HTML, not only inside the widget.
What does the law require of the purchase button?
This is the part most often overlooked, and the one that can void a sale. In the EU, Article 8(2) of Directive 2011/83/EU is explicit:
«If placing an order entails activating a button or a similar function, the button or similar function shall be labelled in an easily legible manner only with the words 'order with obligation to pay' or a corresponding unambiguous formulation indicating that placing the order entails an obligation to pay the trader. If the trader has not complied with this subparagraph, the consumer shall not be bound by the contract or order.»
The UK kept the same rule in regulation 14 of the Consumer Contracts Regulations 2013, and every EU country has written it into its own law: in Spain, for example, it is article 98.2 of the consolidated General Law for the Protection of Consumers and Users.
"Buy", "Continue" or "Finish" on their own are not unambiguous formulations. The consequence set out in the law isn't a fine: it's that the contract doesn't bind the buyer.
The same paragraph adds, just before this, another obligation: the trader must make the consumer aware «in a clear and prominent manner, and directly before the consumer places his order, of the information provided for in points (a), (e), (o) and (p) of Article 6(1)». Point (e) covers price: «the total price of the goods or services inclusive of taxes» and, where applicable, «all additional freight, delivery or postal charges and any other costs». Ticket booking fees can't appear only after the click.
And paragraph 3: «Trading websites shall indicate clearly and legibly at the latest at the beginning of the ordering process whether any delivery restrictions apply and which means of payment are accepted.» If your widget only accepts certain payment methods, that must be stated upfront, not in the final step.
Two things worth tying down contractually with your provider: who controls the wording of that button, and who maintains it if the provider updates their checkout. The seller is liable to the buyer, and Article 6(9) of the directive places the burden of proof for the information requirements on the trader.
Does the sales widget have to be accessible?
In the EU, yes, and there's now a specific rule behind it. Directive (EU) 2019/882, the European Accessibility Act, applies to «e-commerce services» (Article 2(2)(f)) provided to consumers after 28 June 2025, and service providers must only provide services that meet the accessibility requirements in Annex I. The only general exemption is for microenterprises: «Microenterprises providing services shall be exempt from complying with the accessibility requirements» (Article 4(5)).
Each member state transposed it into its own law: in Spain, for example, through Law 11/2023 of 8 May. The UK isn't covered by the directive.
The reference technical standard for compliance is the Web Content Accessibility Guidelines. WCAG 2.2 has been a W3C Recommendation since 12 December 2024. On a ticketing checkout, the usual failure points are concrete: keyboard focus lost on entering the iFrame, error messages flagged only by colour, seat-reservation timers with no warning or extension, and capacity maps with no list alternative. Ask your provider for their accessibility statement before signing; Article 13(2) of the European Accessibility Act requires providers to explain how the service meets the accessibility requirements, and recital 81 places that information «in the general terms and conditions, or in an equivalent document».
What does PCI DSS require of the payment page?
If the widget renders the payment form on your domain, your page falls within the scope of the standard. The PCI Security Standards Council published PCI DSS v4.0.1 in June 2024 and confirmed that this revision "does not impact the effective date of these new requirements": the deferred requirements, including 6.4.3 and 11.6.1 on payment-page scripts, became mandatory on 31 March 2025.
In practice, these two requirements call for inventorying and authorising every script that runs on the payment page, justifying why it's there, and detecting unauthorised changes to headers and content. Translated to an events website: the advertising pixel, the support chat widget and the tag manager sitting alongside the checkout stop being marketing decisions and become security decisions.
The simplest way to narrow that scope is to have the card field live inside the provider's iFrame, not your own HTML. Ask your provider which model they use and what compliance documentation they can provide. The standard itself and its supporting documents are on the PCI Security Standards Council website.
How much can the widget weigh before it tanks your Core Web Vitals?
An embedded widget is third-party code running on your page, and that shows up in the metrics Google uses as a ranking signal. The thresholds are public: according to web.dev, LCP "should occur within 2.5 seconds", CLS should stay at "0.1 or less", and pages "should have a INP of 200 milliseconds or less", all measured at the 75th percentile of page loads.
The detailed breakdown of INP marks the upper boundary: "An INP above 500 milliseconds means a page has poor responsiveness". INP measures the latency of every interaction during a visit, and a seat selector or a session calendar is precisely a sequence of interactions.
Three measures that work without touching the provider's side:
- Load the widget on demand, when the user clicks "Buy tickets", rather than in the
<head>of every page. - Reserve the container's height in CSS before it loads, so the block doesn't push content around and trigger CLS.
- Measure with field data, not just a lab test: the 75th percentile of real users is what counts.
How do you customise the widget with your brand?
The widget should feel like part of your website, not a bolted-on foreign element.
- Colours: match the palette to your brand identity
- Typography: use your own fonts where possible
- Logo: keep your brand visible throughout the process
- Messaging: customised text (buttons, confirmations)
One limit worth knowing: colour contrast is non-negotiable. If your brand palette drops a button or an error message below the WCAG minimum contrast, the widget stops being compliant, however closely it matches your site. The same applies to the purchase button's wording: customisation can't override the requirement in article 98.2 of the TRLGDCU.
Checklist before hiring a widget provider
Nine questions to ask your provider, each with a documented answer.
Can I edit the order-button text? It must read "order with an obligation to pay" or an equally unambiguous formulation. If the text is fixed and ambiguous, that's your problem, not the provider's.
Where is the total price, including booking fees, shown? It must appear before the purchase click, not in the final summary.
Do you have an accessibility statement and WCAG audit results? Ask for the level and the date. Article 13(2) of the European Accessibility Act requires service providers to explain publicly how their service meets the accessibility requirements.
Does the card field render on your domain? The answer determines how much PCI DSS scope you take on.
What PCI DSS compliance documentation do you provide, and from what date? Requirements 6.4.3 and 11.6.1 have been mandatory since 31 March 2025.
What frame-ancestors or X-Frame-Options headers do I need to configure? And which domains you authorise for embedding.
Responsive: the widget must work flawlessly on mobile. Test it on a slow connection and with a keyboard, not just a mouse.
Performance: it shouldn't slow down your page load. Ask for the script's weight and check LCP, CLS and INP with field data before and after installing it.
SEO and screen readers: the widget shouldn't harm your rankings and must be usable with a screen reader. Keep the event name, date, venue and price-from information in your own HTML.
Conclusion
An embedded widget is almost always the best way to sell tickets from your own website. It keeps the user on your domain, reinforces your brand and hands you back control over measurement. The implementation effort is minimal compared with the benefit, but this isn't purely a technical decision: the button rule of Article 8(2) of Directive 2011/83/EU, the European Accessibility Act and the PCI DSS v4.0.1 requirements mandatory since 31 March 2025 are exit conditions, not optional upgrades. If your ticketing provider doesn't offer a decent widget or can't document these three points, it may be time to look elsewhere. See our comparison of ticketing platforms or compare Futura Tickets vs Eventbrite directly.
Sources
- Directive 2011/83/EU on consumer rights, consolidated version, Articles 6 and 8 — EUR-Lex
- The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013, regulation 14 — legislation.gov.uk
- Directive (EU) 2019/882 on accessibility requirements for products and services, Articles 2, 4 and 13 — EUR-Lex
- Spain: consolidated General Law for the Protection of Consumers and Users, article 98, and Law 11/2023 of 8 May — BOE
- Web Content Accessibility Guidelines (WCAG) 2.2, Recommendation of 12 December 2024 — W3C
- Content Security Policy Level 3, working draft of 16 September 2026 — W3C
- Just Published: PCI DSS v4.0.1 — PCI Security Standards Council
- PCI Security Standards Council: standards and document library — PCI SSC
- Web Vitals: LCP, INP and CLS thresholds — web.dev, Google
- Interaction to Next Paint (INP) — web.dev, Google
- JavaScript SEO basics — Google Search Central