11Aug 2026

PCI online payment for UK merchants: what to do

Hands connecting secure network cable in UK office

For any UK merchant accepting card payments online, PCI DSS (the Payment Card Industry Data Security Standard) is the baseline requirement that your checkout must meet. The single most effective action for most businesses is to use a PCI-validated payment service provider with a hosted checkout or iFrame integration, which keeps card data off your systems entirely and dramatically reduces your compliance burden.

Before you read further, run through these three checks right now:

  • Confirm your PSP holds a current Attestation of Compliance (AoC) or appears on the Visa or Mastercard service provider registries.
  • Verify TLS is active on every checkout page — not just the payment form, but every page in the flow.
  • Audit third-party scripts on your checkout pages — analytics tags, chat widgets, and tracking pixels that load on the payment page expand your scope and create real breach risk.

If your provider is hosted or redirect-based and you can tick all three, you are already on the right path. The rest of this guide explains exactly why, maps your integration method to the correct Self-Assessment Questionnaire (SAQ), and gives you a practical checklist to complete the process.

Key takeaways

PCI DSS compliance for online payments is primarily a scope management exercise: the right PSP and integration method determine most of your compliance burden before you write a single line of code.

Point Details
Choose hosted checkout or iFrame Keeping card data off your systems reduces your SAQ to A or A-EP and cuts compliance effort significantly.
Verify your PSP’s AoC and registry listing Request the current Attestation of Compliance and confirm the provider appears on the Visa/Mastercard service provider registries.
Audit scripts on checkout pages Every third-party script on a payment page is a potential scope expansion and a breach risk; remove all non-essential ones.
Map your SAQ before you build Your integration method determines your SAQ; confirm with your acquirer before committing to a technical approach.
Treat compliance as ongoing Re-complete your SAQ annually, run ASV scans at the required cadence, and review your PSP’s compliance status each year.

Table of Contents

What is PCI DSS and why does it matter for online payments in the UK?

PCI DSS is a global security standard created and maintained by the PCI Security Standards Council (PCI SSC), a body founded by the major card brands including Visa and Mastercard. It sets 12 principal requirements covering everything from network security and access control to vulnerability management and security testing. Every organisation that stores, processes, or transmits cardholder data is in scope, regardless of size or transaction volume.

The cardholder data environment (CDE) is the core concept you need to understand. It refers to the people, processes, and technology that touch card data — the primary account number (PAN), cardholder name, expiry date, and sensitive authentication data such as CVV codes. Anything connected to or capable of affecting the security of the CDE is also considered in scope. For an online merchant, that typically includes your web server, payment plugin, checkout pages, and any system that could reach card data.

In the UK, enforcement comes primarily through your acquiring bank (the bank that processes your card transactions). Acquirers are required by Visa and Mastercard to ensure their merchants validate PCI compliance. Failure to comply can result in fines passed down from the card brands, increased transaction fees, or in serious cases, the loss of your ability to accept card payments. The Visa Europe and Mastercard Europe service provider registries list validated third-party providers, and you should use these to verify any PSP you work with.

GOV.UK Pay, the UK government’s own payment platform for public services, publishes specific guidance on secure payment solutions and points merchants to validated devices and registries — a useful reference even for private-sector organisations.

Pro Tip: Small merchants are not exempt from PCI DSS. The validation route is simpler (SAQs rather than a full QSA audit), but the underlying obligation to protect cardholder data is identical to that of a large enterprise.

What changed in PCI DSS v4.0 and what does it mean for your ecommerce setup?

PCI DSS v4.0 replaced version 3.2.1 as the active standard in March 2024, with a transition period that gave organisations time to adopt new requirements. The most significant shift for online merchants is the move towards outcomes-based controls: rather than prescribing a single technical method, v4.0 allows organisations to demonstrate that a control achieves the intended security outcome, which matters most for custom integrations and bespoke software.

