PCI DSS compliance — what merchants need to know

4 min read

Quick answer #

PCI DSS (Payment Card Industry Data Security Standard) is the global security standard for businesses that handle credit card data. Pay@ Gateway is PCI DSS Level 1 certified — the highest level — which means most merchants who use our hosted checkout don’t need to worry about PCI compliance themselves. You’ll likely qualify for the simplest compliance level (SAQ A), which is a short self-assessment questionnaire, not a full audit.

What PCI DSS is, in plain language #

Anyone who processes, stores, or transmits credit card data has to comply with PCI DSS. The standard is set by the major card networks (Visa, Mastercard, Amex, Discover, JCB) and enforced through the merchant’s acquiring bank.

PCI compliance has 12 broad requirements covering things like firewalls, encryption, access control, and regular security testing. The level of compliance you need depends on how much card data your business actually touches — which depends on how you accept payments.

The four PCI compliance levels (SAQ types) #

Most SA merchants fall into one of these:

Level	When it applies	What’s required
SAQ A	You never touch card data. Customer enters card on Pay@’s hosted checkout or via an iframe.	Short self-assessment (~22 questions). Easy.
SAQ A-EP	Card data passes through your site but you don’t store it (using JavaScript-based integration).	Longer self-assessment (~191 questions) + quarterly network scans.
SAQ D	You handle card data on your servers in any form.	Full assessment, often requires a Qualified Security Assessor (QSA).
Level 1	Processing >6M card transactions per year.	Annual on-site audit by a QSA.

Which level you’ll be on with Pay@ Gateway #

For the vast majority of Pay@ merchants — anyone using our hosted checkout, the WooCommerce or Shopify plugins, or our standard JavaScript SDK — you’ll be on SAQ A.

SAQ A is the simplest possible PCI compliance level. The customer enters their card details directly on Pay@’s payment page or in an iframe served by Pay@. Card data never touches your server. You answer about 22 yes/no questions, sign the form, and submit annually to your acquiring bank.

For most SME merchants, SAQ A takes about 30 minutes to complete each year.

When you might need a higher level #

A small number of merchants need SAQ A-EP or higher. This applies if:

You’re using Pay@’s direct API integration where customer card details are submitted from your server to Pay@’s API (rather than via the hosted checkout). This is sometimes used by Enterprise merchants for custom checkouts.
You’re storing card numbers for any reason (you shouldn’t be — Pay@ tokenises cards so you store a safe token instead of the raw number).
You’re a marketplace processing on behalf of sub-merchants.

If any of these apply, contact our Enterprise team — we provide PCI guidance and can connect you with a QSA if needed.

What Pay@ does to be PCI compliant #

Pay@ Gateway is certified at PCI DSS Level 1, the highest level. This means we undergo an annual on-site audit by a Qualified Security Assessor and maintain extensive technical controls including:

Network segmentation between systems that touch card data and those that don’t
Encryption of cardholder data at rest and in transit
Tokenisation so merchants get a non-sensitive reference instead of a card number
Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV)
Penetration testing at least annually
Strict access control, logging, and monitoring

You can request a copy of our Attestation of Compliance (AOC) for your own audit records by contacting support.

Common PCI mistakes merchants make #

Three things that put merchants in a higher compliance bracket than they need to be in:

Storing card numbers in your CRM. Don’t do this. Use the customer ID and Pay@’s tokenised reference instead.
Taking card details over the phone. This is technically MOTO (Mail Order / Telephone Order) and has its own compliance requirements. Better to send the customer a secure payment link instead.
Sending card numbers by email. Never. Both you and the customer should treat this like a security incident.