Requirements for PCI DSS Compliance When Adding Online Payment on a Pune Boutique's Website

What is PCI DSS and why a boutique needs it

PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements created by the major card brands to protect cardholder data. Any business that stores, processes, or transmits payment card information – including a small boutique adding an online checkout – must meet these requirements to avoid fraud, fines and loss of customer trust.

Govindani Infotech Pvt. Ltd. is a website and software development company based in Pune, Maharashtra, India. For Indian merchants, compliance also means aligning with RBI guidelines and GST regulations while handling card payments.

Determine your merchant level and scope

Your PCI DSS obligations start with identifying the merchant level assigned by the acquiring bank. Levels range from 1 (annual transaction volume > 6 million INR) to 4 (≤ 1 million INR). Most Pune boutiques fall into Level 3 or 4, which limits the validation effort to a Self‑Assessment Questionnaire (SAQ) rather than a full on‑site audit.

Scope is the set of systems, people and processes that can affect card data. Keeping the scope narrow – for example, by using a hosted payment page – reduces the number of controls you must implement and audit.

Choose the right payment integration model

The integration model you select determines how much of the card data touches your website. Three common options are:

Choosing a hosted payment page is often the safest route for a boutique that lacks a dedicated security team. It shifts most PCI responsibilities to the payment service provider (PSP) while still giving a seamless checkout experience.

Implement technical controls for card data protection

Regardless of the integration model, certain technical safeguards are mandatory:

• Encryption in transit – Use TLS 1.2 or higher for all pages that handle payment information. A valid SSL certificate from an Indian CA (e.g., e‑Mudhra) is required and must be renewed annually.
• Encryption at rest – If any card data is stored (e.g., for recurring billing), it must be encrypted with strong algorithms (AES‑256) and the keys must be managed separately from the data.
• Tokenisation – Replace the primary account number (PAN) with a non‑sensitive token. Most Indian PSPs (Razorpay, PayU, CCAvenue) provide token services that remove the PAN from your database.
• Secure coding practices – Validate all inputs, use prepared statements for database queries, and avoid exposing error messages that could reveal system details.
• Network segmentation – Isolate the web server that handles payments from the rest of your boutique’s IT environment. A separate VLAN or firewall rule reduces the scope of PCI controls.

Secure the website and hosting environment

A boutique’s website is often built on popular CMS platforms (WordPress, Shopify) or custom PHP/Node stacks. Securing the underlying host is essential:

• HTTPS everywhere – Enforce HSTS (HTTP Strict Transport Security) to prevent downgrade attacks.
• Web Application Firewall (WAF) – Services like AWS WAF or Cloudflare WAF can block common attacks (SQL injection, XSS) without requiring code changes.
• Patch management – Apply OS and application updates within 30 days of release. Unpatched libraries are a leading cause of data breaches in Indian SMEs.
• Least‑privilege accounts – Database users used by the checkout process should have only SELECT, INSERT and UPDATE rights on the token table.
• Backup and recovery – Store encrypted backups off‑site and test restoration quarterly. While backups are not a PCI requirement, they help maintain business continuity after a security incident.

If you are engaging a local development partner for website development in Pune, ask them to include these hardening steps in the project plan.

Documentation, policies, and staff training

PCI DSS is as much about process as technology. You will need documented evidence for each control:

• Information security policy – A one‑page statement approved by senior management that outlines the intent to protect cardholder data.
• Incident response plan – Steps to contain, investigate and report a breach, including contact details for the acquiring bank and the Indian Computer Emergency Response Team (CERT‑In).
• Access control list – Who can view or modify payment‑related code and configurations.
• Training records – All staff handling payments should complete a short PCI awareness module annually. Even sales staff need to know not to write down PANs on paper.

Maintaining these documents in a cloud‑based repository (e.g., Google Workspace with two‑factor authentication) simplifies the audit process.