For UK ecommerce merchants, the practical implications cluster around three areas:

  • Software security practices: v4.0 places greater emphasis on secure software development and the PCI SSC’s Software Security Framework (SSF). If you use custom payment software or plugins, those components need to align with secure lifecycle practices. The PCI SSC maintains a validated payment software list — checking it before deploying any payment component is a straightforward risk-reduction step.
  • Script management on payment pages: v4.0 introduced explicit requirements around managing and authorising scripts that execute in the consumer’s browser on payment pages. This directly affects merchants who load third-party tags (analytics, A/B testing tools, chat widgets) on checkout pages.
  • SAQ selection and customised approach: v4.0 introduced a “customised approach” option for mature organisations that want to implement controls differently from the standard method. For most UK small and mid-sized merchants, the defined approach (standard SAQs) remains the practical route.

The key deadline most UK merchants needed to act on was 31 March 2025, by which date all new v4.0 requirements became mandatory. If your last SAQ was completed under v3.2.1 and you have not reviewed your controls since, that review is overdue.

How is your PCI scope determined, and which SAQ will you need?

Your PCI scope is determined by how card data flows through your environment. The more directly card data touches your systems, the broader your scope and the more demanding your validation requirements.

The table below maps common integration methods to their typical SAQ, key scope notes, and primary validation activities.

Integration method Typical SAQ Merchant CDE in scope? Key validation activities
Fully hosted checkout (redirect to PSP page) SAQ A No — card data never touches merchant systems Confirm PSP AoC; complete SAQ A
iFrame / hosted fields (PSP-controlled fields embedded in merchant page) SAQ A or A-EP Partial — merchant controls page but not card fields Confirm PSP AoC; check for scripts on checkout page; SAQ A-EP if merchant JS affects the iFrame
Direct API / server-side card capture SAQ D Yes — card data passes through merchant server Full SAQ D or QSA assessment; ASV scans required
MOTO / virtual terminal (staff-keyed) SAQ C-VT Limited — staff access only, no electronic storage SAQ C-VT; access controls and logging review
P2PE validated solution SAQ P2PE No — encrypted at point of capture SAQ P2PE; confirm P2PE solution listing

The practical rule is straightforward: the further card data stays from your servers and your code, the lighter your compliance burden. PCI SSC guidance confirms that outsourcing the payment capture environment to a validated provider can materially reduce a merchant’s scope by keeping card data off their systems entirely.

A few nuances worth noting:

  • SAQ A-EP applies when a merchant uses a redirect or iFrame but their own JavaScript executes on the checkout page and could theoretically intercept card data. If you load any scripts on the payment page that you do not fully control, you may be pushed from SAQ A to A-EP.
  • SAQ D is the most demanding route and is typically required for merchants who accept card data directly via API or store PANs server-side. It covers all 12 PCI DSS requirement areas.
  • Your acquirer has the final say on which SAQ applies to your setup. When in doubt, ask them directly.

Which payment integration method is right for your business?

Choosing an integration method is a trade-off between user experience, PCI scope, and development effort. Here is how each option stacks up.

Hosted checkout (full redirect) sends the customer to a payment page entirely controlled by the PSP. Card data never touches the merchant’s domain. The PCI burden is minimal — typically SAQ A — and the integration is quick to deploy. The trade-off is limited control over the payment page design.

Hands adjusting payment terminal setup

iFrame / hosted fields embed PSP-controlled input fields within the merchant’s page. The customer stays on your site visually, but the card fields live in a separate browser context owned by the PSP. This is the most popular balance of user experience and scope reduction. Whether you land on SAQ A or A-EP depends on whether your own JavaScript can interact with the payment fields.

Direct API integration gives the most control over the payment experience but brings card data into your environment. Your server receives the PAN and passes it to the PSP. This triggers SAQ D and all 12 requirement areas. It is appropriate for large merchants with dedicated security teams, not for most small or mid-sized businesses.

P2PE (Point-to-Point Encryption) is primarily relevant for in-person or hybrid (in-person plus online) flows. A validated P2PE solution encrypts card data at the point of capture before it reaches any merchant system. The PCI SSC maintains a list of validated P2PE solutions. For pure ecommerce, hosted fields or a redirect typically achieve the same scope reduction.

Tokenisation is not an integration method on its own, but it works alongside any of the above. The PSP replaces the PAN with a non-sensitive token that your system stores for recurring billing. Stripe’s integration documentation illustrates how client-side tokenisation through hosted fields allows merchants to avoid handling PANs directly and qualify for lighter SAQ validation.

