Is my Bermuda payment page PCI compliant?

Most Bermuda businesses taking card payments online have never been told which PCI questionnaire applies to them, and find out only when the bank asks. The answer is not a matter of opinion or of how careful your developer is. It turns on one technical fact about your payment page, and you can establish that fact yourself right now.

The two-minute test

Open your payment page in a browser, the one where a customer actually types their card number. Right-click and choose View Page Source, or press Ctrl+U, or Cmd+Option+U on a Mac. Then search the source with Ctrl+F for the word card.

You are looking for an <input> tag whose name attribute contains something like card_num, cardnumber, card_number or ccnumber. Three outcomes:

You find one, and the surrounding <form> posts to your own domain. Your web server receives the full card number. This is the case that matters, and it is the one this guide is about.

You find no card field at all. The card entry is almost certainly inside an iframe served by the gateway, which is what you want. The card number goes from the customer’s browser to the gateway and never touches your site.

You find no card field, and the page loads a script from the gateway. Search the source for Accept.js or accept.authorize.net. That is a hosted-fields setup: the fields look like part of your page but belong to the gateway, and the card number is swapped for a token before anything reaches your server. Also what you want.

One caution before you act on this. A page can carry a field named card_something and still be safe if a script converts it to a token in the browser before the form is submitted. If you find a card field, the honest next step is to ask whoever built the page a direct question, not to assume the worst: does the card number reach our server, or is it tokenised in the browser first? A developer who built it properly will answer that in one sentence.

Why the answer changes your paperwork

PCI DSS is not a law. It is a card network requirement that your bank passes on to you, and the way it reaches most small businesses is a self-assessment questionnaire the bank asks you to complete each year. Which questionnaire you get depends on how your payments are set up.

If your website never receives card data, because the entry is in the gateway’s iframe or hosted fields, you qualify for SAQ A. It is the shortest questionnaire that exists, it asks mostly about your business practices rather than your servers, and most Bermuda merchants can complete it honestly in an afternoon.

If your website does receive card data, SAQ A is not available to you and neither is SAQ A-EP, the middle option for sites that influence a payment page without receiving card numbers. You are on SAQ D, the full merchant assessment. It is an order of magnitude longer, and it does not stop at your payment page: it pulls the server, the hosting environment, your logging, your patching and your access controls into scope. If you are on shared hosting, that scope includes a machine you do not control.

This is the whole reason the technical detail matters. The same payment page, built the other way, is the difference between a short annual form and a compliance programme.

What changed in 2025

PCI DSS version 4 added two requirements aimed squarely at payment pages, and both became mandatory on 31 March 2025.

Requirement 6.4.3 says you must know every script that loads and runs on your payment page, authorise each one, justify why it is there, and assure yourself it has not been altered. In practice that means an inventory, kept current.

Requirement 11.6.1 says you must run a mechanism that detects unauthorised changes to your payment page and to its HTTP headers, and alerts you when one happens.

Both exist because of card skimming attacks that work by quietly modifying a payment page, or one of the third-party scripts it loads, so that card details are copied as they are typed. The page looks identical. Nothing breaks. That is the point.

Who they apply to depends on your questionnaire. On SAQ A-EP and SAQ D they apply in full. In January 2025 the PCI Council took them out of SAQ A, but not out of the picture: to qualify for SAQ A you now have to confirm that your site is not susceptible to attacks from scripts that could affect your payments. In practice that means either running the controls these two requirements describe, or getting written confirmation from your gateway that its embedded payment form protects against script attacks.

The practical consequence for a Bermuda business: if your payment page loads fonts, analytics or icon libraries from other people’s servers, and nobody is watching whether those files changed, you cannot honestly make that confirmation, whichever questionnaire you are on. That is worth knowing before your bank asks.

What to do if the answer was the bad one

The fix is not usually a rebuild. Moving card entry off your own page and onto the gateway’s hosted fields is a contained piece of work, and it is the single change that does the most for both your security and your paperwork. The Authorize.Net security checklist explains that lever and the other settings worth checking, ranked by how urgently each one closes a real hole.

Two things worth doing in the same sitting. Ask your bank which SAQ they currently have on file for you, because a mismatch between what you filed and how the site actually works is the problem you want to find yourself rather than have found for you. And ask whoever maintains the site who is watching the payment page for changes, which is the honest version of requirement 11.6.1.

If you are still choosing how to set payments up, what to look for in a Bermuda payment gateway covers the three separate bills behind “payment processing fees”, and our payments page has the current options and pricing for getting a gateway configured properly.

If you ran the test, found a card field, and are not sure what you are looking at, send us the page and we will tell you which of the three cases it is. That costs nothing and takes about as long as reading this did.