Someone on your team says "we need PCI compliant hosting" before a WooCommerce launch. Fair question. The awkward truth: PCI compliance is mostly about how you handle card data, not a checkbox your host ticks on a pricing page.
Your hosting provider matters for security basics. Patching, TLS, access control, logging. But the PCI DSS assessment is yours as the merchant (or your payment processor's shared responsibility model). Understanding where the host fits saves you from buying the wrong plan or over-engineering infrastructure you do not need.
What PCI DSS actually asks for
The Payment Card Industry Data Security Standard is a set of requirements for anyone who stores, processes, or transmits cardholder data. Banks and card brands enforce it through your acquirer or payment gateway.
Most small Canadian e-commerce sites never touch raw card numbers. Customers pay through Stripe Checkout, Square, Moneris hosted pages, or PayPal. Card data goes straight to the processor. Your server sees tokens, order IDs, and receipts. That dramatically shrinks your compliance scope compared to typing card numbers into a custom form on your site.
SAQ types in plain language
Self-Assessment Questionnaires (SAQs) are how many merchants validate compliance without a full onsite audit. Which SAQ applies depends on your checkout architecture:
- SAQ A: Card data never hits your server (fully outsourced payment page). Common for Stripe Checkout, PayPal Smart Buttons, hosted gateways.
- SAQ A-EP: Your site influences the payment page (embedded iframe or redirect you control) but card data still does not land on your server.
- SAQ D: You store, process, or transmit card data on your systems. Avoid this if you can. Scope explodes.
Pick the payment integration first. Then read which SAQ your processor says you qualify for. Do not pick hosting and hope it maps to SAQ A.
Where your host actually fits
Even on SAQ A, you still need a secure environment for your website, admin logins, and order data (names, emails, addresses). Your host should provide:
- TLS on all public endpoints (valid certs, modern ciphers)
- Timely OS and control panel security updates on managed plans
- Network-level protections (firewall, DDoS mitigation baseline)
- Sensible backup and restore options
- Clear access controls (no shared FTP passwords from 2014)
What typical shared hosting does not give you: a signed "PCI compliant hosting" attestation that satisfies your entire SAQ. Read marketing carefully. "PCI-ready infrastructure" is not the same as "we completed your merchant validation."
The mistakes we see on WooCommerce sites
Storing card data locally. Plugins or custom code that save PANs (primary account numbers) in the database or logs. Do not. Use a gateway tokenization model.
Card fields on your domain without understanding scope. Some embedded checkout flows shift you from SAQ A toward A-EP or worse. Your processor's integration docs spell this out.
Logging payment debug output. WooCommerce and gateway plugins in verbose debug mode can write sensitive payloads to log files on disk. Turn off debug in production. Rotate logs.
Weak admin access. PCI cares about who can change the checkout flow. Use MFA on WordPress admin, hosting panel, and DNS. Limit admin accounts.
Shared hosting with noisy neighbors. You can run a compliant checkout on well-managed shared hosting if card data never touches the box. You cannot control what another account on the same node does. Higher-risk merchants often move to VPS or isolated managed hosting for clearer boundaries and stricter access.
Canadian context
PCI is global; your processor and bank are usually Canadian or US entities with similar expectations. PIPEDA and provincial privacy rules add another layer for customer personal information, but PCI is specifically about payment card data.
If you sell B2B with invoicing and card-on-file through a processor portal, scope may differ again. Document how payments actually flow before you answer a compliance questionnaire for a large client.
Questions to ask your host (and your developer)
- Does cardholder data ever touch our server, even briefly?
- Which SAQ does our payment integration qualify for?
- Who patches the server, PHP, and WordPress plugins?
- Where are backups stored and who can access them?
- Is TLS terminated only on modern versions? (Old TLS fails PCI scans.)
- What happens if the site is compromised? Incident response path?
Good hosts answer these plainly. Evasive answers mean you need better documentation, not a more expensive plan by default.
When to upgrade hosting for compliance comfort
You might step up from shared to managed VPS when:
- You need dedicated IP reputation for email and stricter network isolation
- Auditors or enterprise clients require documented access controls
- You run custom checkout code that increases SAQ scope
- Traffic and logging requirements exceed shared resource limits
You might not need to upgrade if you use hosted checkout, keep WordPress patched, and pass your processor's SAQ A checklist on current shared hosting.
Bottom line
PCI compliance is a merchant responsibility shaped by how you take payments. Your host supplies secure infrastructure; you supply architecture that keeps card data off your server when possible, plus disciplined admin access and patching.
Launching a store and unsure about scope? Talk with Swift Host. Tell us your gateway and checkout flow. We will help you understand what the hosting side needs to support without selling you compliance theater.
