Do I have to pay extra to be PCI DSS compliant?

In most cases it isn't a separate added cost: if payment happens on a page hosted by the vendor or through an iframe, what falls on you is filling in a self-assessment questionnaire (SAQ A), not a paid audit. It becomes a real cost only if the vendor has you step deeper into the payment flow, because then the required self-assessment (SAQ A-EP) is far more extensive.

Who prepares the GDPR agreement with the booking engine vendor?

In most cases the vendor itself: the main booking engines publish a standard Data Processing Agreement in their own legal section, ready to sign. What's left for you is checking that it actually exists and covers at least the minimum content required by GDPR article 28, not signing a generic line in the terms of sale and mistaking it for the same thing.

If a guest asks to withdraw within 14 days of booking, do I have to accept?

No. Article 59 of Italy's Consumer Code expressly excludes accommodation supplied for a specific date from the withdrawal right that applies to other distance purchases. Offering a free cancellation window up to a certain date remains entirely your own commercial choice, not a legal requirement.

Is the vendor's PCI DSS confirmation enough on its own?

It covers their part, not automatically yours. If the integration is a pure redirect or iframe, the vendor's confirmation is normally what you need to complete your own SAQ A. If the integration goes deeper, check with them which self-assessment applies to you before you sign, not after.

Do these obligations still apply if the booking engine is bundled into the PMS subscription?

Yes, in the same way: whoever processes your guests' data and whoever collects the card payment is the same party, whether it's bundled into one subscription or invoiced separately. What changes is how many invoices you receive, not the obligations that sit with you as the data controller.

How much does a booking engine cost?

The pricing models and the vendors that publish a price list are laid out in another article, together with the questions worth asking before signing a quote. This piece was about a different part, the one no product comparison names.

Hotel booking engine: the legal obligations no vendor comparison names

27 July 2026

A guest hands over a wallet and a smartphone at a hotel front desk, next to the service bell

Whoever compares booking engines, or IBEs in the industry acronym, almost always looks at two things: what it costs and what it does. Price and features are the right question, but they start one step too far ahead. Before putting two vendors side by side there are three points that aren't product features: they're obligations that fall on you, the property signing the contract, whichever engine you pick. None of the product comparisons out there name them.

Card payments put you in PCI DSS scope regardless

The engine collects the card payment on your site, even when it does so through a page hosted by the vendor or an iframe you never touch directly. That still puts you in the scope of PCI DSS (Payment Card Industry Data Security Standard), the security standard the card networks require of anyone accepting card payments. The PCI Security Standards Council states this without ambiguity: the standard applies to all entities involved in payment processing, regardless of size or transaction volume (source: pcisecuritystandards.org/merchants, checked 27 July 2026).

It doesn't mean handling everything yourself. If payment happens entirely on the vendor's page, through a redirect, or via an iframe you never touch directly, the self-assessment that applies to you is the lightest one, SAQ A (Self-Assessment Questionnaire A): a few dozen requirements, not a paid audit. If the engine steps deeper into the flow, for instance with a script that touches the payment form before it's submitted, the questionnaire moves up to SAQ A-EP, far more extensive. A Council clarification from 28 February 2025 (FAQ 1588) added a detail worth knowing: anyone using an iframe also has to show, directly or through written confirmation from the vendor, that the payment page is protected against malicious scripts. Without that confirmation, eligibility for the lighter questionnaire falls away.

The question to ask in a demo, before even looking at the price: does payment happen on your hosted page or through an iframe, and will you give me the written compliance confirmation my self-assessment needs? A vendor who answers with a generic "we're PCI DSS compliant" without specifying how payment is integrated is answering a different question from the one you asked.

The vendor processes your guests' data on your behalf: you need a written agreement

Guest names, contact details, and sometimes payment data pass through the booking engine before they reach you. In that step, the vendor doesn't decide why and how to process that data: you do. Under the GDPR (Regulation (EU) 2016/679) this makes the vendor a "processor" and you the "controller". Article 28 of the regulation leaves no room: there must be a written contract, including in electronic form, between controller and processor setting out at least the subject matter, duration, nature and purpose of the processing, the type of data involved, and a set of guarantees that include documented instructions the vendor must follow, confidentiality, security measures, the use of any sub-processors, assistance in the event of a data breach, and what happens to the data once the contract ends.

This isn't a large-company detail. Italy's data protection authority, the Garante per la protezione dei dati personali, in a clarification note dated 29 April 2026 on the processing of guests' identity documents in accommodation businesses, explicitly points to the appropriate regulation, under article 28 of the GDPR, of the relationship with providers of hotel booking management services, specifying how important it is to define the terms of processing and what happens in the event of a data breach.

This agreement, often called a DPA (Data Processing Agreement), is almost always a standard form the vendor makes available: the main ones publish it in their own legal section, and signing it takes a moment. The point isn't the effort of signing it, it's checking that it actually exists and that the vendor hasn't buried a generic line inside the terms of sale instead.

Your guest doesn't get 14 days to change their mind, and it isn't your call

Anyone who sells online knows the 14-day withdrawal right that consumer law grants to distance purchases. For a hotel room booking, that right doesn't exist, and it's the law itself that excludes it, not a clause of yours. Article 59, paragraph 1, letter n) of Italy's Consumer Code (Legislative Decree 206/2005) lists among the exceptions to withdrawal the supply of accommodation for non-residential purposes when the contract provides for a specific date or period of performance: exactly the case of a stay with fixed check-in and check-out dates.

It's worth stating this somewhere visible on your booking engine, not because you should fear a dispute, but for the opposite reason: it's a point in your favour that almost no property communicates, and stating it clearly avoids the common misunderstanding of a guest expecting to cancel for free within two weeks, the way they would with an order on any e-commerce site.

Be careful not to confuse this with your cancellation policy: that remains your own commercial choice, free and unrelated to the law. You can offer free cancellation up to the day before, or a non-refundable rate: that's a contractual condition you decide. The legal withdrawal right, on the other hand, simply doesn't apply to your sector, and your booking terms should say so plainly rather than leave it to be inferred.

The three points, in one table

Obligation	Where it's written	What happens if it's missing
PCI DSS compliance on card payments	PCI DSS standard, PCI Security Standards Council	Your acquirer, the bank that lets you accept cards, can suspend card acceptance or apply contractual penalties
Written agreement with the vendor, under GDPR art. 28	Regulation (EU) 2016/679, article 28	Guest data processed without an adequate contractual basis, controller liability in the event of an audit or a breach
14-day withdrawal right	Excluded by article 59, paragraph 1, letter n), Italy's Consumer Code	None: it's an exclusion in your favour, not a risk to manage

The rest is a product comparison, not an obligation

Integration with the PMS and the channel manager, how fast and how the booking page looks, handling deposits and no-shows, upselling, multiple languages: this is where engines genuinely differ, and it's where comparing vendors is worth the time. The pricing models, the four vendors that publish a public price list against those that quote only on request, and the questions worth asking before signing, are already laid out in how much does a hotel website cost: this piece was about the part that article didn't cover.

Where to start

If you're about to sign with a booking engine vendor, before even looking at the monthly fee ask three things: how card payment is integrated and which PCI DSS self-assessment applies to you as a result, whether they hand you a GDPR article 28 agreement to sign or whether it's on you to ask for one, and check that your booking terms clearly state the 14-day withdrawal right doesn't apply. Three questions that take five minutes and matter more than comparing two price lists.

If you'd like someone to look at your booking engine alongside everything else, website, PMS, channels, with this method, there's the digital check-up. Otherwise write to me: the vendor's name and a couple of lines on how it takes payment are enough for a quick read on what's missing.