Complete the Self‑Assessment Questionnaire (SAQ) and validation

For Level 3/4 merchants, the SAQ is the primary validation tool. The version you use depends on your integration model:

Steps to complete the SAQ:

1. Gather evidence – screenshots of TLS certificates, WAF rules, tokenisation logs, and policy documents.
2. Fill the questionnaire – Answer “Yes” only if you can provide supporting evidence. “No” or “Not applicable” are acceptable where the control truly does not apply.
3. Attestation of Compliance (AOC) – Sign the AOC and submit it to your acquiring bank. The bank may request a Report on Compliance (ROC) if they deem the scope high.

The entire process typically takes 2–4 weeks for a boutique that has already implemented a hosted payment page.

Ongoing compliance and monitoring

PCI DSS is not a one‑time checklist. Continuous monitoring keeps your environment secure and reduces the risk of non‑compliance penalties:

• Quarterly vulnerability scans – Use an ASV‑approved scanner (e.g., Qualys, NetSparker) to detect external weaknesses. The scan report must be retained for at least a year.
• Monthly log reviews – Review firewall, WAF and server logs for suspicious activity. Automated SIEM tools can flag anomalies without manual effort.
• Annual re‑assessment – Even if you stay on SAQ A, repeat the questionnaire each year and update documentation for any changes (new plugins, server migrations, etc.).
• GST and tax compliance – Ensure that the PSP’s transaction fees include GST, and that you issue proper tax invoices for each sale. Incorrect GST handling can attract penalties from the tax department.

By embedding these activities into your boutique’s regular operations, compliance becomes a habit rather than an annual sprint.

Frequently Asked Questions

What is the minimum PCI DSS version I must comply with in India?

All Indian merchants must meet at least PCI DSS version 4.0, which became mandatory globally in early 2024. Some acquiring banks may still accept version 3.2.1 for a short transition period, but planning for 4.0 avoids future re‑validation.

Can I use a free SSL certificate for my boutique’s checkout page?

Free certificates (e.g., Let’s Encrypt) provide the required TLS encryption, but you must ensure they are renewed automatically and that the certificate chain is trusted by Indian browsers. For high‑value brands, a paid EV (Extended Validation) certificate can add visual trust cues, though it is not a PCI requirement.

Do I need to store cardholder data if I offer “Buy Now, Pay Later”?

If the “Buy Now, Pay Later” service tokenises the PAN and stores only the token, you are not storing cardholder data and can stay within SAQ A. However, you must keep the tokenisation agreement on file and verify that the PSP complies with PCI DSS.

How does GST affect my payment gateway fees?

Payment gateways in India charge a transaction fee that includes GST at the prevailing rate (currently 18 %). The fee you see on the invoice should be GST‑inclusive; you can reclaim the GST as input tax if you are GST‑registered.

What happens if I fail a quarterly vulnerability scan?

A failed scan must be remediated within 30 days, and a re‑scan submitted to the acquiring bank. Persistent failures can lead to a temporary suspension of card processing privileges until the issues are resolved.

Is a dedicated PCI‑DSS compliant server necessary for a small boutique?

Not necessarily. Using a reputable cloud provider that offers PCI‑certified infrastructure (e.g., AWS PCI‑eligible services) satisfies the requirement, provided you configure the environment according to the provider’s security best practices.

Where to Start

1. Map your transaction volume and confirm your merchant level with the acquiring bank.
2. Select a hosted payment page from a PCI‑validated PSP (Razorpay, PayU, CCAvenue) to keep your scope minimal.
3. Implement TLS 1.2+, enable a WAF, and set up tokenisation – most PSPs provide a one‑click integration guide.
4. Document the controls (policy, access list, incident response) and schedule a quarterly vulnerability scan.
5. Complete the appropriate SAQ before the next compliance deadline and retain all evidence for at least one year.

If you need hands‑on help, talk to the Govindani Infotech team on WhatsApp.