Even if your e-commerce site doesn’t store any credit card information (like the full card number, expiration date, or CVV), you almost certainly still need to comply with PCI DSS (Payment Card Industry Data Security Standard). Here’s why, broken down clearly:
PCI DSS Applies to More Than Just Storage
PCI DSS isn’t only about storing card data — it applies to any organization that stores, processes, or transmits cardholder data (CHD).
- Storing — Keeping CHD anywhere (databases, logs, backups, etc.). You say you don’t do this — great, that reduces your scope significantly.
- Processing — Handling or manipulating CHD in any way (e.g., authorizing a payment).
- Transmitting — Sending CHD over networks (even temporarily, like from the customer’s browser to your server and then to a payment gateway).
For virtually all e-commerce sites, customers enter their card details on your website (or an embedded form on your site). That data is transmitted through your systems — even if only briefly — before reaching your payment processor (e.g., Stripe, PayPal, Authorize.net). This puts you in scope for PCI DSS.
How You Handle Payments Determines Your Compliance Burden
The exact level of effort depends on your payment integration method:
| Payment Method | Do Card Details Touch Your Systems? | Typical PCI Form | Approx. Requirements | Scope/ Effort |
|---|---|---|---|---|
| Full redirect (e.g., customer leaves your site and pays on Stripe/PayPal’s page) | No | SAQ A | ~22 questions | Very low |
| Hosted fields / iFrame (e.g., payment form embedded on your site, but fields loaded directly from a PCI-compliant provider) | No (if implemented correctly) | SAQ A | ~22 questions | Very low |
| Direct post / Your own form (card entered on your site, then POSTed directly to gateway from customer’s browser) | Sometimes borderline (often shifts to higher SAQ) | SAQ A-EP | ~140+ questions | Medium |
| Forms that submit to your server (card data hits your backend before going to gateway) | Yes | SAQ D (full) | 300+ requirements | High (avoid this!) |
If you use a proper redirect or validated iFrame/hosted fields from a PCI-compliant provider (and the provider supplies an Attestation of Compliance confirming it removes you from handling CHD), you qualify for the shortest form — SAQ A — and your compliance is minimal. You still have to:
- Fill out and sign the SAQ annually.
- Confirm your provider is PCI-compliant.
- Keep basic security practices (e.g., no malware on your site, secure scripts).
Why Can’t You Just Skip It Entirely?
- The card brands (Visa, Mastercard, etc.) and your acquiring bank require PCI compliance from any merchant that accepts their cards. It’s contractual, not optional.
- Even if you never store data, a breach on your checkout page (e.g., a skimmer injecting malware) can steal cards in real time. PCI exists to prevent that.
- Non-compliance risks fines (up to $100,000/month per card brand), higher processing fees, or losing the ability to accept cards altogether.
Bottom Line
Not storing card data is smart and drastically reduces your PCI burden — but unless you’re 100% sure card details never transmit through your environment (true full redirect or properly implemented iFrame/hosted fields), you still have PCI obligations. Most e-commerce sites today use one of the low-scope methods above and just complete a short SAQ A each year.
At Web2Market, we follow the strictest guidelines and have partnered with Security Metrics to bring you a service. By default, we have clients go through SAQ-D and then can scale back as needed. What we find is that most small business owners think that it’s only the responsibility of the payment gateway company or the hosting provider and not theirs at all–wrong again. The new world of PCI that went into effect this year ensures that it’s a shared responsibility for all of us!