PCI Compliance for Merchants: What PCI DSS 4.0.1 Requires

PCI DSS is a set of security rules for any business that stores, processes or sends cardholder data. That covers card numbers, expiration dates and the security code. It applies whether you take one payment a month or a million.

Two groups are involved, and it helps to know which does what:

• The PCI Security Standards Council (PCI SSC) writes the standard. Its founding members are American Express, Discover, JCB, Mastercard and Visa. The Council doesn't fine anyone or check your compliance.
• The card brands and your acquirer enforce it. The PCI SSC says each founding brand runs its own compliance program, and that "whether a small merchant is required to validate compliance is determined by the individual payment brands." It tells merchants to ask their acquirer (merchant bank) about validation and reporting.

In practice, your merchant account provider is who asks you to validate each year. If you're still setting up an account, our guide to merchant accounts explains how the acquirer, processor and gateway fit together.

If an old checklist mentions "PCI 3.2.1", it's out of date. Here's the timeline from the PCI SSC, as of September 2026:

The future-dated requirements were mostly aimed at larger or more complex setups. For online stores, the ones that got the most attention covered scripts running on payment pages. Those are the ones the 2025 SAQ A change dealt with.

Merchant levels, usually Level 1 through Level 4, decide how you prove compliance. They're set by each card brand and applied by your acquirer, not by the PCI SSC. Visa says a merchant's "total Visa transaction volume over a 12-month period determines your merchant level and the necessary requirements for validation."

• Level 1 is the largest merchants (millions of card transactions a year). They typically need an on-site assessment and a Report on Compliance.
• Levels 2 and 3 are mid-sized merchants. Most validate with a questionnaire, though a brand or acquirer can ask for more.
• Level 4 is where most small businesses sit. Validation is usually a yearly SAQ, plus any scans that SAQ calls for.

The exact thresholds differ by card brand and can change. So don't guess: your acquirer tells you your level and what you need to file. If you haven't been told, ask your provider.

The PCI SSC publishes several self-assessment questionnaires. Each one fits a way of taking payments, and the rule of thumb is simple: the less card data your own systems touch, the shorter your SAQ. These are the common ones:

Some SAQs also call for quarterly external vulnerability scans by an Approved Scanning Vendor (ASV). Not every Level 4 merchant needs them; it depends on your SAQ and how your checkout is built.

If you take cards over the phone, see how the Authorize.Net virtual terminal works. It's the tool behind most keyed payments.

The January 2025 SAQ A change

In January 2025 the PCI SSC revised SAQ A, effective March 31, 2025. Two things changed:

• Three requirements came out of SAQ A: 6.4.3 and 11.6.1, which cover scripts on payment pages, and 12.3.1.
• A new eligibility check went in: to use SAQ A, you confirm that your site "is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)."

The PCI SSC notes that the underlying PCI DSS requirements still exist; the change is in how SAQ A merchants report on them. In practice, if your site embeds a hosted payment form, you need to be able to stand behind that script statement. Keep your checkout pages lean, limit third-party scripts, and ask whoever runs your site how it's protected. Our website requirements for accepting credit cards guide covers the rest of a secure, approvable checkout.

PCI DSS has 12 principal requirements. Version 4 renamed several of them (there's no longer a requirement literally called "firewall" or "anti-virus"). Here's what each one asks of you, in our words rather than the standard's official titles:

1. Control your network. Put security controls between the internet and any system that handles card data.
2. Configure systems securely. Change default passwords and turn off settings and services you don't need.
3. Protect stored card data. Better still, don't store it. Never keep the security code after a payment is authorized.
4. Encrypt card data in transit over the internet and other open networks.
5. Protect against malware on every system that could be exposed to it.
6. Build and maintain secure systems and software. Apply security patches and protect payment pages.
7. Limit access to card data to staff who need it for their job.
8. Identify every user. Unique logins for each person, with strong authentication.
9. Restrict physical access to card data, devices and paper records.
10. Log and monitor access to systems and card data.
11. Test your security regularly, with scans and other checks.
12. Keep a written security policy and make sure staff know it.

You don't answer all of this on every SAQ. SAQ A covers only a small slice, because a hosted checkout moves most of the work to your gateway. SAQ D covers all of it.

"Scope" means the systems PCI DSS applies to. If card numbers never reach your website or servers, far fewer of your systems are in scope. That's the idea behind hosted and tokenized checkouts. Both gateways START works with, Authorize.Net and Cybersource, offer them.

Authorize.Net

Authorize.Net's developer documentation, checked September 28, 2026, rates its Accept tools this way:

• Accept Hosted (a payment form Authorize.Net hosts): SAQ A
• Accept.js with Authorize.Net's ready-made form (Accept.js UI): SAQ A
• Accept Customer (a hosted form where customers manage saved cards): SAQ A
• Accept.js with your own form: SAQ A-EP, because your page controls the form

Saved cards help too. With Authorize.Net's Customer Information Manager (CIM), card details sit in Authorize.Net's vault and you keep only a reference. The Authorize.Net integration methods guide compares each option by PCI scope, including older SIM and AIM setups.

Cybersource

Cybersource's developer documentation, checked September 28, 2026, describes its Unified Checkout as "PCI SAQ-A compliant: Payment data never touches your systems." See Cybersource merchant services for how the gateway and merchant account fit together.

Two cautions. A gateway's rating depends on you using the tool as designed; a plugin that swaps in its own card form can change your SAQ. And your acquiring bank has the final say on which questionnaire you file. Planning a new store? Our ecommerce merchant account guide covers the checkout choices alongside the account itself.

There are two kinds of cost to watch for, and they're easy to confuse:

• PCI fees from your provider. Some providers charge a yearly or monthly PCI program fee, and some add a separate PCI non-compliance fee each month you haven't validated. These are provider fees, not card brand fines. Look for them on your statement and in your agreement, and ask your provider what each one covers.
• Card brand assessments after a problem. Visa says it "may assess a non-compliance assessment to the issuer or acquirer." Your agreement will say whether your acquirer can pass that on to you. A data breach can also bring investigation and cleanup costs.

Be wary of any page that quotes a fixed fine range for merchants. We found no such schedule in Visa's or the PCI SSC's merchant guidance, and what you'd actually owe depends on your agreement with your acquirer.

Reviewing your statement? Tell us what PCI charges you see, and we'll tell you what they are. Our free rate review looks at the whole statement.

1. Map how cards reach you: website, phone, terminal, or all three. Each channel may need its own SAQ.
2. Ask your provider which level and which SAQ apply, and where to file it.
3. Use a hosted or tokenized checkout where you can, so card numbers skip your systems.
4. Never store card numbers or security codes in email, spreadsheets, notes or your order system.
5. Give each person their own login to your gateway and store admin, with two-factor sign-in turned on.
6. Keep software patched: your cart, plugins, themes and computers.
7. Run any required ASV scans on schedule, and fix what they find.
8. File your SAQ and attestation every year before the deadline, and keep a copy.

PCI compliance and fraud prevention overlap but aren't the same thing. Being compliant won't stop a stolen card from being used at your checkout. For that, see card-not-present fraud prevention and the Authorize.Net Fraud Detection Suite.