What PCI DSS is, and who enforces it
The Payment Card Industry Data Security Standard is written by the PCI Security Standards Council, a body founded by Visa, Mastercard, American Express, Discover and JCB. It is not a law. It is a contractual requirement: the card networks require acquirers to ensure their merchants comply, and your merchant agreement passes the obligation to you. Enforcement runs the same direction. If card data is stolen from your business, the networks fine the acquirer, and the acquirer bills you.
The current version is PCI DSS v4.0.1. Version 4.0 replaced 3.2.1 in March 2024, and the requirements that were "future-dated" in 4.0 became mandatory on 31 March 2025. The standard has twelve requirements grouped under six goals:
| Goal | Requirements |
|---|---|
| Build and maintain a secure network | 1. Network security controls (firewalls). 2. Secure configurations, no vendor defaults. |
| Protect account data | 3. Protect stored account data. 4. Strong cryptography for cardholder data in transit over public networks. |
| Maintain a vulnerability management program | 5. Protect against malware. 6. Develop and maintain secure systems and software. |
| Implement strong access control | 7. Restrict access to need-to-know. 8. Identify users and authenticate access. 9. Restrict physical access. |
| Monitor and test networks | 10. Log and monitor all access. 11. Test security of systems and networks regularly. |
| Maintain an information security policy | 12. Support information security with organizational policies and programs. |
Read in full, that is several hundred controls. Almost none of them apply to a business whose systems never see a card number, which is the whole point of the next two sections.
The data the standard protects
PCI DSS cares about two classes of data, and treats them very differently.
| Class | Elements | Rule |
|---|---|---|
| Cardholder data | Primary account number (PAN), cardholder name, expiration date, service code | May be stored if needed, but the PAN must be rendered unreadable (encryption, truncation, tokenization or hashing) wherever it is stored, and masked when displayed. The name, expiry and service code are only protected when stored together with the PAN. |
| Sensitive authentication data | Full magnetic stripe or chip data, the card security code (CVV2, CVC2, CID), PIN and PIN block | Never stored after authorization, even encrypted, even for a minute, with no exceptions for merchants. This is the rule most often broken by well-meaning staff writing a security code on an order form "until we run it". |
Masking rules: when a PAN is displayed, at most the first six (or, since v4, the first eight, to accommodate longer BINs) and the last four digits may be shown, and only to people with a business need to see them. The last four alone is the norm on receipts and in software.
Two practical consequences. First, if your business stores full card numbers anywhere, in software, spreadsheets, paper files, email or voicemail, all of requirement 3 applies and your questionnaire is the long one. Second, a card security code written on a paper order form is a violation regardless of what happens to it later. The way to stay out of both problems is not to have the data.
Scope: the only word that matters
PCI DSS applies to the cardholder data environment: every system that stores, processes or transmits cardholder data, plus every system connected to those or able to affect their security. Compliance effort is proportional to the size of that environment. A business where the environment is "one iPad running a certified terminal app" has a small job. A business where the environment is "the office network, because card numbers are typed into a browser on any workstation" has a large one.
The ways to keep the environment small, in rough order of how much they help:
- Outsource the payment page. When a customer pays on a page served entirely by a PCI-compliant provider, whether by redirect or in an iframe embedded on your site, the card number goes from the customer's browser to the provider and never passes through your web server. Your site is out of scope for the transmission, and you qualify for the shortest questionnaire.
- Send links instead of taking numbers. A phone customer who receives a text or email link and pays on the hosted page has removed your staff, your phones and your workstations from scope. A phone customer who reads out a card number that staff type into a virtual terminal has put them in.
- Tokenize. Store a token issued by the provider's vault instead of the card. Repeat charges, refunds and subscriptions run against the token, and nothing in your systems can be used to make a purchase if stolen. Covered in its own section below.
- Use validated point-to-point encryption (P2PE) terminals for in-person payments, which encrypt at the card reader so the data passing through your network is unreadable.
- Segment the network. If some systems must handle card data, isolate them so the rest of the business is out of scope. This is the expensive option and the last resort.
The test to apply to any process in the business: could a person doing this job write down a full card number? If yes, that process is in scope, and the question is whether it can be redesigned so the answer is no.
Merchant levels and the self-assessment questionnaires
How you demonstrate compliance depends on your transaction volume (your level) and on how you accept cards (which SAQ applies).
Levels
| Level | Annual Visa or Mastercard transactions | Validation |
|---|---|---|
| 1 | More than 6 million, or any merchant that has suffered a breach | Annual on-site assessment by a Qualified Security Assessor, producing a Report on Compliance; quarterly network scans by an Approved Scanning Vendor |
| 2 | 1 million to 6 million | Annual self-assessment questionnaire (Mastercard may require it to be completed with a QSA), quarterly ASV scans |
| 3 | 20,000 to 1 million e-commerce transactions | Annual SAQ, quarterly ASV scans where the SAQ requires them |
| 4 | Fewer than 20,000 e-commerce transactions, or up to 1 million transactions in total | Annual SAQ, quarterly ASV scans where the SAQ requires them; validation requirements set by the acquirer |
Levels are defined per card brand and are broadly aligned. Nearly every small and mid-sized business is Level 4 or 3.
Questionnaires
Each SAQ is a subset of the full standard matched to one way of accepting cards. Pick the one that describes you, or, if more than one does, the longest that applies.
| SAQ | Who it is for | Approximate size | ASV scans |
|---|---|---|---|
| A | Card-not-present merchants (e-commerce or mail/phone) who have fully outsourced all cardholder data functions to a validated third party: the payment page is delivered by the provider (redirect or iframe), and the merchant stores, processes and transmits no cardholder data on its own systems. Since January 2025 the merchant must also confirm its website is protected against script attacks that could affect the payment page. | About 30 questions | Not required by the SAQ itself; the acquirer may still require them |
| A-EP | E-commerce merchants whose website does not itself receive card data but affects the security of the payment transaction: typically a payment form on the merchant's page that posts directly to the processor, or JavaScript from the merchant site that touches the form. | About 150 questions | Quarterly |
| B | Merchants using only imprint machines or standalone dial-out terminals, with no electronic storage of card data. | About 40 questions | Not required |
| B-IP | Merchants using only standalone, PTS-approved terminals with an IP connection to the processor, no electronic storage. | About 80 questions | Quarterly |
| C-VT | Merchants who manually key card numbers into a virtual terminal in a browser, on a single isolated computer, one transaction at a time, with no electronic storage. | About 80 questions | Not required |
| C | Merchants with a payment application (point-of-sale software) connected to the internet, no electronic storage. | About 160 questions | Quarterly |
| P2PE | Merchants using only a validated point-to-point encryption solution, no electronic storage. | About 30 questions | Not required |
| D (merchants) | Everyone else, including any merchant that stores cardholder data electronically, or whose acceptance methods do not fit a shorter SAQ. | About 250 questions | Quarterly |
Question counts are approximate for the v4 questionnaires and change with revisions.
The pattern is obvious once the table is laid out. Hosted payment pages and payment links put a business in SAQ A; a virtual terminal on a dedicated machine puts it in C-VT; anything that stores card numbers puts it in D. The difference between A and D is a morning versus a quarter of a year, every year.
The annual cycle
- Confirm which SAQ applies, and whether anything changed since last year (a new website, a new terminal, a new way of taking phone orders).
- Answer the questionnaire honestly. "Not in place" answers need a remediation plan, and lying on an SAQ shifts breach liability entirely onto the business.
- Run quarterly ASV scans if the SAQ requires them, and pass them (no high-severity findings).
- Sign the Attestation of Compliance and submit it to the acquirer, usually through a compliance portal the processor provides.
- Keep the evidence: policies, training records, scan reports, the list of third parties and their attestations.
The v4 payment-page rules: 6.4.3 and 11.6.1
Version 4 added two requirements aimed at a specific attack: criminals injecting a few lines of JavaScript into a checkout page so that card numbers are copied to a third party as the customer types them. The page still works, the payment still goes through, and the theft is invisible to both the merchant and the processor. The requirements apply to any merchant whose page delivers or affects the payment form, which is SAQ A-EP and SAQ D e-commerce merchants; since the January 2025 revision, SAQ A merchants instead attest that their site is protected against this class of attack, in practice by relying on the provider's hosted page and its controls.
| Requirement | What it says | How it is typically met |
|---|---|---|
| 6.4.3 | All scripts that load and run on payment pages are managed: there is a method to confirm each script is authorized, a method to assure the integrity of each script, and a written inventory of every script with a justification for why it is necessary. | A maintained list of every script on the checkout page and where it comes from; Content Security Policy headers that only allow those sources; Subresource Integrity hashes on scripts served from third parties; a review whenever the page changes. |
| 11.6.1 | A change-and-tamper detection mechanism is deployed that alerts personnel to unauthorized modification (including indicators of compromise, changes, additions and deletions) to the HTTP headers and the script contents of payment pages as received by the consumer browser. It runs at least weekly, or at a frequency justified by a risk analysis. | A monitoring service that loads the page as a browser would, records every script and header, and alerts on any difference from the approved baseline. Server-side file monitoring does not satisfy it, because the injected script may only appear in the browser. |
Neither requirement is hard once the checkout is small and the script list is known. Both are effectively impossible on a page that loads dozens of marketing tags. The practical advice: put the payment form on its own page, or in a provider-hosted iframe, with the minimum of scripts, and let the provider carry the monitoring. FloPay's hosted checkout is built to that pattern and runs 11.6.1 tamper detection on the page it serves.
Tokenization: what it is and what it is not
A token is a substitute value that stands in for a card number in your systems. The provider stores the real number in a vault, returns a token, and accepts the token in place of the number for future charges, refunds and updates. If your database is stolen, the thief has tokens that work only with your provider, only for your merchant account, and are worthless anywhere else.
Three distinctions matter when choosing how to tokenize:
| Type | Issued by | Works with | Notes |
|---|---|---|---|
| Gateway or processor token | Your payment gateway or processor | That gateway only | The most common form. Simple, but the tokens are the reason switching processors means re-collecting every stored card. |
| Provider-agnostic vault token | An independent vault that connects to many processors | Any processor the vault supports | The vault holds the card once and can present it to whichever gateway you route to. This is what "agnostic tokenization" means on FloPay's tokenization page: the vault is a PCI DSS Level 1 service provider, and FloPay itself never holds the number. |
| Network token | Visa, Mastercard, Amex or Discover through their token services | Any participating processor, for that card brand | Issued by the network with a domain restriction to your merchant; the network updates it when the card is reissued, and issuers tend to approve network-tokenized transactions at slightly higher rates. Usually obtained through a gateway or vault rather than directly. |
What tokenization does not do: it does not protect the moment of capture. If a card number is typed into your own web page before it is tokenized, that page is in scope. Tokenization reduces the storage problem; hosted capture reduces the transmission problem; you want both. And tokenization is not encryption: an encrypted card number can be decrypted with the key and is still cardholder data in scope; a token cannot be reversed into a number outside the vault, and is not.
What compliance costs, and what a breach costs
Compliance
| Item | Typical cost | Notes |
|---|---|---|
| SAQ and attestation | Staff time: a few hours for SAQ A, days to weeks for SAQ D | Most processors provide a portal that walks through the questionnaire. |
| ASV scans | $100 to $300 per quarter where required | Often bundled by the processor. |
| "PCI compliance fee" on the statement | $5 to $20 per month | Charged by many processors for the portal and scans; see reading your merchant statement. |
| "PCI non-compliance fee" | $20 to $40 per month, sometimes more | Charged when you have not submitted an attestation. Avoidable by submitting one. |
| QSA assessment (Level 1 only) | $20,000 to well over $100,000 | Not relevant below 6 million transactions. |
A breach
| Item | Typical cost | Notes |
|---|---|---|
| Forensic investigation by a PCI Forensic Investigator | $10,000 to $100,000 or more | Mandatory after a suspected compromise; the merchant pays. |
| Card brand assessments | $5,000 to $100,000 per month of non-compliance, per brand | Levied on the acquirer and passed through under the merchant agreement. |
| Reissuance and fraud recovery | $3 to $5 per card reissued, plus fraud losses on compromised cards | Charged back through the acquirer. |
| Mandatory Level 1 validation afterward | The QSA assessment cost above | A breached merchant is treated as Level 1 regardless of volume. |
| Termination and MATCH listing | The ability to accept cards | The acquirer may close the account and list the business, which other acquirers check. |
The asymmetry explains the design advice in this guide. A small business cannot afford a breach and does not need to be exposed to one, because the tools that take it out of scope are the same hosted pages and tokens the processors already provide.
A compliance program for a small business
For a business with under a million transactions a year, a workable program fits on one page.
- Decide that card numbers never enter your systems. Hosted checkout for the website, payment links for phone and email customers, certified terminals or a P2PE solution in person, tokens for anything stored. Write it down as policy.
- Retire the exceptions. Find the spreadsheet of card numbers, the paper forms, the voicemail box where customers leave card details, the shared inbox where cards arrive by email. Delete, shred, and replace each with a link the customer completes.
- If staff must key cards (some customers will insist), do it in a virtual terminal on a dedicated computer that is not used for email or browsing, and accept that you are SAQ C-VT. Better: read the customer the text-to-pay consent script and send a link.
- Train everyone who talks to customers, once a year, on two rules: never write a card number down, never store a security code. Keep the attendance record.
- Keep a list of every third party that touches card data on your behalf (gateway, vault, terminal provider, invoicing platform), and collect their Attestation of Compliance annually. Requirement 12.8 asks for this and SAQ A depends on it.
- Complete the SAQ every year, run scans if required, submit the attestation, and put the renewal date in the calendar. Confirm the non-compliance fee has disappeared from the statement.
- Review scope whenever something changes: a new website, a new POS, a new employee workflow, a new way of taking payments. The scope creeps in through convenience.
Where FloPay fits
FloPay is designed so that a merchant using it stays in the smallest scope. Cards are captured on a hosted checkout served by the platform, whether reached by link, iframe or text, and stored as tokens in a provider-agnostic, PCI DSS Level 1 vault that works across every connected gateway, so switching processors does not mean re-collecting cards. The virtual terminal exists for staff who must key a card, and the rest of the platform exists so they rarely have to. The hosted page carries the script inventory and tamper detection that 6.4.3 and 11.6.1 require.
Stay in SAQ A without thinking about it
Hosted checkout, payment links by text and email, and a provider-agnostic token vault mean card numbers never touch your systems. Ask us how your current payment flows would map to PCI scope.
See Tokenization