August 3, 2026
You took your first online deposit, the money landed in your account, and then a small worry set in: am I supposed to be doing something about credit-card security? You've probably seen the phrase "PCI compliant" on a form somewhere and quietly panicked.
Here's the good news, up front. If guests type their card details into a booking widget served by a reputable payment company — not into code that lives on your own website — then you are almost certainly doing the lightest version of this, not the 300-question audit that scares people off. Most operators do far less than they fear.
This guide walks through what PCI compliance actually means for a small tour, activity, or charter business, why the payment setup you already use matters more than anything else, and how to check yours in about four questions. If you just want the short version of the whole thing, we've also written about how to take card payments without the compliance headache.
PCI DSS stands for the Payment Card Industry Data Security Standard. It's a set of rules for handling card data safely, set by the PCI Security Standards Council — a body created by the card brands themselves: Visa, Mastercard, American Express, and Discover.
Two things are worth knowing right away. First, PCI DSS is not a federal law. It's a requirement that comes down through the card brands and your acquiring bank (the bank that lets you accept cards) as part of your agreement to take payments. Second, that doesn't make it optional. Your processor and bank can enforce it, and there are real fees for ignoring it — more on those later.
The standard organizes into 12 core requirements grouped under six goals — build and maintain a secure network, protect cardholder data, run a vulnerability management program, control access, monitor and test your systems, and keep a security policy — according to the PCI DSS Quick Reference Guide published by the Council. That's the full menu. The whole trick for a small operator is landing in the version where only a small handful of those actually apply to you.
PCI DSS sorts merchants into four levels based on how many card transactions you run in a year. As payments specialist Paytia lays them out:
A three-boat charter running a busy season, a walking-tour guide, a dive shop, a food-tour operator — virtually every independent tour and activity business sits comfortably in Level 4, the lightest validation tier. You are not in the same bucket as a national airline, and nobody expects you to behave like one.
One caveat worth taking seriously: a business that suffers a card-data breach can be bumped up to the strictest tier — effectively Level 1 treatment — no matter how small it is, according to compliance firm Secureframe. Your size gets you the easy path; a breach takes it away. That's the whole reason the setup below matters.
For a Level 4 merchant, "doing your PCI compliance" mostly means filling out a Self-Assessment Questionnaire, or SAQ, once a year. You attest to a list of security controls, sign it, and keep it on file for your processor or bank. No auditor camps out at your desk.
Here's the catch that decides how big a job that is: there are several versions of the SAQ, and which one you have to complete depends entirely on how card data flows through your business. Two of them mark the extremes.
SAQ A is the short one. To be eligible, you have to confirm that every element of the payment page shown to your customer comes only and directly from a PCI DSS-compliant third-party service provider, and that you never store, process, or transmit any cardholder data on your own systems or premises. That's the eligibility rule Adyen spells out in its PCI guide, straight from the Council's criteria.
When you qualify, the questionnaire is short — Stripe's setup, for example, typically lands merchants on SAQ A with around 22 requirements, versus the roughly 300 controls of the heaviest form. The systems that touch card data — your "cardholder data environment," or CDE — belong to your payment vendor, not you. So most of the standard simply doesn't apply.
SAQ D is the long one. It covers the full sweep of the 12 requirement families — firewalls, encryption, access control, logging and monitoring, a written security policy, the lot — and heavier scope can also pull in extras like quarterly network scans by an Approved Scanning Vendor (ASV).
You land here when card data actually touches your own website or servers: a custom checkout form that posts card numbers through your site, a spreadsheet with card details, an inbox full of "here's my Visa" emails. Stripe's own documentation notes that businesses handling sensitive card data directly may have to meet more than 300 security controls — but that many can instead use a hosted integration so the data goes straight to the processor and never passes through their systems. Avoiding SAQ D isn't luck. It's a design choice you make when you pick how to collect payment.
This is the part the generic "PCI for small business" articles never explain for our world, so it's worth being plain about.
A hosted booking widget works like this: the box where your guest types their card number is served directly by a PCI DSS-compliant payment company, not built into your own site's code. The card number goes from the guest's browser to that company — through their locked-down systems — and comes back to you as a harmless token, a stand-in reference you can use for refunds and reports. You get the booking and the payout. You never see, store, or handle the actual card number.
Because the card data never enters your systems, your website stays out of the cardholder data environment — and that's exactly the situation SAQ A was written for. The Council's own eligibility criteria, as summarized in a Davis Wright Tremaine analysis, cover three hosted setups: a site fully hosted by a compliant vendor, a page that redirects to one, or a page with an embedded iframe from one — all fine for SAQ A, as long as you never store, process, or transmit card data yourself.
It's also the approach the Council flat-out recommends. Its small-merchant guide tells online sellers that "using a wholly outsourced third party to capture and process payments" is the safest option — and to make sure that third party is a PCI DSS validated provider. If you want the mechanics of how the money actually moves, we've broken down how payment gateways work for tour operators separately.
There's one recent wrinkle worth knowing, because it changes what to ask your provider.
In March 2025 the PCI Security Standards Council issued FAQ 1588 to clarify a point about how the payment box gets onto your page. If your page simply redirects the guest to the payment company's page — a normal redirect, or a fully outsourced payment link — nothing extra is required; you stay on the straightforward SAQ-A path.
But if you embed the payment form as an iframe directly on your own page, you now have to additionally confirm that script-attack protections are in place. You can either implement techniques like those in PCI DSS Requirements 6.4.3 and 11.6.1 yourself, or — far more likely for a small operator — get written confirmation from your payment vendor that their embedded solution already includes those protections. That's it. The practical takeaway is a single question for your booking software provider: do you use a redirect or an embedded form, and if it's embedded, will you confirm the script protections in writing?
Junglebee is built around this hosted model. Guests enter their card details on Junglebee's hosted booking widget and payment page — not in code sitting on your own website.
Who processes the payment depends on where you operate. Outside the Caribbean — the US, Canada, Europe, and beyond — Junglebee's widget runs on Stripe, which is certified annually as a PCI DSS Level 1 service provider by an independent Qualified Security Assessor, the highest level of PCI certification. Inside the Caribbean, where Stripe and PayPal don't connect to most local banks, payments run on Junglebee's own processor, JB Pay, so operators can take cards and get paid out to their bank on their own island.
Either way, the important architectural fact is the same: the card number is captured on the vendor's hosted page, not on yours, which is the whole basis for an SAQ-A scope argument. As with any provider, the right move is to ask for written confirmation of which SAQ applies and how the payment box is delivered — that's a normal, reasonable thing to request. Pairing a hosted widget with a few sensible habits is also the foundation of a chargeback-proof card payment setup.
Hosted payments shrink the job — they don't erase it. Even on the shortest questionnaire, a few things are still on you:
It's tempting for a small operator to assume no one's watching. The stakes say otherwise.
Card brands and acquiring banks can levy non-compliance fines on small and mid-size merchants ranging from roughly $5,000 to $100,000 per month — charged until the gap is fixed — according to compliance platform Compyl. That's before any breach even happens.
And if one does happen, the numbers get worse. IBM's 2025 Cost of a Data Breach Report put the global average breach at $4.44 million; small-business-specific research cited by PurpleSec puts the cost of resolving a smaller incident at roughly $120,000 to $1.24 million. Most damning of all, the Council's own small-merchant guide cites a survey finding that 60% of breached small and medium businesses close within six months — and, per Verizon, that 61% of breaches now hit smaller businesses. A three-boat operation doesn't have a spare $120,000, which is exactly why the hosted setup that keeps card data out of your hands is worth getting right.
You don't need a consultant to get a read on where you stand. Run your setup through these four questions:
If card entry lives on a hosted widget, it's a redirect or a documented iframe, your provider will confirm SAQ-A eligibility, and you never touch raw card numbers — you're in the simplest bucket there is. That's the setup a widget like Junglebee's is designed to give you, alongside Junglebee's pricing (no monthly or setup fees).
Do I need to hire a QSA (Qualified Security Assessor)? Almost certainly not. Qualified Security Assessors are the auditors that top-tier, Level 1 merchants bring in. As a Level 4 operator, you self-assess by completing the SAQ yourself and signing it — no paid auditor required.
Does taking deposits instead of full payment change anything? No. A deposit is still a card payment, so the same rules apply. What matters isn't the amount — it's whether the card is entered on your vendor's hosted page or on your own site. Hosted keeps you in the same light bucket either way.
Does taking a card in person, dockside or at the counter, count? Yes, in-person card payments are their own situation with separate self-assessment forms. Use a card reader from a compliant provider, let the device handle the card, and never write the number down. Keep it off your laptop and out of any spreadsheet.
Is PCI compliance a one-time thing or ongoing? Ongoing. You complete the SAQ each year, and again whenever you change how you take payments — a new website, a new checkout, a new processor. It's a yearly habit, not a one-and-done certificate.
The headline fear — a 300-point audit — is real for businesses that build their own checkout and handle card numbers directly. For a small operator whose guests pay through a hosted booking widget, it simply isn't your situation. Get the payment box off your own code, keep card numbers out of your inbox, sign your SAQ once a year, and you've handled the part that actually matters.
