Five managed ecomm hosting myths you stop believing after your first vendor review

By the time you’re comparing vendors you’re parsing through phrases like “PCI-compliant infrastructure,” “managed support,” and “application layer expertise” without a clear way to tell what any of them cover. Here’s where each one tends to stop.

Myth 1: “PCI-compliant infrastructure covers your store”

The badge on their homepage means their servers passed an assessment, which covers their side of the compliance question and not yours.

PCI DSS 4.0.1, Requirement 12.8.5 requires a documented matrix, signed by both parties, that spells out exactly which controls the host owns and which ones you own. That’s what an assessor or payment processor wants to see, not a badge, but a formal document with both parties named.

Ask for it before you sign. If they send you a PDF about their data centers, you have your answer.

Myth 2: “Redirecting to a hosted payment page means PCI compliance isn’t our problem”

Redirecting to a hosted payment page still reduces your compliance scope meaningfully, but it doesn’t eliminate it.

PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1, mandatory since April 2025, govern the scripts running on your payment pages regardless of where card data goes. If your checkout loads third-party scripts, even on a fully redirected payment flow, you have documented obligations around script inventory, integrity checking, and tamper detection.

Merchants who found that out in a 2025 QSA engagement rather than beforehand had a more interesting year than they planned.

Myth 3: “If the host gets breached, that’s their problem”

PCI DSS doesn’t include a vendor exemption. If cardholder data is exposed through a service provider’s environment, the merchant is still in scope for the breach. Payment card brands and acquiring banks look at which controls failed and who was responsible for them.

What a formal responsibility matrix gives you in that scenario is documentation showing your side was covered. A host that describes its responsibilities informally can’t produce that after the fact. A host with a signed responsibility model already has it.

Myth 4: “Application-layer support covers our platform problems”

Application-layer support means the people on your ticket know Magento, WooCommerce, or Shopware at the platform level. If checkout latency surfaces, they can tell you whether it’s a resource issue, a configuration problem, or something in the application. That’s useful.

What it doesn’t cover: custom plugin work, debugging checkout flows your agency built, or anything touching your code. The boundary is reasonable, and it’s worth knowing where it sits before a 2am incident makes it obvious.

Myth 5: “The responsibility model is just standard contract language”

On commodity managed hosting, the responsibility model is a mutual understanding: they handle the server, you handle everything else. That works until a payment processor, enterprise retail partner, or PE firm doing diligence asks for it in writing.
A mutual understanding doesn’t produce a page they can file. A host with a written responsibility model tied to PCI DSS 4.0.1 can turn that around quickly. One without it has to build it from scratch, under deadline, while you’re waiting.

The phrases don’t change across vendors. What does is whether there’s a document behind them.

If you’re starting that conversation and want to know what Nexcess Platform’s responsibility model, compliance posture, and support boundaries include, talk to an expert and we’ll walk you through it.