In short
The Payment Card Industry Data Security Standard (PCI DSS) sets security rules for anyone who stores, processes or transmits payment card data, or whose systems can affect its security. Version 4.0.1 is current, and its future-dated requirements became mandatory on 31 March 2025. Two of them target the payment page itself: control every script and detect tampering. In India, RBI’s card-on-file rules and a compliant payment gateway let most merchants keep card data out of their own systems, which shrinks what PCI DSS covers.
Who it applies to
- Merchants that accept card payments, online or in store, whatever their size.
- Service providers that store, process or transmit card data for others, or can affect its security, such as gateways, payment aggregators and some hosting providers.
- Merchant levels are set by the card brands, mostly by yearly transaction count. Visa’s Level 1, for example, starts above 6 million transactions a year. Your acquiring bank tells you your level and how to prove compliance.
- Ways to prove it. Larger merchants and service providers usually need an on-site assessment. Others fill a self-assessment questionnaire (SAQ):
- SAQ A: card-not-present merchants whose payment page elements all come only and directly from a PCI DSS compliant provider, and whose site is not susceptible to script attacks that could affect payments.
- SAQ A-EP: e-commerce merchants who outsource payment processing but whose website can affect payment security. It adds many more requirements.
- SAQ D: merchants that do not fit a shorter SAQ, and service providers.
The PCI Security Standards Council writes the standard but does not enforce it. Card brands and acquiring banks do, through merchant agreements.
What it means for your website
Choose the checkout design first
How the card form reaches the customer decides most of your PCI DSS work. With a full redirect to the gateway’s hosted page, the gateway serves the payment page. With an embedded iframe, your page hosts the gateway’s form, so scripts on your page can still affect it. If your own page collects or posts card data, you are well outside SAQ A.
Requirement 6.4.3: control payment page scripts
Every script loaded and run in the customer’s browser on a payment page must be authorised, have its integrity checked, and be listed in an inventory with a written reason. This targets e-skimming, where an injected script copies card details as they are typed. Content Security Policy (CSP) and Subresource Integrity (SRI) are common ways to meet it.
Requirement 11.6.1: detect tampering
A change- and tamper-detection mechanism must alert staff to unauthorised changes to the payment page’s scripts and security-related HTTP headers, as the customer’s browser receives them. It must run at least weekly, or at a frequency set by a targeted risk analysis (requirement 12.3.1).
What changed for SAQ A
The SAQ A form in use from 31 March 2025 removed 6.4.3, 11.6.1 and 12.3.1. In their place, merchants must confirm their site is not susceptible to attacks from scripts that could affect their e-commerce systems. Merchants who cannot confirm this move to SAQ A-EP. The two requirements still apply under SAQ D and on-site assessments. Regular external vulnerability scans of your site also remain part of SAQ A (requirement 11.3.2).
What it means for your software
Keep card data out of your systems
Since 1 October 2022, RBI rules say no entity in the card payment chain other than card issuers and card networks may store card-on-file data. Merchants and their software keep a token, an alias that works only for that merchant, instead of the card number. Design your ERP, e-commerce and subscription systems around tokens and gateway references. See RBI payments and e-commerce.
Watch for card data leaking in
Card numbers end up in places nobody planned: order notes, support tickets, call recordings, spreadsheets, email and application logs. Mask card numbers in any field that could receive them, and scrub logs. Train staff not to accept card details by phone or email into business systems.
Secure the gateway integration
The back end that creates payment orders and receives the gateway’s callbacks is part of payment security. Verify the signature on every callback, confirm the amount and order match, and never trust payment status sent from the browser. Keep gateway keys out of source code.
Know when you become a service provider
If your company hosts or runs payment pages, or integrations that can affect card security, for other businesses, those clients may treat you as a service provider. Then they will ask for your own PCI DSS evidence.
Change control for payment pages
Because 6.4.3 and 11.6.1 apply to what the browser receives, every release that touches checkout needs a script inventory review. Tag managers and marketing scripts are a frequent gap: keep them off payment pages.
Checklist
- Ask your acquiring bank or gateway which merchant level and SAQ apply to you.
- Map how card data flows: checkout, phone orders, refunds, subscriptions and support.
- Prefer a redirect or iframe checkout from a PCI DSS compliant gateway.
- Store only tokens and gateway references, never card numbers or CVV.
- List every script on your payment and checkout pages, with an owner and reason.
- Add Content Security Policy and Subresource Integrity, and remove scripts you cannot justify.
- Set up tamper detection on payment pages and alerting to a named person.
- Verify gateway callbacks on the server and keep keys out of code.
- Run regular external vulnerability scans and fix what they find.
- Complete your SAQ or assessment every year and keep the evidence.
How Kreon helps
We build e-commerce and ERP systems that use hosted or embedded gateway checkouts and store tokens, so card data stays out of your database. We design payment pages without tracking scripts and verify gateway callbacks on the server. We can prepare your site and systems for your SAQ or assessor and fix findings. Kreon is not a PCI DSS assessor, so validation comes from your bank’s process or a qualified assessor.