Payment Security for Booking Deposits

This guide explains payment security choices for booking websites in plain language. It is not a substitute for guidance from your acquiring bank or payment processor, which decides what you must submit.

Taking a deposit online means handling payment cards, and handling payment cards brings the Payment Card Industry Data Security Standard, usually shortened to PCI DSS. For a small business that sounds daunting, but the most effective step is simple: do not let card numbers touch your own website. This guide explains how that works and what changed for small online merchants in 2025.

Who decides what you must do

PCI DSS is maintained by the PCI Security Standards Council, but the council does not decide which forms an individual merchant submits. Its FAQ on the SAQ A criteria advises merchants to consult the entity that accepts their compliance, typically the acquirer or the payment brands, to determine whether they must submit a self-assessment questionnaire and which one¹. In practice, your payment processor or bank will tell you.

The three ways a booking site can take a card

For booking deposits, the first two approaches are the sensible ones. Building your own card form brings a much larger set of security obligations that rarely make sense for a service business.

SAQ A and the 2025 script criterion

SAQ A is the shortest self-assessment questionnaire, intended for e-commerce merchants who have fully outsourced card handling. The council's blog explains that the revised SAQ A requires merchants to have confirmed that scripts on their site cannot be used to attack their e-commerce systems, with the related PCI DSS v4.0.1 requirements taking effect on April 1, 2025².

Crucially, the council's FAQ says this criterion applies only to merchants whose webpage includes a processor's embedded payment page or form, such as an iframe; it does not apply to merchants who redirect customers to the processor or fully outsource payment, for example by emailing a payment link¹. Merchants who embed a form can meet the criterion either by applying techniques such as those in PCI DSS requirements 6.4.3 and 11.6.1, deployed by themselves or a third party, or by obtaining confirmation from a PCI DSS compliant processor that its embedded solution, implemented as instructed, protects the payment page from script attacks^1,2.

What "scripts" means here

Modern web pages load scripts from many places: analytics, chat widgets, booking tools, fonts and advertising tags. If any of those scripts were tampered with, it could in principle interfere with a payment form on the same page. That is the risk the criterion addresses. A booking page that loads fewer third-party scripts is easier to protect and easier to confirm.

Practical choices for booking websites

1. Prefer a redirect or a processor-confirmed embed. Ask your processor which approach it recommends and whether it provides written confirmation for its embedded form.
2. Keep the payment page lean. Remove chat widgets, heatmaps and advertising tags from the page that hosts the payment step.
3. Use a Content Security Policy. A strict policy that allows only the scripts you expect makes unexpected scripts much harder to run.
4. Serve everything over HTTPS. The whole site, not just the payment step.
5. Limit admin access. Give staff their own logins with only the permissions they need.
6. Keep records. Note which approach you use, the date you set it up and any confirmation your processor gave you.

Deposits, refunds and stored cards

Some booking systems save a card to charge a no-show fee later. When that happens, the card should be stored by the processor, not by your site, and the customer should see the fee and the conditions before they book. Refunds should be issued through the processor's dashboard, which keeps the card details out of your hands. Our guide on deposits and cancellation policies covers how to explain these terms clearly.

Prices still need to be clear

Security is only half the payment step. If you add a mandatory card fee or booking fee, it should be included in the first price shown. The Competition Bureau treats drip pricing as false or misleading, with an exception for government charges such as sales tax³.

A short checklist

• Card numbers never enter your own forms or server.
• Payment through a hosted page or a processor's embedded form.
• If embedded, script protection in place or written processor confirmation obtained.
• Payment page free of unnecessary third-party scripts.
• Strict Content Security Policy and HTTPS everywhere.
• Your acquirer has confirmed which questionnaire you complete.
• Deposit and fee terms shown before payment.

How we set it up

On booking sites we build, payment always runs through your processor's hosted page or its own embedded form, the page that hosts payment carries no unnecessary scripts and the site ships with a strict Content Security Policy. We record the approach in the handover notes so you can answer your acquirer's questions. See payments and deposits for the service details.