PCI DSS and Website Security: A Guide for UK Businesses | Yrzo AI

What Is PCI DSS and Why Does It Apply to Your Website?

If your UK business accepts credit or debit card payments online — whether through your own checkout, an e-commerce platform, or a payment gateway integration — you are in scope for the Payment Card Industry Data Security Standard (PCI DSS). This isn't optional. It's a contractual requirement imposed by Visa, Mastercard, American Express, and other card schemes through your merchant agreement with your payment processor or acquiring bank.

PCI DSS is now on version 4.0, published in March 2022 with full enforcement from March 2025. Version 4.0 places significantly greater emphasis on web application security, penetration testing, and continuous monitoring — changes that directly affect how UK merchants manage their websites.

Failure to comply with PCI DSS doesn't result in direct regulatory fines from a government body (unlike UK GDPR). Instead, non-compliance can lead to your acquiring bank withdrawing your ability to accept card payments, fines from the card schemes passed on through your acquirer, and liability for fraudulent transaction costs if a breach occurs while you were non-compliant.

Who Needs to Be PCI DSS Compliant?

Every organisation that stores, processes, or transmits cardholder data must comply with PCI DSS. The compliance requirements scale based on your transaction volume and how you handle card data:

**SAQ A (Self-Assessment Questionnaire A)** — For merchants that have fully outsourced all payment functions to a PCI DSS compliant third party (e.g., Stripe or PayPal hosted payment pages) and whose website only redirects customers to the payment provider. This is the lightest compliance burden. Most small UK e-commerce businesses using Shopify Payments, WooCommerce with Stripe, or similar can aim for SAQ A.

**SAQ A-EP** — For merchants whose website delivers payment pages hosted by a third party but where the merchant's own JavaScript runs on the payment page (e.g., embedded payment forms). This is more common than merchants realise and carries significantly more requirements.

**SAQ D** — For merchants that process card data directly on their own systems, store card data, or have complex environments. This covers the full range of PCI DSS requirements and is the most demanding compliance tier.

The key question for your website is: at any point in the payment flow, does cardholder data pass through your systems or your website's code? If the answer is yes for anything beyond a redirect, your compliance requirements increase accordingly.

PCI DSS 4.0 Requirements That Directly Affect Your Website

Requirement 6: Develop and Maintain Secure Systems and Software

PCI DSS Requirement 6 covers your web application security posture comprehensively:

**6.2 — Bespoke and custom software is developed securely.** If your checkout is custom-built rather than an off-the-shelf platform, your development process must follow secure development practices — input validation, output encoding, proper authentication, and protection against the OWASP Top 10.

**6.3.2 — An inventory of bespoke and custom software is maintained.** You must know what code is running on your payment-related systems, including third-party scripts.

**6.4 — Public-facing web applications are protected against attacks.** This is where PCI DSS 4.0 is most specific about websites. You must either:

- Deploy a Web Application Firewall (WAF) in front of your payment application, OR - Perform a web application penetration test at least annually (and after any significant change) conducted by a qualified internal or external party

**6.4.3 — All payment page scripts are managed and authorised.** This is a new and significant requirement in PCI DSS 4.0. Every piece of JavaScript that loads on your payment page must be:

- Inventoried with a justification for why it's present - Reviewed periodically to confirm it's still necessary and hasn't been tampered with - Prevented from being loaded from unauthorised sources (typically enforced through a Content Security Policy)

This requirement directly targets skimming attacks — where attackers inject malicious JavaScript into payment pages to steal card data as it's typed. The British Airways breach of 2018, which resulted in a £20 million ICO fine, involved exactly this type of attack.

Requirement 11: Test Security of Systems and Networks Regularly

**11.3 — External and internal penetration testing is performed.** PCI DSS requires penetration testing at least annually and after any significant infrastructure change or upgrade. The test must cover:

- Network-layer testing of your cardholder data environment - Application-layer testing of all web applications that store, process, or transmit cardholder data

**11.4 — External and internal penetration testing is performed regularly.** The tester must be a qualified internal resource or a qualified external penetration testing organisation. PCI DSS doesn't mandate that you use a Qualified Security Assessor (QSA) for penetration testing specifically, but the testing must be conducted by someone with sufficient expertise.

**11.6.1 — A change-and-tamper-detection mechanism is deployed.** For SAQ A-EP merchants and above, you must implement monitoring to detect changes to payment page HTTP headers and script content. This is specifically designed to catch skimming attacks.

Requirement 12: Support Information Security with Organisational Policies

PCI DSS 4.0 requires formal policies and procedures for your security testing programme. Your penetration test findings must be documented, prioritised, and remediated within defined timescales. Critical vulnerabilities must be addressed within one month.

Common PCI DSS Failures in UK E-Commerce Websites

Skimming (Magecart-style) Attacks

The most significant active threat to UK online merchants is payment page skimming. Attackers compromise a plugin, theme, or third-party script that loads on your checkout page and inject JavaScript that intercepts card data as customers type it.

These attacks are difficult to detect because they don't change what the customer sees — the payment appears to process normally. The stolen card data is silently sent to the attacker's server in the background.

PCI DSS 4.0's Requirement 6.4.3 exists specifically to force merchants to inventory and monitor their payment page scripts. If you can't tell what JavaScript is running on your checkout page, you can't detect when something malicious has been added.

Third-Party Payment Form Embedding

Many UK merchants embed payment forms from their provider using iframes or JavaScript widgets. This is generally secure when done correctly, but problems arise when:

- The merchant's own site JavaScript has access to card field content (defeating the point of the third-party hosted field) - CSP headers aren't configured to restrict which domains can load scripts on the payment page - The embedded form fails to load over HTTPS

Outdated E-Commerce Platform Components

WooCommerce, Magento, and PrestaShop power a large proportion of UK e-commerce. Each has had significant security vulnerabilities. Running an outdated version of these platforms, or outdated payment gateway plugins, puts your cardholder data environment at risk and puts you in breach of PCI DSS Requirement 6.

Insecure APIs

UK merchants increasingly use APIs to connect their website to payment processors, inventory systems, and fulfilment partners. APIs that handle order data, even without directly processing card numbers, can be in scope if they transmit cardholder data in any form. API security testing — including authentication, rate limiting, and input validation — must be included in your penetration test scope.

Penetration Testing for PCI DSS Compliance: What to Include

A PCI DSS penetration test for a UK e-commerce website should cover:

**Web application layer:** - OWASP Top 10 vulnerability classes (injection, broken access control, cryptographic failures, etc.) - Business logic testing for your checkout flow (price manipulation, quantity tampering, coupon code bypass) - Authentication testing on admin panels and customer accounts - Session management testing - Payment page script inventory and CSP review

**Network layer:** - Exposure of admin interfaces to the internet - Firewall rule review for cardholder data environment - TLS configuration on all in-scope domains

**Third-party integrations:** - Payment gateway API security - Webhook validation (do your webhooks verify that requests genuinely come from your payment provider?) - OAuth and API key security

**Social engineering (optional but recommended):** - Phishing tests targeting staff with access to payment systems - Physical security review if your card acceptance environment includes physical terminals

How Yrzo AI Supports PCI DSS Compliance

Yrzo AI's continuous automated penetration testing is designed to keep your web application security posture aligned with PCI DSS requirements between your annual formal tests:

- **Continuous vulnerability scanning** catches new issues as they emerge, not once a year - **Payment page monitoring** alerts you when new scripts appear on your checkout pages - **OWASP Top 10 coverage** ensures your application is tested against the vulnerability classes PCI DSS specifically references - **Compliance-ready reports** give you documentation to show your acquiring bank or QSA

For businesses working toward full PCI DSS compliance, Yrzo AI pairs with a formal annual penetration test conducted by a qualified security firm to meet both the continuous monitoring and periodic assessment requirements.

**[Start your PCI DSS compliance journey → Try Yrzo AI free at yrzoai.dev](https://yrzoai.dev)**

Your payment page is the highest-value target on your website. Continuous testing is the only way to know it's actually secure.