Pro Tip: For membership organisations and subscription businesses, the critical requirement is a PSP that supports recurring tokenised billing. Confirm that the token vault is held by the PSP (not your server), that webhook payloads never include raw PANs, and that your subscription management logic never logs card data. This keeps your scope narrow even as transaction volumes grow.

Practical steps to reduce your PCI scope and secure your payment environment

Scope reduction is not a one-time task. It is an ongoing discipline that covers both the payment form and the broader web environment around it.

Scope-reduction strategies:

  • Use a PCI-validated PSP with a hosted checkout or hosted fields integration as your default approach.
  • Implement tokenisation for any recurring or stored-payment use case so your systems never hold live PANs.
  • For hybrid in-person flows, use a P2PE validated solution to encrypt card data before it enters your network.
  • Apply network segmentation to isolate any systems that do touch card data from the rest of your infrastructure.

Hardening the broader environment is where many merchants fall short. PCI SSC guidance is explicit that attackers frequently target the merchant’s surrounding web environment — unpatched plugins, exposed admin panels, and unmonitored third-party scripts — to scrape card data in the browser before encryption occurs. Your security checklist should include:

  • Remove or block all non-essential third-party scripts from checkout pages. Use a Content Security Policy (CSP) header to whitelist only approved scripts.
  • Enforce multi-factor authentication (MFA) on all admin and back-end access points.
  • Apply a documented patching policy: critical patches within 30 days, high-severity patches within 60 days.
  • Configure TLS 1.2 or higher on all pages in the payment flow, not just the form itself.
  • Disable or remove any payment plugins that are no longer actively maintained.
  • Review server and application logs regularly to confirm no card data is being written to logs inadvertently.

For organisations managing secure online event hosting or ticketing alongside membership payments, the same principles apply: every page in the registration or checkout flow needs the same script controls and TLS configuration as the core payment page.

Pro Tip: Run a browser-based script audit on your checkout page using your browser’s developer tools network tab. Count every third-party domain that loads a resource. Each one is a potential attack vector and a potential scope expansion. If you cannot justify a script’s presence on the payment page, remove it.

How to choose a PCI-compliant PSP in the UK

Selecting the right payment service provider is the single decision with the greatest impact on your compliance burden. The PCI Small Merchant Guide recommends that most ecommerce merchants use a wholly outsourced, PCI DSS-validated third party to capture and process payments, and it provides practical vendor questions to help verify providers.

Compliance and security checks to request from any PSP:

  • Current Attestation of Compliance (AoC) — ask for the document, not just a verbal assurance.
  • PCI DSS level (Level 1 is the highest; most major PSPs operate at Level 1).
  • Listing on the Visa Europe and Mastercard Europe service provider registries.
  • Evidence of P2PE validation (if relevant to your use case) from the PCI SSC P2PE list.
  • ASV (Approved Scanning Vendor) scan reports for their infrastructure.
  • Validated payment software references under the PCI SSC Software Security Framework.

Commercial and operational checks:

  1. Which integration patterns do they support — hosted redirect, iFrame/hosted fields, direct API, mobile SDK?
  2. Do they support tokenised recurring billing, and where is the token vault held?
  3. What is their process for chargeback handling and dispute resolution?
  4. Where is cardholder data stored — UK, EU, or elsewhere? Does this align with your data residency requirements?
  5. What is their SLA for notifying you of a security incident that affects your merchant account?
  6. Do they provide documentation confirming which SAQ applies to each of their integration methods?

Where to verify PSP listings:

  • Visa Europe service provider registry: search at Visa’s merchant portal under “Visa Global Registry of Service Providers.”
  • Mastercard SDP (Site Data Protection) programme: search the Mastercard registered service provider list.
  • PCI SSC validated payment software: pcisecuritystandards.org/assessors_and_solutions.

Well-known UK-active providers including Stripe, Worldpay (FIS), Adyen, Checkout.com, and Evopayments all publish AoCs and appear on the major registries. Verify their current listing status directly — registries are updated periodically and a listing from 18 months ago does not confirm current compliance.

A practical checklist and timeline to achieve PCI compliance for online payments

Getting to compliance does not need to be a lengthy project if you choose the right integration route from the start.

