Five PCI questions your payment processor will ask, and how to get ahead of them

Most ecomm merchants at $5M–$20M in annual GMV have dealt with something like this, and that “we’re working on it” does not buy the time it sounds like it should. The processor documents it and the review continues on their timeline.

The questions are reasonable, but the challenge is that the documentation they require doesn’t always exist in the form they’re expecting. These five are what exposes gaps.

What SAQ type are you operating under, and can you provide your most recent attestation?

SAQ type is one of those things that gets decided once and rarely revisited when the store evolves. A checkout that qualified for SAQ A at attestation time can quietly move out of eligibility as the store grows. A live chat widget added here, an analytics tag there, a session recording tool on the checkout page.

The PCI SSC updated the criteria in 2025 to require active confirmation that checkout pages aren’t susceptible to script-based attacks. What looked like a clean SAQ A situation when the attestation was signed may not qualify the same way anymore. Worth confirming the current setup still matches the SAQ on file before someone asks.

Can you provide current results from an approved scanning vendor?

Most hosts that run ASV scans run them against the infrastructure, not individual merchant environments. The report goes into a file the host keeps, that you don’t see. When a processor asks for current scan results scoped to your specific environment, which is what Requirement 11.3.2 requires, “our host handles security” isn’t an answer that produces a document.

The scan needs to be scoped to the merchant environment specifically. That’s a different engagement than what most commodity managed hosting includes by default.

How are you managing the scripts running on your payment pages?

Requirements 6.4.3 and 11.6.1 became mandatory in March 2025, and the requirement is exactly what it sounds like: every script on your checkout page inventoried, justified, and monitored for changes. Not the page behind the checkout button, but the checkout page itself, where the support widget, the analytics pixel, and the session recording tool are also loading.

The inventory piece most stores can approximate. The monitoring piece, having a mechanism that actually detects when something changes, is the one that’s hard to satisfy with evidence rather than stated intent. That’s the part the processor wants documented.

If there’s a security incident involving cardholder data, who handles which part of the response?

The coordination point between host and merchant, who calls whom first, who contacts the processor, who preserves logs, is usually undocumented. The host runs its own incident response process. The merchant runs theirs. Requirement 12.10 asks for a documented plan with named parties and escalation steps and processors want confirmation the people named in it know about it.

On commodity managed hosting, that document rarely exists in the form the question assumes. It’s not that the response wouldn’t happen, it’s that the plan isn’t written down.

Who owns patch management for your server and application environment, and what’s the cycle?

The host patches the server. Magento, WooCommerce, and the extension stack typically sit with the merchant, whether or not anyone stated that clearly at setup. Requirement 6.3 sets a one-month ceiling on critical vulnerabilities.

If the store hasn’t run a Magento security patch in four months because the developer queue was backed up, that gap lives in the merchant’s column regardless of what the host’s SLA says. The question isn’t whether the host is doing its job, it’s whether the full picture is documented and current.

---

These five questions aren’t a compliance test, they’re a documentation test. The infrastructure work, the scan results, the script inventory, the patch cycle, the incident response plan, most of it exists in some form. The problem is that on Tuesday morning, when you’re staring at a questionnaire with a deadline, none of it is in a form that produces a document.

Getting ahead of that is an organizational problem. The ecomm stores that handle these reviews without drama tend to be ones that treat the documentation as a living artifact rather than something assembled under pressure.

About the author

[Name] is a [title] at Nexcess, a Specialty Cloud company that builds solutions for ecomm merchants who’d rather have this documentation ready than find out what happens when they don’t. If your store is in that $5–$20M GMV range and you’re not sure your current setup would hold up to these five questions, that’s worth a conversation.