If your site accepts credit card payments, PCI DSS (Payment Card Industry Data Security Standard) applies to you. The good news: with the right architecture, an e-commerce site on shared cPanel hosting can meet PCI requirements without significant cost or effort. The bad news: a few common mistakes will move you into a much harder compliance tier. This article explains the practical implications.
The four PCI levels
PCI DSS has four levels of merchant obligation, based on annual transaction volume. Most small businesses and SaaS startups are Level 4 (less than 20,000 transactions per year). Level 4 obligations are vastly less than Level 1.
If you're Level 1, 2, or 3, this article is a starting point but you need professional compliance support. We're assuming Level 4 from here on.
The single most important decision: which payment flow
The PCI scope of your business depends almost entirely on whether your server ever sees raw credit card data. Three patterns:
Pattern A: Hosted payment page (recommended)
The customer enters card data on a payment processor's page (Stripe Checkout, PayPal Checkout, Square hosted). Your server never sees the card. PCI scope: SAQ A — the simplest questionnaire, ~22 questions, mostly about your hosting.
Use this unless you have a specific reason not to. Stripe Checkout, PayPal Smart Buttons, Authorize.net Accept Hosted, and Square Web Payments SDK all support this.
Pattern B: Tokenization (iframe or JavaScript)
The customer enters card data into an iframe or JavaScript widget hosted by the processor (Stripe Elements, Braintree Hosted Fields). The widget tokenizes the card and your server only ever sees the token. PCI scope: SAQ A-EP — ~191 questions, requires quarterly external vulnerability scans.
More effort than Pattern A but allows fully custom checkout UX.
Pattern C: Card data touches your server (DON'T)
Your server processes raw card numbers (storing, logging, transmitting). PCI scope: SAQ D — ~329 questions, quarterly scans, annual penetration tests, ongoing security training. Cannot be done compliantly on shared hosting.
This pattern is for established e-commerce companies with dedicated infrastructure and security teams. If you're reading this article, this is not the path for you.
Required for any pattern
- HTTPS sitewide. No HTTP fallback, no mixed content. See our force HTTPS article.
- Strong access control. 2FA on cPanel and on your e-commerce platform admin (WordPress, WooCommerce, Magento, etc.).
- Patching. WordPress, WooCommerce, and any plugins must be kept current. PCI explicitly requires patches within 30 days of release for high-severity vulnerabilities.
- Quarterly external scans (Pattern B and Pattern C only). Hire an Approved Scanning Vendor (ASV). Trustwave, SecurityMetrics, and Qualys are common. Costs ~$50-200 per scan per IP.
- Annual self-assessment questionnaire. Your payment processor will provide the right SAQ template.
- No raw card data in logs. Configure your e-commerce platform to never log card numbers. Most are sane by default; verify.
WooCommerce specifics
WooCommerce by default works with payment processors via tokenization (Pattern B). Specifically:
- Stripe for WooCommerce — uses Stripe Elements; your server never sees card data. Stays in Pattern A or B scope depending on configuration.
- WooCommerce Payments — same as above, by Automattic.
- PayPal for WooCommerce — redirects to PayPal-hosted page. Pattern A.
- Authorize.net (CIM) — tokenized; Pattern B.
Avoid plugins that ask for the API username and password and store them in the database — that pattern can drag you into Pattern C scope.
What ipxcore handles vs. what you handle
Hosting-side PCI obligations (which we handle for you):
- Server hardening — firewall (CSF + cPHulk), patching, logging
- Physical security of the data center
- Network segmentation
- Account isolation between customers
Your obligations:
- Application-level security (WordPress, plugins)
- Strong passwords and 2FA
- Access control to your cPanel and e-commerce admin
- Picking a payment integration that minimizes your scope (Pattern A or B)
- Filing the annual SAQ with your payment processor
If you receive a card-data-handling complaint
Sometimes a customer or their bank notices your site is handling card data improperly. If this happens:
- Stop accepting cards immediately. Take checkout offline.
- Contact your payment processor's compliance team.
- Ensure no raw card data is anywhere in your database, logs, or backups.
- Work with the processor to remediate before re-enabling payments.
Doing PCI badly is much worse than not selling at all.
Resources
- Official SAQs — pick A or A-EP depending on your pattern.
- Stripe PCI guide — clear, vendor-specific.
- PCI Glossary — for the alphabet soup of acronyms.