Step-by-step order of operations:

  1. Map your scope. Identify every system, page, and process that touches card data. Document the data flow from the customer’s browser to your PSP and back.
  2. Choose your PSP and integration method. Opt for hosted checkout or hosted fields wherever possible to minimise scope. Confirm the provider’s AoC and registry listings before signing a contract.
  3. Integrate and configure. Implement TLS on all checkout pages, apply CSP headers, remove non-essential scripts, and configure MFA on admin access.
  4. Run an ASV scan if required for your SAQ (SAQ A and A-EP do not require ASV scans; SAQ D does). Use a PCI SSC-approved ASV vendor.
  5. Complete your SAQ. Work through the relevant questionnaire honestly. If any control is not in place, remediate before submitting.
  6. Record your AoC. Sign and retain the Attestation of Compliance. Your acquirer may request it at any time.
  7. Engage a QSA if needed. Merchants processing high volumes or using direct API integrations may need a Qualified Security Assessor rather than a self-assessment.

Typical timelines:

  • Hosted checkout route (SAQ A): 2–6 weeks from provider selection to completed SAQ, assuming no legacy integrations to unpick.
  • iFrame / hosted fields (SAQ A or A-EP): 4–10 weeks, depending on script audit complexity and any remediation required.
  • Direct API (SAQ D): 3–6 months minimum for a small merchant; longer if infrastructure changes are needed.

Cost considerations vary significantly. Hosted checkout integrations carry minimal additional compliance cost beyond the PSP’s standard fees. SAQ D routes may require ASV scans (typically £200–£800 per scan from a UK-based ASV vendor), penetration testing (costs vary by scope), and potentially QSA fees for larger assessments. Ongoing costs include annual SAQ completion, quarterly ASV scans where required, and periodic penetration testing.

For a rapid risk-reduction route, the priority sequence is: choose a hosted PSP, complete SAQ A, confirm TLS and CSP, and document your AoC. That covers the majority of the compliance obligation for most small UK online merchants.

A practical checklist and timeline to achieve PCI compliance for online payments — overview diagram

Common mistakes UK online merchants make that increase PCI scope

The most damaging errors are rarely in the payment form itself. They are in the environment around it.

  • Loading third-party trackers on checkout pages. A single analytics or retargeting script on your payment page can push you from SAQ A to A-EP, and in some configurations, into SAQ D territory. Audit every script on every page in the checkout flow.
  • Leaving admin access unsecured. Default credentials, shared passwords, and admin panels exposed to the public internet are among the most common entry points for attackers. Enforce MFA and restrict admin access by IP where possible.
  • Using unmaintained plugins. A WooCommerce or Magento plugin that has not been updated in 12 months is a known risk. Attackers actively scan for known vulnerabilities in popular ecommerce plugins.
  • Storing PANs in logs or analytics. Application logs, error tracking tools, and analytics platforms sometimes capture form field values. A single misconfigured logging statement can result in PANs being stored in plain text outside the CDE.
  • Assuming outsourcing removes all responsibility. It reduces scope significantly, but the merchant remains responsible for ensuring their PSP maintains compliance. As PCI SSC guidance states, customers who outsource must maintain oversight of their third-party service providers and ensure anything that could affect the CDE remains secure.
  • Treating compliance as a one-off project. PCI DSS is an annual obligation at minimum. Your environment changes — new plugins, new staff, new integrations — and each change can alter your scope.

How to verify compliance and what documentation to keep

Verification is not just about your own SAQ. It means confirming that every third party in your payment chain is also compliant, and retaining the evidence that proves it.

Key documents and artefacts to obtain and retain:

  • Your own signed Attestation of Compliance (AoC) — completed annually or at the cadence your acquirer requires.
  • Your PSP’s current AoC — request this directly from your provider and store a dated copy.
  • ASV scan reports — required quarterly for SAQ D merchants; retain passing scan reports for at least 12 months.
  • Penetration test reports — required annually for SAQ D; retain the report and any remediation evidence.
  • SAQ evidence — the completed questionnaire itself, plus any supporting documentation for controls you attested to.
  • Vendor compliance confirmations — written confirmation from any third-party service provider that handles card data on your behalf, confirming their PCI DSS scope and compliance status.

