PCI Compliance for Ecommerce Store Owners: What You Actually Have to Do

What is PCI DSS and who made it?

PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements created by the PCI Security Standards Council — founded by Visa, Mastercard, American Express, Discover, and JCB in 2006. The standard exists to protect cardholder data and prevent payment fraud.

Any business that accepts, processes, transmits, or stores cardholder data is subject to PCI DSS requirements. This includes virtually every online store. The good news: the compliance requirements scale significantly based on how you handle card data. If you use a hosted checkout, you're in the easiest tier.

The 3 SAQ types that matter for ecommerce

SAQ A: the path 90% of ecommerce stores take

SAQ A applies when you completely outsource all cardholder data handling to a PCI DSS certified third party. In practice: when your checkout redirects customers to Razorpay's hosted page, Stripe Checkout, PayPal's payment page, or a similar hosted solution — the customer enters card details on the gateway's servers, not yours.

• Your website contains only a "Pay Now" button that redirects to the payment provider's page.
• You never see, touch, or store any raw card numbers.
• The SAQ A questionnaire has approximately 22 yes/no questions.
• You complete it yourself online at the PCI SSC portal or through your acquirer's compliance program.
• Validity: 1 year. Completion time: 30–60 minutes.
• Cost: typically free or low-cost through your payment gateway's compliance program.

SAQ A-EP: for JS SDK integrations

If you use Stripe Elements or Razorpay Checkout.js — where payment fields are rendered on your page but card data is captured and tokenized by the gateway's JavaScript before it reaches your server — you need SAQ A-EP.

The key distinction: your page's server never handles raw card data, but your page delivers the JavaScript that captures it. This means attackers could theoretically inject malicious scripts into your page to intercept card data. SAQ A-EP therefore requires more security controls around your website code, hosting, and change management.

• Around 191 requirements versus SAQ A's 22.
• Requires proper implementation of Content Security Policy (CSP) headers.
• Website change management and code review requirements.
• File integrity monitoring on payment-page scripts.
• Still self-assessment — no external QSA audit needed.
• Most developers on modern frameworks (Next.js, React) can meet these requirements with reasonable security hygiene.

SAQ D: avoid this entirely

SAQ D applies only if you store, process, or transmit raw card data on your own infrastructure. This means 300+ requirements and an annual audit by a Qualified Security Assessor (QSA) that costs ₹5L–₹20L+ per year.

No modern ecommerce business needs to do this. Tokenization exists precisely to make this unnecessary. Use your payment gateway's hosted checkout or JS SDK — they handle card data capture, tokenization, and storage. You store a token (a non-sensitive reference ID), not the actual card number.

Golden rule of PCI compliance

Never let raw card data (card numbers, CVV, expiry) touch your servers. Use hosted checkout or gateway JS SDKs — they handle capture and tokenization. Store only the gateway-provided payment token. This keeps you at SAQ A or A-EP and eliminates the massive liability of SAQ D compliance.

What Indian ecommerce stores specifically need

If you're using Razorpay, Cashfree, PayU, or any RBI-licensed Payment Aggregator with their hosted checkout or JavaScript SDK:

• Your gateway is PCI DSS Level 1 certified — the highest level of compliance, covering over 300 controls on their end.
• You fall under SAQ A (hosted checkout) or SAQ A-EP (JS SDK) — both are self-assessment only.
• RBI's Payment Aggregator framework (2020) mandates that PAs maintain PCI DSS compliance and implement additional data localization requirements.
• Merchants using certified PAs inherit significant compliance coverage — your gateway's annual compliance certificate covers the payment data handling portion.
• You still need to secure your own website (HTTPS, CSP headers, regular updates, no storing card data in databases or logs).

PCI compliance checklist for ecommerce merchants

• Use HTTPS everywhere on your site — get a free SSL certificate via Let's Encrypt or your hosting provider.
• Redirect to hosted checkout OR use JS SDK for payment — never build custom card forms that post to your server.
• Never log card numbers, CVV, or PAN in server logs, database, or analytics tools.
• Store only the gateway token (e.g., razorpay_payment_id, Stripe charge ID) — not any card details.
• Keep your payment gateway integration library and CMS (WordPress, Shopify, etc.) updated.
• Implement Content Security Policy headers if using embedded JS payment fields.
• Complete your SAQ A or A-EP questionnaire annually through your acquiring bank or gateway's compliance portal.
• Run a quarterly vulnerability scan of your website (some gateways provide this as part of their merchant program).
• Restrict access to payment transaction data — only give access to team members who need it.
• Have an incident response plan: what to do if you suspect a data breach.

Gateway PCI compliance reference

Verdict — Most stores need SAQ A. It takes 30 minutes, once a year.

PCI compliance is dramatically simpler than most merchants fear. If you're using any major gateway's hosted checkout or JS SDK — and you should be — you're at SAQ A or SAQ A-EP. That's a self-assessment, not an audit. The most important action right now: confirm you're not accidentally logging card details in your server logs or database, and make sure you're on HTTPS everywhere. Everything else your certified payment gateway handles for you.