Penetration Testing for E-commerce: Checkout and PCI Scope

Ecommerce penetration testing is the only reliable way to prove that the part of your business that takes money is not the part an attacker can quietly own. An online store is a payment system, an identity system and a web application stacked on top of each other, and a weakness in any layer can expose card data or let an attacker redirect orders and refunds. This guide explains what to test, how PCI DSS scope shapes the work, where checkout fails in practice, and how scope translates into budget for a UK retailer. For the wider picture of how we support online businesses, see the sectors we work in.

Why ecommerce stores are a high-value target

An online store concentrates two things attackers want at once: live card payment flows and a large base of customer accounts holding names, addresses, order history and stored payment tokens. The most damaging attacks on UK retailers are rarely brute-force smash-and-grabs; they are quiet, persistent compromises that monetise the store without breaking it.

Digital skimming, often called Magecart, is the defining ecommerce threat. An attacker who can inject a few lines of JavaScript into a checkout page, or into a third-party script the page loads, can harvest card details as customers type them, with the store running normally and no obvious sign of compromise. Alongside skimming, retailers face credential stuffing, coupon and pricing logic abuse, account takeover that drains loyalty balances, and business logic flaws that let an attacker order goods for less than they should pay. Penetration testing exists to find these exploitable paths before they are abused, so you are reading a report rather than answering to a card scheme and the Information Commissioner’s Office.

How PCI DSS scope shapes an ecommerce test

PCI DSS is the practical driver behind most ecommerce penetration testing, and it shapes both what you must test and how often. Requirement 11.4 of PCI DSS v4.0 requires external and internal penetration testing at least annually and after any significant change, performed using a documented methodology, with findings remediated and retested. The detail that catches retailers out is segmentation: if you use network segmentation to reduce the systems in scope, requirement 11.4.5 requires you to test that the segmentation actually works, because a flaw there pulls the rest of your estate back into the cardholder data environment.

How much of your store falls into PCI scope depends heavily on how you take payment. The integration model is the single biggest factor in both scope and risk.

• Fully hosted redirect or iFrame (SAQ A): the customer is handed to the payment provider, so your servers never touch card data. Scope is smallest, but the page that loads the iFrame and any scripts on it are still attackable, which is exactly where skimming lives.
• Direct post or JavaScript SDK (SAQ A-EP): card data is captured in the customer’s browser on your page and posted to the provider. Your checkout page is firmly in scope because it controls the payment form and the scripts around it.
• Self-hosted or gateway integration (SAQ D): your systems process or transmit card data directly. This is the broadest scope, pulling in servers, applications and the supporting network.

Knowing which model you run is the first scoping question we ask, because it decides whether the test is a focused application engagement or a wider infrastructure and application programme. Getting this right keeps the test proportionate and keeps your PCI evidence clean.

What to test inside an online store

A good ecommerce scope follows the money and the data rather than testing the homepage and stopping. The components below are where we focus most retail engagements.

Checkout and payment flow

Checkout is the highest-risk area and gets the most attention. Testing examines the payment form and the scripts loaded around it for skimming exposure, the integrity of the redirect or iFrame, and whether the order total, currency and amount sent to the payment provider can be tampered with in transit. The aim is to confirm that the price the customer agrees is the price that is actually charged and captured, and that nothing on the page can quietly read their card number.

Business logic and pricing abuse

Ecommerce platforms are full of stateful logic that automated scanners miss entirely. Testers manually probe whether discount codes can be stacked or replayed, whether negative quantities or currency manipulation reduce the total, whether out-of-stock or restricted items can be added, and whether the order, refund and returns workflow can be abused to obtain goods or money for free. This manual business-logic testing is where senior testers earn their value over a tool.

Accounts, authentication and stored data

Customer accounts hold personal data and often saved addresses and payment tokens. Testing covers registration and login for credential stuffing resilience, password reset for account takeover, multi-factor handling, session management, and whether one customer can reach another customer’s orders or saved details by manipulating identifiers. Insecure direct object references in the orders or account area are a recurring finding on UK stores.

Application, APIs and third-party scripts

Beneath the storefront sits the application stack, the headless or mobile APIs that increasingly power modern retail, and a long tail of third-party tags for analytics, chat and marketing. Each loaded script is a potential skimming vector. Testing covers the classic web application weaknesses, the APIs that bypass the user interface, and the content-security and integrity controls that should constrain what third-party code can do on the checkout page.

Admin, plugins and infrastructure

The store admin panel, the CMS or platform such as Magento, WooCommerce or a custom build, its plugins and extensions, and the hosting infrastructure all sit behind the shopfront. Outdated extensions are a frequent route to a full store compromise, so external infrastructure and the admin attack surface are tested alongside the customer-facing application.

How an ecommerce engagement runs

A professional ecommerce test is built around one constraint above all: do not break trading. Work is authorised in writing and scoped against the systems that take payment and hold customer data. Wherever possible, exploitation and any potentially disruptive testing run against a staging environment that mirrors production, with carefully controlled, low-impact checks against the live store so a sale is never lost and no real card is charged. Reconnaissance maps the real attack surface including every third-party script, exploitation safely confirms which weaknesses are genuinely usable, and post-exploitation analysis shows how far an attacker could reach toward card data, accounts or the admin panel.