Where to verify PSP and solution claims:

  • GOV.UK Pay’s security page lists validated payment solutions and points to PCI SSC resources — a practical starting point for UK public-sector and private-sector merchants alike.
  • The PCI SSC website hosts lists of validated payment software, P2PE solutions, and Qualified Security Assessors.
  • The Visa Europe and Mastercard Europe service provider registries confirm whether a named PSP holds current validated status.

Retention guidelines:

  • Retain AoCs, SAQs, and scan reports for a minimum of 12 months after the period they cover.
  • Keep penetration test reports and remediation evidence for at least two years.
  • Store all compliance documentation securely, with access restricted to relevant staff.

Applying this to membership organisations: how Colossus approaches secure payments

Membership organisations face a specific set of PCI challenges. Recurring subscription payments, event registration fees, and donation flows all involve card data, and the combination of multiple payment touchpoints across a single platform increases the risk of scope creep.

The most common scope issues for membership platforms include:

  • Recurring subscription billing where tokens are stored for future charges. If the token vault sits on the membership platform’s server rather than the PSP’s infrastructure, the platform enters scope.
  • Event registration payments processed through a separate plugin or gateway that has not been assessed as part of the main compliance review.
  • Donation flows that use a different payment method or provider from the main membership subscription, creating a second CDE to manage.

Recommended implementation patterns for membership organisations:

  • Use a PSP that supports tokenised recurring billing and holds the token vault on their infrastructure. Your platform stores only the token reference, never the PAN.
  • Ensure webhook payloads from your PSP never include raw card data. Review webhook documentation before going live.
  • Apply the same script controls and TLS configuration to event registration and donation pages as to the main membership checkout.
  • For organisations managing secure credit card payments online, the principle is the same: keep card data with the PSP, not the platform.

Colossus integrates with PCI-compliant payment gateways to ensure that card data is handled by validated providers, keeping the Colossus platform outside the primary CDE for payment capture. For organisations managing subscription payments for nonprofits, this architecture means recurring billing can be managed within the platform without the platform itself storing sensitive card data.

Pro Tip: When evaluating any membership management platform for payment processing, ask specifically: “Where is the token vault held?” and “Does your platform ever receive or log raw PANs?” The answers tell you immediately whether the platform reduces your scope or expands it.

The compliance advice most merchants get is incomplete

Most PCI compliance guidance stops at “use a hosted checkout and complete your SAQ A.” That is correct as far as it goes, but it misses the part that actually causes breaches.

The conventional framing treats PCI compliance as a payment form problem. In practice, the payment form is often the most secure element on the page. The risk sits in everything else: the analytics script that fires on checkout, the chat widget loaded from a third-party CDN, the admin panel accessible on a predictable URL with a shared password. These are the vectors attackers use, and none of them appear on a standard SAQ A.

The second gap in conventional advice is the assumption that outsourcing to a validated PSP transfers responsibility. It transfers scope, not accountability. Your acquirer holds you responsible for your PSP’s compliance status. If your PSP’s AoC lapses and you have not checked it in 18 months, that is your problem as much as theirs.

What I would prioritise, in order: first, get the integration right (hosted fields or redirect, tokenised recurring billing, PSP-held token vault). Second, lock down the surrounding environment with the same rigour you apply to the payment form itself. Third, build a compliance calendar — annual SAQ, quarterly ASV scans where required, annual PSP AoC check — and treat it as a standing operational task, not a project with an end date.

The merchants who get into trouble are rarely the ones who chose the wrong PSP. They are the ones who chose the right PSP, completed their SAQ once, and then changed their checkout page six months later without reassessing scope.

Colossus: built for membership organisations that need secure, compliant payments

Colossus

Colossus is a membership management platform built for associations, nonprofits, and professional organisations that need to manage members, events, and payments in one place. Our platform integrates with PCI-compliant payment gateways so that card data is handled by validated providers, keeping your organisation outside the primary cardholder data environment for payment capture.

Whether you are managing recurring membership subscriptions, event registration fees, or donation flows, Colossus gives you the tools to handle payments securely without building compliance infrastructure from scratch. Explore our membership management features to see how we support secure, tokenised payment processing alongside member management, CRM, and event tools.

This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.

Sources

Every merchant should bookmark these resources. They are the primary verification points for compliance status, validated solutions, and authoritative guidance.

PCI SSC official resources:

UK-specific and payment brand resources:

PSP integration documentation: