Ecommerce Website Development in Pune: Why PCI DSS 4.0.1 Is Now Mandatory for Your Checkout
PCI DSS 4.0's transition period ended on 31 March 2025, which means every requirement that was previously a "best practice recommendation" — including a jump to twelve-character minimum passwords and much tighter authentication controls — became mandatory for anyone storing, processing or transmitting card data. If your ecommerce website development in Pune was built or last security-reviewed before that date, there's a real chance your checkout is running against a standard that's now out of date, even if nothing about the site's day-to-day operation looks any different — the site still processes orders normally, the checkout page still loads, and nothing visibly signals that the underlying compliance requirements underneath it have moved.
Who this actually applies to
PCI DSS (Payment Card Industry Data Security Standard) isn't a government regulation in India — it's a global standard maintained by the major card networks (Visa, Mastercard, RuPay's operator NPCI, American Express, Discover) and enforced through your payment processor and payment gateway contracts. If your online store accepts card payments in any form, you fall somewhere on the PCI DSS compliance spectrum, and where you fall depends heavily on one architectural decision: whether card details ever touch your own servers, or whether they go straight from the customer's browser to your payment gateway without passing through your infrastructure at all.
What Changed With Version 4.0.1
PCI DSS 4.0 was published in 2022 with a deliberately long runway — organisations had until 31 March 2024 to move off the previous version 3.2.1, and a further year, until 31 March 2025, during which a specific set of new requirements were treated as "best practice" rather than mandatory, to give merchants time to adapt. That grace period is now over. Every requirement in the standard, including the ones that were optional during the transition window, is enforceable today. Version 4.0.1 is a minor clarifying update to 4.0 itself, not a new set of requirements — so "PCI DSS 4.0" and "PCI DSS 4.0.1" refer to the same enforcement reality your business is now operating under.
The single most concrete change worth knowing by number: Requirement 8.3.6.1 raises the minimum password length for any account with access to cardholder data from seven alphanumeric characters to twelve, with a matching increase in complexity rules. This sounds like a narrow, technical detail, but it applies to every admin login, every staff account, every API credential with access to your payment or order-management systems — which, for a typical mid-sized Pune ecommerce operation, is usually more accounts than the business owner realises exist.
Beyond password length, the broader shift in 4.0's philosophy — carried through into 4.0.1 — is toward continuous, demonstrable security rather than a once-a-year checklist exercise: more frequent vulnerability scanning, clearer requirements around monitoring and logging, and an expectation that security controls are actually operating day-to-day, not just documented for an annual audit.
The RBI Layer: This Isn't Only a Card-Network Requirement
For an Indian ecommerce business, PCI DSS compliance isn't purely a card-network contractual matter sitting one step removed from regulation — the Reserve Bank of India has built PCI DSS certification directly into its regulatory framework for Payment Aggregators (PAs), the entities that actually process card and other digital payments on behalf of merchants. Under RBI's Payment Aggregator guidelines, PCI-DSS certification is mandatory for authorised PAs, who must undergo annual audits by a Qualified Security Assessor (QSA) and complete quarterly vulnerability scans to maintain that certification, alongside other cybersecurity obligations like data localisation and yearly CERT-In cyber audits.
What this means in practice for a store owner: your payment gateway provider is already required to hold current PCI DSS certification to legally operate as an RBI-authorised aggregator in India. That doesn't automatically make your checkout compliant, though — it only covers the gateway's own infrastructure. The moment your website's own code touches raw card data — even briefly, even in a form field your own server renders before handing it to the gateway — your site itself enters PCI DSS's scope, and the compliance burden shifts substantially onto you.
The Decision That Determines Almost Everything: Where Does the Card Form Live?
This is the single design choice that determines whether a store's PCI DSS obligation is a light annual questionnaire or a genuinely expensive audit process, and it's a decision made during ecommerce website development, not something a business can easily undo after launch.
Fully hosted or redirect checkout. The customer is sent to a page hosted entirely by the payment gateway (or the gateway's fields are embedded via an iframe your own code never touches), and card data never passes through your server in any form, even transiently. This qualifies for the simplest PCI DSS validation category — a Self-Assessment Questionnaire A (SAQ A) — which is a short annual questionnaire, not a technical audit. For the overwhelming majority of small and mid-sized Indian ecommerce sites, this is both the cheapest and the most secure option, and it's the default most competent developers should be building toward unless there's a specific product reason not to.
Card fields embedded directly on your page, even via a script. If your checkout page renders its own card-number, expiry and CVV fields — even if the actual submission is handled by a gateway's JavaScript library — your website's code is now part of the cardholder data environment. This typically requires SAQ A-EP, a substantially longer questionnaire with real technical requirements around your web server's security, or in higher-volume cases, a full Report on Compliance requiring an external QSA. This path exists for a reason (more control over checkout design and conversion-rate tuning), but it comes with a compliance cost that should be an explicit, informed decision, not something a developer defaults to without discussing it.
Storing card details for "one-click" repeat purchases. Storing primary account numbers directly on your own servers, rather than relying on your gateway's tokenisation service, is the highest-liability option by a wide margin and is generally the wrong choice for a business without dedicated security infrastructure and a QSA relationship already in place. Tokenisation — where your gateway stores the sensitive data and hands your system back a safe reference token — achieves the same "remember this customer's card" convenience without pulling raw card data into your own environment at all, and is the option a competent ecommerce website development in Pune should be steering you toward by default.
| Checkout architecture | Card data touches your server? | Typical validation | Relative cost/complexity |
|---|---|---|---|
| Fully hosted/redirect checkout | No | SAQ A | Lowest |
| Gateway iframe embedded on your page | No (isolated by the iframe) | SAQ A or A-EP depending on setup | Low–moderate |
| Custom card form on your own page | Yes, transiently | SAQ A-EP or full ROC | High |
| Storing raw card numbers yourself | Yes, persistently | Full ROC, ongoing QSA relationship | Highest — avoid unless necessary |
Other 4.0.1 Requirements Worth Knowing Beyond Passwords
Password length is the easiest requirement to explain, which is why it gets cited most often, but it isn't the only mandatory change that arrived with the end of the transition period. A handful of others are worth flagging specifically because they change what "secure enough" looked like under the older 3.2.1 standard:
Multi-factor authentication is now required for all access into the cardholder data environment, not just for remote or administrative access as under the previous version. If a staff member can log into any system that touches card data — including from inside your own office network — a password alone is no longer considered sufficient, and MFA needs to be in place for that account.
More frequent, more targeted vulnerability scanning. Where the older standard was satisfied by a periodic scan on a fixed schedule, the current approach expects scanning aligned to how your systems actually change, with authenticated internal scans and a clearer expectation that identified vulnerabilities get remediated on a defined timeline, not left open indefinitely between audit cycles.
A documented, ongoing risk analysis, not a one-time exercise. The standard now expects merchants and service providers to justify how frequently certain controls are reviewed based on an actual risk assessment specific to their environment, rather than defaulting to whatever generic annual cycle a template compliance document suggests.
For a small or mid-sized Pune ecommerce operation using a hosted checkout (SAQ A), most of these heavier requirements sit with your payment gateway rather than your own site — which is, again, precisely why keeping card data out of your own infrastructure is the practical decision that protects you from most of this complexity, not just a security nicety.
What to Actually Ask Your Developer or Agency
"Which SAQ category does our checkout fall into, and why?" A developer who can answer this specifically — not "don't worry, the gateway handles it" — understands the architecture's compliance implications. "The gateway handles it" is sometimes true and sometimes a sign nobody has actually checked which SAQ category applies.
"Do our admin and staff accounts already meet the twelve-character password requirement?" This is the most commonly missed item precisely because it sounds too minor to prioritise. An admin panel, a CMS login, and any API keys with access to order or payment data all fall under this requirement now, not as a future recommendation.
"When was our last PCI DSS self-assessment actually completed, and by whom?" Many small merchants sign a payment gateway's terms of service years ago, tick a compliance box once, and never revisit it. If nobody can produce a current SAQ or point to when it was last completed, treat that as an open item to close before your next product launch or marketing push, not something to defer indefinitely.
"If we ever add a custom checkout field, saved-card feature, or a new payment method, will that change our compliance category?" Any change to how card data flows through your site can shift you between SAQ categories. This should be a standing question for every checkout feature request, not a one-time assessment done at launch and forgotten.
Frequently Asked Questions
Is PCI DSS compliance legally required in India, or just a card-network rule?
It functions as both. PCI DSS itself is a card-network contractual standard, not an Indian statute, but the RBI has built mandatory PCI DSS certification directly into its regulatory requirements for Payment Aggregators, and your ability to accept card payments at all depends on working with an RBI-authorised, PCI-DSS-certified aggregator. In practice, non-compliance risks both your payment processing relationship and, depending on your own site's role in the cardholder data environment, your gateway contract.
Does using a well-known payment gateway like Razorpay, PayU or Cashfree automatically make my store compliant?
It makes the gateway's infrastructure compliant — those providers maintain their own PCI DSS certification as RBI-authorised aggregators. It does not automatically cover your own website's code, particularly if your checkout renders card fields directly rather than using the gateway's fully hosted or properly isolated embedded checkout. The safest and simplest path for most merchants is to use the gateway's hosted or iframe-isolated checkout specifically so your own site stays out of PCI DSS's harder-to-satisfy scope.
What actually happens if my store isn't compliant?
Consequences run through your payment gateway relationship rather than a direct government penalty: gateways can require remediation, restrict processing, or in serious cases terminate the merchant agreement, and in the event of a card-data breach, non-compliance significantly worsens both the financial liability (fines from card networks, forensic investigation costs) and the reputational damage, since it becomes public that basic, well-documented security requirements weren't being met.
How much does becoming PCI DSS compliant actually cost for a small Indian ecommerce business?
For a store using a fully hosted or properly isolated checkout (SAQ A), the direct cost is often minimal — largely staff time to complete the annual self-assessment questionnaire correctly and fix any password-policy gaps. Costs rise meaningfully for SAQ A-EP or full audit scenarios, which typically require a security consultant or QSA engagement; this is a strong practical argument for choosing a hosted or iframe-based checkout architecture from the start rather than a custom card form, unless there's a specific business reason that outweighs the added compliance cost.
What is the difference between "PCI DSS" and "PCI DSS 4.0.1" — do I need to ask specifically for the .1 version?
No — 4.0.1 is a clarifying revision of 4.0 itself, correcting wording and closing minor ambiguities rather than introducing new requirements on top of it. When a vendor, gateway or auditor references "PCI DSS 4.0" today, they mean the current enforced standard, which in practice is 4.0.1; there's no separate, higher bar hiding behind the version-number difference. What matters is confirming you're being assessed against the current version at all, not the older 3.2.1 standard some smaller providers may still be quietly running against.
We're a small store doing maybe fifty orders a month — does any of this really apply to us at our scale?
Yes. PCI DSS applicability is based on whether you process card data at all, not on transaction volume — a business processing a handful of card payments a month has the same SAQ obligation as one processing thousands, though the depth of the requirement (SAQ A versus higher categories) still depends on your checkout architecture rather than your size. Smaller merchants are, if anything, more exposed to the consequences of getting this wrong, since they typically have less security infrastructure to fall back on if something goes wrong.
Our developer says the site is "GST 2.0 ready" and "secure" — does that cover PCI DSS too?
Not necessarily, and it's worth asking the question directly rather than assuming. GST-related tax compliance and PCI DSS card-data security are entirely separate requirements handled by different systems and, usually, different vendors — a site can be fully correct on GST invoicing and tax rates while still running a checkout architecture that pulls it into a heavier PCI DSS category than necessary, or one where staff accounts don't meet the current password and MFA requirements. Ask about PCI DSS specifically; general reassurance about "security" isn't the same thing as a stated SAQ category.
Where to Start
Govindani Infotech builds ecommerce checkouts from Pune that default to hosted or properly isolated gateway integrations specifically to keep our clients in the simplest PCI DSS category their business model allows, and every project handover includes a plain-language note on which SAQ applies and why — because a merchant who understands their own compliance position catches problems before a gateway or auditor does.
If you're planning a new store through our ecommerce or payment gateway integration work, or reviewing an existing checkout system that hasn't been security-reviewed since before 2025, we're glad to walk through your current architecture and tell you plainly which SAQ category you're actually in. You can see completed ecommerce projects in our portfolio, or reach out on WhatsApp for a quick compliance check before your next sale event puts real transaction volume through an unreviewed checkout.