The deliverable is written for two audiences at once. Your developers and platform agency get a technical remediation section with reproduction steps and risk-rated findings, and your finance or operations lead gets a plain summary they can put in front of an acquiring bank, a qualified security assessor or the board. Findings are mapped to the PCI DSS requirements they touch, so the report drops straight into your compliance evidence.

What it costs and how scope drives the price

Price for an ecommerce test is driven by scope complexity measured in tester days, not by your revenue. The integration model, the number of distinct user roles and workflows, the presence of APIs, and whether infrastructure and segmentation testing are in scope all move the day count. All testing is delivered by senior and principal testers at a typical UK day rate of around £1,200 to £1,300, so a focused checkout and web application engagement of four to six days sits in the region of £4,800 to £7,200, and a broader programme adding APIs, internal segmentation testing and a self-hosted payment stack across eight to ten days lands around £9,600 to £12,000.

The way to keep the cost proportionate is a tight scope built around your actual payment model and the highest-risk workflows, rather than testing every page by reflex. We set out exactly how day counts translate into budget, and what changes the count, in our guide to UK penetration testing cost, so you can plan the spend before committing. Fixed pricing against a defined scope means no surprise day-rate creep mid-engagement.

How EJN Labs approaches ecommerce penetration testing

EJN Labs is a CREST-accredited penetration testing firm, and we hold Cyber Essentials, Cyber Essentials Plus, ISO 27001 and ISO 9001 ourselves. That matters to an online retailer, because the report you hand to your acquiring bank, your qualified security assessor or a corporate marketplace partner carries the weight of an independently assessed provider. Our testing is delivered by senior and principal testers, never junior staff, which is the level of skill manual business-logic and skimming analysis genuinely requires.

Every engagement maps findings to the standards that matter to you, including PCI DSS requirement 11.4 and UK GDPR Article 32, so the report slots straight into your compliance pack. We scope on a defined day count with fixed pricing, schedule disruptive work against staging to protect trading, write the report for both your developers and your commercial team, and include a free retest to confirm that fixes have actually closed the findings. To see the industries we support, browse our sectors, or read more about our services.

Frequently Asked Questions

Is penetration testing required for ecommerce under PCI DSS?

Yes, if you store, process or transmit cardholder data, PCI DSS requirement 11.4 requires external and internal penetration testing at least annually and after any significant change, using a documented methodology. If you reduce scope with network segmentation, requirement 11.4.5 also requires you to test that the segmentation works. Even stores using a fully hosted payment redirect should test the checkout page and its scripts, because digital skimming targets the page that loads the payment form rather than the payment provider itself.

Will testing my live store disrupt sales or charge real cards?

No, when it is run properly. Potentially disruptive and exploitation testing is scheduled against a staging environment that mirrors production, with only carefully controlled, low-impact checks against the live store. Test card numbers and sandbox payment credentials are used so no real customer is charged and no genuine order is placed. The engagement is designed around protecting trading, so a professional test strengthens your checkout rather than threatening a sale.

What does ecommerce penetration testing cost in the UK?

Cost is driven by scope complexity in tester days rather than your revenue. A focused checkout and web application test typically runs to four to six tester days at a UK day rate of around 1,200 to 1,300 pounds, which is roughly 4,800 to 7,200 pounds. Adding APIs, a self-hosted payment stack and internal segmentation testing increases the day count. A scope built around your actual payment integration and highest-risk workflows keeps the price proportionate.

How often should an online store be penetration tested?

The accepted baseline, and the PCI DSS expectation, is at least annually and additionally after any significant change. For ecommerce that means after a platform upgrade, a checkout or payment provider change, a new plugin or theme, a migration to a headless or mobile API, or any change to the scripts loaded on the checkout page. Tying testing to change as well as the calendar is the risk-based approach that card schemes and assessors expect.

What is digital skimming and can a pen test find it?

Digital skimming, often called Magecart, is when an attacker injects malicious JavaScript into a checkout page, or into a third-party script the page loads, to silently harvest card details as customers type them. It is the dominant ecommerce threat because the store keeps working normally. A penetration test finds the weaknesses that allow it, such as weak content-security policy, missing subresource integrity, vulnerable plugins and over-permissive third-party tags, so you can close the routes a skimmer would use.

Which systems should an ecommerce store include in scope?

Scope should follow the money and the data. The priorities are the checkout and payment flow including all third-party scripts, business and pricing logic, customer accounts and authentication, the application and any headless or mobile APIs, and the admin panel, plugins and supporting infrastructure. Where segmentation reduces PCI scope, the segmentation controls should be tested too. A scope built around these answers both your PCI obligations and the real attack paths a fraudster would use.

Secure your checkout with a test built for online retail

If your store takes payment and holds customer accounts, ecommerce penetration testing is the most reliable way to prove that checkout, payments and customer data are protected by controls that actually work, mapping cleanly to PCI DSS requirement 11.4 and UK GDPR Article 32. To get a fixed scope and price delivered by senior, CREST-certified testers, request a penetration testing quote, or explore the sectors we support first.