If your business touches a credit card number at any point, whether you swipe it, tap it, key it in, or simply pass it to a processor, you are operating inside the world of PCI compliance. For merchants, ISVs, and payment engineers alike, understanding the Payment Card Industry Data Security Standard is not optional. It is the baseline that keeps cardholder data safe and keeps your business out of regulatory and financial trouble.
This guide breaks down what PCI is, the compliance levels that apply, how to choose the right validation path, and how to actually stay compliant year-round. We also cover the broader security and certification work that surrounds PCI, and how the team at Paying.co supports it.
What Is PCI DSS?
PCI DSS stands for the Payment Card Industry Data Security Standard. It is a set of security requirements created and maintained by the PCI Security Standards Council, a body founded by the five major card brands: Visa, Mastercard, American Express, Discover, and JCB.
The standard exists for one reason: to protect cardholder data anywhere it is stored, processed, or transmitted. Every organization that handles payment cards is expected to meet these requirements, from a single-location coffee shop to a global payment processor.
The current version, PCI DSS 4.0.1, is built around six core goals and twelve high-level requirements:
→ Build and maintain a secure network and systems
→ Protect stored account data
→ Maintain a vulnerability management program
→ Implement strong access control measures
→ Regularly monitor and test networks
→ Maintain an information security policy
A common misconception is that PCI is a law. It is not. It is a contractual obligation enforced by the card brands and acquiring banks. The penalties for non-compliance, however, can feel very much like the law caught up with you.
The Four PCI Compliance Levels
Not every business carries the same compliance burden. Your level is determined primarily by the volume of card transactions you process annually. The more transactions you handle, the more rigorous your validation requirements become.
Level 1
✦ More than 6 million transactions per year (Visa/Mastercard)
✦ Also applies to any merchant that has suffered a data breach
✦ Requires an annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA) or internal auditor
✦ Quarterly network scans by an Approved Scanning Vendor (ASV)
Example: A national retail chain or a large payment processor.
Level 2
✦ 1 million to 6 million transactions per year
✦ Requires an annual Self-Assessment Questionnaire (SAQ)
✦ Quarterly ASV scans
Example: A mid-sized regional e-commerce retailer.
Level 3
✦ 20,000 to 1 million e-commerce transactions per year
✦ Requires an annual SAQ
✦ Quarterly ASV scans
Example: A growing online-only merchant.
Level 4
✦ Fewer than 20,000 e-commerce transactions, or up to 1 million total transactions per year
✦ Requires an annual SAQ
✦ Quarterly ASV scans recommended
Example: A small local business or boutique shop.
A quick note worth remembering: thresholds vary between card brands. American Express, for example, sets its Level 1 cutoff at 2.5 million transactions rather than 6 million, and your acquiring bank has the final say on which level applies to you. When in doubt, ask your acquirer directly.
Understanding the SAQ Types
For most merchants below Level 1, compliance is validated through a Self-Assessment Questionnaire. The right SAQ depends on how you accept payments and how much you touch cardholder data:
♦ SAQ A — Card-not-present merchants who fully outsource all cardholder data handling to a PCI-compliant third party
♦ SAQ A-EP — E-commerce merchants who outsource payment processing but whose website affects transaction security
♦ SAQ B — Merchants using standalone dial-out terminals or imprint machines, no electronic storage
♦ SAQ B-IP — Merchants using standalone, IP-connected payment terminals
♦ SAQ C — Merchants with payment application systems connected to the internet
♦ SAQ C-VT — Merchants who key transactions through a virtual terminal on one computer
♦ SAQ D — All other merchants and all service providers; the most comprehensive questionnaire
Choosing the wrong SAQ is one of the most common compliance mistakes. The goal of modern payment architecture is to reduce your scope so you qualify for the simplest possible SAQ.
A Note on Service Providers
If your business can affect the security of another organization's payment data, you are considered a service provider, even if you never directly store or transmit card numbers. SaaS platforms, payment application vendors, and hosting providers frequently fall into this category. Service providers validate through an SAQ D for Service Providers or a Report on Compliance, and merchants are required to confirm their providers' compliance annually, usually by collecting an Attestation of Compliance. If you build payment software or integrate into a merchant's environment, this almost certainly applies to you.
How to Stay Compliant
Compliance is not a one-time certificate you frame on the wall. It is a continuous discipline. Here is how to keep your program healthy throughout the year.
1. Reduce your scope
The less cardholder data you store, process, or transmit, the smaller your compliance footprint. Use tokenization and point-to-point encryption (P2PE) so that raw card data never lives in your environment. A tokenized card number is useless to an attacker.
2. Never store what you do not need
Sensitive authentication data such as the full magnetic stripe, CVV, or PIN must never be stored after authorization. This is one of the most frequently cited violations and one of the easiest to avoid.
3. Segment your network
Isolate your cardholder data environment (CDE) from the rest of your corporate network. Proper segmentation dramatically shrinks the systems that fall in scope and limits the blast radius if something goes wrong.
4. Patch, scan, and test
✓ Run quarterly ASV scans
✓ Conduct annual penetration testing
✓ Apply security patches promptly
✓ Maintain and test your incident response plan
5. Enforce strong access control
Apply the principle of least privilege, require multi-factor authentication for all access into the CDE, and assign unique IDs so every action is traceable to an individual.
6. Treat compliance as continuous
PCI DSS 4.0 leans heavily on the idea of "business as usual." Build security checks into your daily operations rather than scrambling once a year before an audit.
Beyond PCI: The Wider Security Picture
PCI compliance rarely stands alone. It sits inside a broader payment security program, and the gaps that cause failed assessments or data breaches usually live in the areas around it. This is where Paying.co does some of its most valuable work. Paying.co, part of Mojave Payment Technologies, has been providing payment engineering and security expertise since 2018.
Security and PCI Compliance Services
Achieving compliance is easier when your security program is built for it from the start, and easier still when someone has your back the moment something breaks. Paying.co keeps payment businesses secure and compliant through three pillars: proactive security, audit and compliance, and remediation. We watch your environment before an audit, we work alongside your Qualified Security Assessor through the assessment itself, and when findings come back we fix them and get you back to compliant.
Our approach is QSA-aligned and built on the same AI-driven scanning and manual verification rigor as our testing platform. We coordinate directly with your QSA rather than around them, prepare the evidence and documentation that audits actually require, and support you across the full PCI lifecycle. We are PCI DSS 4.0 ready and partnered with all major QSAs and security firms.
Coverage spans eight domains that matter for payment infrastructure:
✦ Network security
✦ Web application security
✦ Mobile security
✦ Cloud security
✦ PCI DSS
✦ Access controls
✦ Policy and governance
✦ Continuous monitoring
A real engagement runs end to end: initial assessment, gap analysis, remediation plan, QSA coordination, final certification, and ongoing support with continuous monitoring once you are compliant. Because we build payment infrastructure ourselves, from EMV Level 3 certifications to SoftPOS and unattended systems, we understand exactly where card data enters your environment and how to keep it out of scope. And with 24/7 incident response, we are not just there when something breaks; we are there to keep it from breaking.
→ Learn more: paying.co/security-pci-compliance
Penetration Testing
Annual penetration testing is a PCI DSS requirement for many environments, but its real value goes further. Paying.co runs both external and internal penetration testing through Flaw.co, our purpose-built platform that pairs AI-driven scanning with human-driven exploitation. The scanner handles scale, continuously surfacing weaknesses across the full attack surface, while senior testers chase down the depth: the manual, business-logic, and chained exploit paths automated tools never reach.
We cover the full perimeter and the full interior, across eight domains that matter for payment infrastructure:
✦ Network penetration
✦ Web applications
✦ Mobile apps
✦ Cloud infrastructure
✦ Wireless networks
✦ Infrastructure
✦ Social engineering
✦ PCI compliance validation
Every engagement runs from free initial consultation to a certification-ready report, with remediation planning, retesting, and continuous coverage built in. The documentation is designed so your QSA accepts it on the first pass, mapped to PCI DSS 4.0, Visa AIS, Mastercard SDP, American Express DSOP, and Discover DISC. You get actionable, prioritized findings rather than a wall of unsorted alerts, so your engineering team knows exactly what to fix and in what order.
→ Learn more: paying.co/penetration-testing
Where Else We Help
✦ EMV Level 3 certifications across major processors and hardware partners, with 131+ completed certifications
✦ SoftPOS and MPoC implementations that move acceptance onto commercial off-the-shelf devices
✦ Unattended and kiosk payment systems, including self-service and vending environments
✦ Custom Android payment applications built for secure, certified acceptance
✦ AI-driven payment infrastructure for fraud scoring, estimation, and project intelligence
Frequently Asked Questions
Is PCI compliance required by law?
No. PCI DSS is a contractual requirement from the card brands and acquiring banks, not a government regulation. Non-compliance can still trigger fines, higher fees, and loss of your ability to accept cards.
How often do I need to validate compliance?
Validation is an annual exercise, with quarterly network scans required for most environments. PCI DSS 4.0 emphasizes continuous, business-as-usual security rather than once-a-year preparation.
Does using a compliant processor make me compliant?
Not automatically. Even when you rely on a PCI-compliant processor or platform, you remain responsible for your own implementation, which may still require a self-assessment and vulnerability scans.
What is the fastest way to reduce my PCI burden?
Reduce scope. Tokenization and point-to-point encryption keep raw card data out of your environment entirely, often qualifying you for a far simpler SAQ.
Talk to Our Team
Navigating PCI scope, terminal certifications, penetration testing, and secure payment architecture is exactly the kind of work we do every day. Paying.co, part of Mojave Payment Technologies, has specialized in payment engineering and security since 2018. Whether you are preparing for an assessment, building new payment infrastructure, or trying to shrink your compliance footprint, our engineering team can help you do it right from the ground up.
→ Book a meeting with our team: meet.paying.co
→ Contact sales for more information: paying.co/contact-us
#PCICompliance #PCIDSS #PaymentSecurity #EMV #FinTech #PaymentProcessing #CyberSecurity #DataSecurity #PaymentTechnology #Compliance #SoftPOS #UnattendedPayments #PaymentInfrastructure #Tokenization #PenetrationTesting #PaymentEngineering #PayingCo