Exact Triggers for PCI DSS Compliance on Indian E‑Commerce Sites
Find out the exact points when an Indian e‑commerce business must implement PCI DSS and how to manage the requirements.
An Indian e‑commerce site must adopt PCI DSS as soon as it stores, processes, or transmits card data, with thresholds set by the acquiring bank and card brands.
Legal and contractual triggers
The moment you accept a credit or debit card on your website, the card‑issuing networks (Visa, MasterCard, RuPay) consider you a card‑present merchant. That alone obliges you to follow the Payment Card Industry Data Security Standard (PCI DSS). The law doesn’t give you a grace period; the contract with your acquiring bank will spell out the exact compliance level you need.
If you never touch card data – for example you redirect users to a third‑party payment gateway that hosts the form on its own domain – you can stay out of the scope, but you must still prove that you never see the PAN.
Transaction volume thresholds
Most Indian merchants think the 20,000‑transaction annual limit applies universally. In practice, the threshold is set by the acquiring bank and can be lower for high‑risk categories (e.g., travel, digital goods). If you exceed the limit, you move from Self‑Assessment Questionnaire (SAQ) A to SAQ D or even a full Report on Compliance (ROC). The cost and effort jump dramatically because you now need quarterly network scans and possibly an on‑site audit.
Typical progression
- Below 20k transactions, no storage of PAN – SAQ A (minimal questionnaire).\
- Below 20k, but you store PAN or auth data – SAQ D‑Merchant (full questionnaire, no on‑site).\
- Above 20k or high‑risk – SAQ D‑Service Provider or ROC (full audit).
Where the work actually goes
Practical checklist for the first 30 days
- Map every card‑touch point. List every form, API, and third‑party script that could capture PAN, CVV, or expiry.
- Decide on tokenisation. If you can replace PAN with a token before it hits your servers, you stay in SAQ A territory.
- Choose a PCI‑validated service provider. Gateways like Razorpay, PayU, or Stripe already meet the standard; you just need a signed Attestation of Compliance (AoC).
- Set up logging and monitoring. Even if you’re in SAQ A, you must be able to detect a breach within 24 hours.
- Engage your acquiring bank early. Ask them which SAQ version they require and whether they impose a lower transaction threshold.
The annoying detail most forget
Even if you outsource payment processing, the embedding of the gateway’s iframe or JavaScript can pull you back into scope if you manipulate the DOM to capture card data for analytics. The safest route is a pure redirect – the user never leaves your site, but the form lives on the provider’s domain.
Cost implications by compliance level
| Level | Typical effort | Approx. cost range (₹) | Who usually needs it |
|---|---|---|---|
| SAQ A | Few hours of questionnaire | 5,000‑15,000 | Low‑volume, no data storage |
| SAQ D‑Merchant | Days of config + quarterly scans | 30,000‑80,000 | Stores auth data or >20k tx |
| ROC | Weeks of audit, on‑site assessor | 150,000‑500,000+ | Large merchants, high‑risk |
The numbers are illustrative; actual spend depends on the size of your dev team, the complexity of your tech stack and the rates of the audit firm you hire.
Timeline example for a mid‑size fashion retailer
- Week 1‑2: Inventory of card‑touch points, decision on tokenisation.
- Week 3‑4: Implement redirect to Razorpay, remove any inline card fields.
- Week 5: Complete SAQ A, submit AoC from Razorpay.
- Month 2‑3: If transaction volume crosses 20k, upgrade to SAQ D‑Merchant, run quarterly vulnerability scan.
- Month 6: Review with acquiring bank; if still growing, plan ROC.
What if you miss the deadline?
Non‑compliance can trigger fines from the card networks that continue every month until you comply and the acquiring bank may suspend your merchant account. The bigger problem is the reputational hit – a data breach on an e‑commerce site often leads to charge‑backs that can cripple cash flow.
Choosing the right path for your business
If you’re just starting and expect under 10 k transactions a year, use a pure redirect gateway and stay in SAQ A. The overhead is a few hours of work and a small annual fee. Once you see growth, move to tokenisation on your own backend; that pushes you into SAQ D‑Merchant but gives you control over the checkout experience.
Remember that the Indian GST filing process now asks for the last four digits of the card used for each transaction. If you store those digits, you’re already in scope for SAQ D‑Merchant.
The role of a technology partner
We help you map the data flow, choose the right gateway, and prepare the appropriate SAQ without inflating the budget. The goal is to get you compliant the first time, so you can focus on sales rather than chasing audits.
--- This article explains when an Indian e‑commerce site must implement PCI DSS compliance and how to approach it pragmatically.
Thinking about building something?
Tell us what you have in mind. You will hear back from an engineer, usually within a day.
Start a project