If you see a line item like "PCI non-compliance fee" on your merchant statement, it usually means your processor or acquiring bank has marked your account as "not validated" for PCI DSS compliance. This is common for small businesses that are otherwise processing normally but have not completed the paperwork or scans their processor requires.
The good news: in most cases, you can stop the fees by completing the right PCI validation steps for your setup (SAQ type, quarterly scans if required, and an attestation). The bad news: if you ignore it, the fees tend to recur monthly and can add up, and a true data incident can get much more expensive.
A PCI non-compliance fee is a monthly penalty your processor or acquiring bank adds when your merchant account is flagged as not meeting PCI validation requirements.
PCI DSS is not a law, but it is enforced through card brand rules and your merchant agreement. Card brands run compliance programs (for example, Mastercard's Site Data Protection program and Visa's AIS program) and require acquirers to track and report merchant compliance status. If your acquirer cannot validate your compliance, the processor often passes a penalty fee to you.
Important nuance: the PCI Security Standards Council publishes the standards and validation forms, but it does not bill merchants directly for non-compliance.
Usually, you get flagged for one of these reasons:
Mastercard explicitly states that merchants generally work through their acquirer for PCI validation, and that the acquirer manages compliance reporting to Mastercard. That is why your first call is typically your processor, not Mastercard.
No. A "PCI compliance fee" is often a separate recurring charge processors add for access to a PCI portal, scanning tools, training, or support.
A PCI non-compliance fee is the penalty that shows up when you do not complete validation steps in the portal. Some providers charge both: a compliance program fee plus a non-compliance fee.
If you are seeing both, ask your processor to explain exactly what each line item covers and whether either one can be removed if you use a different PCI validation path (for example, submitting a compliant SAQ and scans without the add-on portal).
Most SMBs validate PCI DSS annually with:
1. A Self-Assessment Questionnaire (SAQ)
2. An Attestation of Compliance (AOC)
The PCI SSC publishes official SAQ and AOC templates. Your processor may have you fill them out inside a portal, but conceptually, you are completing an SAQ and attesting to the results.
Larger merchants, and some higher-risk setups, may require a third-party assessment resulting in a Report on Compliance (ROC), but most local businesses and typical ecommerce merchants will not.
The SAQ type is based on how you accept cards and whether card data touches your systems.
If your setup is truly outsourced (for example, you use a hosted checkout page and do not handle card data on your servers), you may be eligible for a shorter SAQ. If you run payments through a virtual terminal, have payment software on a PC, or store card data, you can end up in SAQ D, which is longer.
Why it matters: processors often auto-flag "wrong SAQ" as non-compliant. So even if you completed "an SAQ", it might not satisfy the validation rules for your specific environment.
Practical examples:
If you are not sure, ask your processor: "Which SAQ type does your compliance program require for my MID, and what specific evidence is missing?"
Sometimes.
Quarterly external vulnerability scans (by an Approved Scanning Vendor, or ASV) are required when you have internet-facing systems in scope for PCI DSS. Some merchants never need scans because their payments are fully outsourced. Other merchants do need scans, especially if they host payment pages, have systems exposed to the internet that are connected to the cardholder data environment, or have a more complex setup.
Processors sometimes treat scans as a default requirement in their portal until you prove you are eligible for an SAQ type that does not require them.
The fastest way to get clarity is to ask your processor what exactly is missing:
It varies by processor.
Many processors charge a monthly penalty until you complete validation. Some also charge a one-time "PCI non-compliance" setup fee when the account first gets flagged, or they back-bill for prior months.
The most important operational detail is that these fees are usually avoidable and stop once you are validated as compliant in the processor's system.
Potentially, yes.
Most of the time, a PCI non-compliance fee is the processor's way of applying pressure to complete validation steps. But PCI issues also relate to risk. If a processor believes your environment is storing card data improperly or is materially insecure, it can trigger deeper underwriting review.
If you are already dealing with funding holds or account reserves, read our guide on merchant account reserves and funding holds.
First, confirm the trigger.
Call your processor and ask:
Second, check if the fee is a penalty for missing validation versus a separate PCI program fee.
Third, get the portal login and complete the steps.
If you have multiple locations or multiple MIDs, confirm which one is being charged.
Here is a practical checklist most merchants can follow.
1) Identify your acceptance methods
2) Confirm your required SAQ type in writing
Your acquirer should be able to tell you which SAQ you must complete.
3) Complete the SAQ and sign the attestation
Fill out the SAQ and the attestation (AOC) as required by your provider.
4) Run and upload quarterly ASV scans if required
If scans are required, schedule them as recurring. If a scan fails, remediate and rescan until it passes.
5) Validate your service providers
PCI programs often expect you to maintain a list of service providers that touch card data and confirm they are compliant.
6) Confirm the compliance status update
After submission, ask your processor when the account will show as "compliant" in the portal and when fees will stop.
7) Ask about credits (optional)
Some processors will reverse recent penalties as a courtesy once you validate, especially if the fee was triggered by a portal change or a misunderstanding.
Set reminders.
Also, keep your payment acceptance model stable. Adding new channels (for example, adding an ecommerce checkout to a retail-only business) can change PCI scope and require a different SAQ.
That is a common complaint.
Some processors bundle PCI validation with paid tools. Others offer a portal but do not provide much guidance.
If you feel stuck, you have two practical options:
If you are evaluating providers anyway, you may also want to read our guide to interchange-plus vs flat rate pricing, since PCI fees often show up alongside other statement line items that are easy to miss.
Yes. If you store, process, or transmit cardholder data, you have PCI DSS obligations. Most merchants validate annually via an SAQ and attestation through their acquirer.
You can still have PCI obligations even if your payment provider is compliant. Many merchants remain responsible for validating their own environment and completing the right SAQ for their setup.
Not always. It must be the correct SAQ type, and any required scans must be completed. Also, the status has to update in the processor's system.
In many cases, the fee will recur monthly. More importantly, ignoring PCI validation can increase risk if you have a real security issue, and it can lead to additional scrutiny from the processor.
Typically, penalties are applied through the acquiring chain. Merchants usually interact with their processor or acquiring bank for validation and fees.
If you are getting hit with PCI non-compliance fees, the fastest path is to get your processor to tell you exactly what is missing, complete the correct SAQ and attestation, and confirm the portal status update.
You can apply for a merchant account through Easy Pay Direct or another processor that fits your model. Other options worth a look: