English
German
Spanish
French
Turkish
Back to Guides
PCI DSS Compliance for Payment Gateways: The 2026 Merchant Guide
PCI DSS v4.0.1 became fully enforceable on March 31, 2025. If you accept card payments in any form, you are in scope - the only question is how deeply. The type of gateway you use, far more than the size of your business, decides whether PCI compliance costs you a 10-minute questionnaire or a $100k annual audit.
This guide explains the 12 core requirements, the four merchant levels, the eight SAQ types, and the architectural choices that shrink your scope. Plus how crypto payment gateways remove PCI scope entirely for the crypto leg.
Boost Your Business by Accepting Crypto Payments
What Is PCI DSS (and Who Enforces It)
The Payment Card Industry Data Security Standard (PCI DSS) is a contractual standard set by the PCI Security Standards Council, a body jointly operated by Visa, Mastercard, American Express, Discover, and JCB. It is not a law, but every card-accepting merchant is contractually obligated to comply through their acquirer agreement.
The current version is PCI DSS v4.0.1, published in 2024 and fully enforceable from March 31, 2025. It replaces v3.2.1 and adds about 50 new requirements over the previous version.
Enforcement is practical, not governmental: non-compliant merchants face fines from their acquirer ($5k to $100k per month), increased transaction fees, and ultimately loss of card-processing rights. After a breach, non-compliance multiplies the damage through lawsuits, forensic costs, and reputational loss.
The 12 Core PCI DSS Requirements
Organized into six goals:
| Goal | Requirement |
|---|---|
| Build and maintain a secure network | 1. Install and maintain network security controls (firewalls) |
| 2. Apply secure configurations to all system components | |
| Protect cardholder data | 3. Protect stored cardholder data (encryption, truncation, tokenization) |
| 4. Protect cardholder data with strong cryptography during transmission | |
| Maintain a vulnerability management program | 5. Protect all systems from malware and regularly update anti-virus |
| 6. Develop and maintain secure systems and applications | |
| Implement strong access control | 7. Restrict access to cardholder data by business need to know |
| 8. Identify and authenticate access (MFA mandatory) | |
| 9. Restrict physical access to cardholder data | |
| Regularly monitor and test networks | 10. Log and monitor all access to cardholder data and network resources |
| 11. Test security of systems and networks regularly (ASV scans, pen tests) | |
| Maintain an information security policy | 12. Maintain a policy that addresses information security |
v4.0.1 added targeted risk analysis, customized approaches, stricter authentication (MFA for all access into the CDE), and explicit client-side-script integrity monitoring to counter Magecart-style attacks.
Merchant Levels: From 1 to 4
PCI levels are set by each card network based on transaction volume. Visa's definitions (most others are similar):
| Level | Volume | Validation |
|---|---|---|
| 1 | > 6M card transactions/year or any merchant that has suffered a breach | Annual onsite audit by a QSA, plus quarterly ASV scans |
| 2 | 1M to 6M | Annual SAQ (or QSA audit), quarterly ASV scans |
| 3 | 20k to 1M e-commerce | Annual SAQ, quarterly ASV scans |
| 4 | < 20k e-commerce or < 1M card-present | Annual SAQ, scans per acquirer policy |
A breach can jump any merchant to Level 1 regardless of volume. Service providers (which most payment gateways are) have a separate two-level classification based on storing, processing, or transmitting more than 300k transactions per year.
SAQ Types: The Document That Matters Most
For levels 2 through 4, compliance is documented via a Self-Assessment Questionnaire (SAQ). There are several flavors and they differ massively in length and cost:
| SAQ | Applies to | Questions (approx.) |
|---|---|---|
| A | E-commerce merchants fully outsourcing to a PCI-compliant third party (redirect or iframe hosted fields) | ~24 |
| A-EP | E-commerce merchants where your website impacts transaction security but does not touch card data | ~191 |
| B | Merchants using only imprint machines or standalone dial-up terminals | ~41 |
| B-IP | Merchants using standalone IP-connected PTS terminals | ~86 |
| C-VT | Merchants manually entering card data into a virtual terminal | ~80 |
| C | Merchants using payment applications connected to the internet, no e-commerce | ~152 |
| P2PE | Merchants using a validated P2PE solution | ~35 |
| D | Everything else - the catch-all. Most stored card data goes here. | ~329 |
The architectural choice is almost entirely about getting into SAQ-A or A-EP territory and staying there. The jump from SAQ-A (24 questions) to SAQ-D (329 questions) is a 10x compliance cost.
How Gateway Type Changes Your PCI Scope
Your PCI scope is determined by where cardholder data flows:
- Hosted gateway (redirect): Card data never touches your systems. SAQ-A. Simplest case.
- API gateway with hosted fields or drop-in SDK: Card data goes from buyer's browser directly to the gateway over TLS, skipping your server. SAQ-A, because your site is "deemed out of scope" for the data itself.
- API gateway with server-side capture: Card data flows through your server. Full SAQ-D. Rare in modern builds; almost always a mistake.
- Self-hosted gateway: Card data flows through your server and may be stored. Full SAQ-D. Expensive to maintain.
- Crypto payment gateway: No cardholder data ever. No PCI scope at all.
For most modern builds, the correct architectural choice is: API gateway with hosted fields, for SAQ-A compliance and native UX. Any other path trades away orders of magnitude more compliance cost than it is worth.
Common Scope Traps
Merchants routinely blow up their PCI scope without realizing:
- Handling MOTO (mail-order/telephone-order) orders. Staff typing card numbers into a CRM puts the CRM in scope.
- Accepting cards by email. Never. Use a secure pay-by-link instead.
- Hosted fields misconfiguration. If your site can inject JS into the PSP's iframe, you may end up in SAQ A-EP rather than SAQ-A.
- Client-side scripts on the checkout page. Under v4.0.1, you must monitor integrity of any script on pages that touch payment data. Includes analytics, chat widgets, and tag managers.
- Storing the last 4 digits plus expiry. Not in scope if truncated per rules, but get the rules wrong and it is.
- Call recordings with card numbers. Stored audio is in scope. Either pause the recording during card entry or use a descoping solution.
v4.0.1's requirement 6.4.3 (inventory, authorize, and monitor client-side scripts on payment pages) is the single biggest change most merchants have to accommodate in 2026.
Crypto Payment Gateways and PCI Scope
Here is where crypto gateways get interesting from a compliance-cost perspective. A crypto payment gateway does not handle cardholder data - ever. There is no PAN, no CVV, no expiry, no issuer, no card network. So:
- A merchant accepting only crypto has zero PCI DSS scope. No questionnaire, no scans, no QSA.
- A merchant accepting both cards and crypto still has card-side PCI scope, but the crypto leg does not add to it.
- Fiat-to-crypto on-ramp flows (where a buyer funds with a card and the gateway converts to crypto) have PCI scope on the fiat leg - the gateway typically absorbs this via SAQ-A-EP or a full QSA audit of its own.
For a pure crypto business, the compliance saving is real: $20k to $200k per year of PCI overhead does not exist. For a mixed stack, adding crypto does not increase PCI cost.
This is one of the quieter reasons crypto rails are attractive for digital-goods, iGaming, forex, and other high-volume verticals. Fewer auditable surfaces, less attack area, less money spent on paperwork.
A Practical PCI Compliance Checklist for 2026
- Know your merchant level. Ask your acquirer if you are not sure.
- Know your SAQ. Architect toward SAQ-A or A-EP wherever possible.
- Use an API gateway with hosted fields. SAQ-A without losing UX control.
- Inventory client-side scripts on payment pages. Document every script, monitor for changes, remove anything unnecessary.
- Enforce MFA for any access to systems that touch card data. Mandatory under v4.0.1.
- Run quarterly ASV scans. External network scans by an Approved Scanning Vendor.
- Conduct annual penetration tests. Required for Level 1 and 2, best practice for all.
- Maintain an incident response plan. Test it annually.
- Train staff yearly. Requirement 12 is explicit.
- Watch vendor scope. Service providers you use must also be PCI-compliant; get their AOC (Attestation of Compliance) in writing.
Boost Your Business by Accepting Crypto Payments
Get Started
Frequently Asked Questions
PCI DSS is the security standard all card-accepting merchants must follow to protect cardholder data. It has 12 requirements covering network security, encryption, access control, monitoring, and policy. Non-compliance risks fines and loss of card-processing rights.
Yes, always - but the scope depends on how the gateway integrates. Hosted gateways and API gateways with hosted fields keep you in SAQ-A (minimum scope). Self-hosted gateways put you in SAQ-D (maximum scope).
SAQ-A is the shortest Self-Assessment Questionnaire (~24 questions). It applies to e-commerce merchants who fully outsource cardholder data handling to a PCI-compliant third party - typically via redirect or hosted fields.
Yes. v4.0.1 became fully enforceable on March 31, 2025, replacing v3.2.1. Any merchant validating compliance in 2026 does so against v4.0.1.
For SAQ-A merchants, a few hundred to a few thousand dollars a year (SAQ plus ASV scans). For SAQ-D, $20k to $200k+ per year depending on environment complexity, including QSA fees for Level 1.
No. Crypto payments do not involve cardholder data, so PCI DSS does not apply to the crypto leg of a transaction. Merchants accepting only crypto have zero PCI scope.
Fines from your acquirer ($5k to $100k per month), higher transaction fees, and ultimately loss of card-processing rights. After a breach, non-compliance multiplies liability and forensic costs.
Both. The gateway is responsible for its own compliance as a service provider (and must provide you with an Attestation of Compliance). You are responsible for your own environment's compliance. Never assume using a compliant gateway makes you compliant automatically.
Annually for the SAQ or onsite audit, and quarterly for ASV scans. Penetration tests are annual for Level 1 and 2, plus after any significant change.
Yes, significantly - if implemented correctly. Tokenization replaces the PAN with a token that is useless outside the gateway, keeping your systems out of scope for stored cardholder data. Combined with hosted fields for capture, it is the shortest path to SAQ-A.
