PCI DSS for Small Business: What It Means When You Take Card Payments

PCI DSS for small business applies when you accept card payments, including through Stripe or PayPal. Using a payment provider can keep card details off your systems, but it does not remove your responsibilities. PCI DSS is not a UK law in itself; it is a card-industry standard normally enforced through payment agreements. A self-assessment questionnaire, or SAQ, is a way for an eligible business to show how it meets the requirements that apply to its payment setup.

The practical question is where the customer enters their card number and whether your website can affect that process. Moving card collection to a compliant provider can reduce your scope. Before choosing a questionnaire or changing checkout, establish the payment flow and ask the organisation accepting your compliance evidence to confirm what it requires.

What PCI DSS means for a small UK business

PCI DSS stands for Payment Card Industry Data Security Standard. It covers the protection of cardholder data during payment processing and, where relevant, storage and transmission. The PCI Security Standards Council says the standard is intended for merchants regardless of business size or transaction volume. Taking a few payments does not create an exemption.

For online shops, the main distinction is between handling card details yourself and passing customers to a provider that handles them. Card data includes the full card number, usually called the primary account number or PAN. The card security code is particularly sensitive: the PCI Council's guidance on verification codes says merchants must not retain it after authorisation, even encrypted.

Do not ask customers to send card numbers or security codes by email, chat or ordinary messages. The Council's messaging guidance prohibits sending unprotected card numbers through these channels. If your business receives card details unexpectedly, do not forward them into another system. The Council's guidance on unintended channels says to remove that data immediately or secure it under PCI DSS, and to stop the channel being used for card details again.

The Council's June 2026 request for comments calls PCI DSS v4.0.1 the currently published version, and on 5 November 2026 its PCI DSS page still grouped its guidance under v4.x. Use the current questionnaires and your provider's current instructions rather than an old checklist copied from another website.

Your checkout decides how much is in scope

Scope means the systems, people and processes that must be considered in your PCI assessment. The name on your payment account does not establish scope on its own. What matters is the actual path taken by card details and whether your site can change where the customer sends them. The PCI Council's explanation of payment-page origins makes this distinction explicit.

Customers leave your site for a hosted payment page

Suppose an order page sends the customer to the provider's separate payment page. The provider presents the card fields, receives the card details and returns a payment result to your shop. Fulfil an order only after the provider's API or a verified webhook confirms the payment succeeded, not because the customer's browser came back. If every SAQ A eligibility condition is met, this can be a lower-scope arrangement. A redirect does not make your own site irrelevant: an attacker who changes its payment link may send customers elsewhere.

Stripe describes its hosted Checkout product in its PCI compliance guide. PayPal also supplies hosted payment options, but a PayPal logo or button alone does not prove that no card details pass through your systems. Check the selected integration and every other card channel you use.

Card fields appear inside your page

An embedded payment form may look as though it belongs to your website while every element that collects card data is delivered by the provider in a protected frame. This can also be eligible for SAQ A, but the exact implementation matters. The Council's SAQ A script guidance says an e-commerce merchant using an embedded provider form must confirm that its page is protected against scripts that could compromise the payment process.

The Council allows that confirmation through suitable protective techniques or the compliant provider's confirmation about a correctly implemented solution. Its January 2025 SAQ A revision removed requirements 6.4.3 and 11.6.1 from that questionnaire, replacing them with a script-security eligibility condition for embedded forms. The condition does not apply to a plain redirect.

Your own form collects card information

If your website builds the card-entry form, even where the customer's browser sends details straight to a processor, SAQ A no longer fits. SAQ A-EP may apply if its conditions are satisfied. If card numbers reach your own server, SAQ D for merchants may be required. These distinctions follow the Council's SAQ descriptions.

The separate walkthrough of a Stripe PHP payment flow deals with integration mechanics. For PCI purposes, ask the developer to draw the card-data path rather than relying on a statement that a gateway is installed. If you also take telephone or in-person payments, include those channels in the discussion; the comparison of payment processing for booking systems concerns a different decision from choosing your PCI questionnaire.

What a self-assessment questionnaire actually does

An SAQ is an official set of questions about the applicable security controls. Eligible merchants answer the questions, fix or truthfully report any gaps and complete an accompanying Attestation of Compliance, or AOC. The PCI Council's self-assessment process says the merchant must first check eligibility and scope, then carry out the expected testing. Ticking 'yes' without checking the control is not an assessment.

For an online shop, these are the usual starting points. Each has separate eligibility conditions:

• SAQ A: For qualifying card-not-present businesses that fully outsource card-data functions to compliant providers and meet every eligibility condition. Redirected and embedded checkouts can fit, but they retain relevant site responsibilities.
• SAQ A-EP: For qualifying e-commerce businesses whose website affects the payment page or its delivery without itself receiving cardholder data. This generally involves more of the merchant's website in the assessment.
• SAQ D for merchants: For merchant arrangements not eligible for a shorter questionnaire, including sites that handle card numbers directly. Do not self-select SAQ A simply because a processor eventually receives the payment.
• Other SAQs: Separate categories exist for certain terminals, virtual terminals and validated point-to-point encryption arrangements. A shop with more than one payment method may need additional assessment or different documentation.

It is the acquiring bank, payment provider or payment brand that sets your validation and submission requirements. The Council distinguishes complying with PCI DSS from being asked to submit evidence of compliance. Ask which questionnaire is accepted for your exact setup, when evidence is due, whether the completed AOC must be submitted, and who reviews it.

A passed external scan does not replace the questionnaire. Nor does the provider's own AOC automatically prove your whole business is compliant. The Council's outsourcing guidance says merchants still need a written agreement with the provider and must check its compliance status at least once a year (requirements 12.8.2 and 12.8.4). Keep the documents with your payment agreements so the answers remain traceable when your checkout changes.

What you still need to protect on your website

Outsourcing card collection removes an important source of exposure, not every website security task. Someone who takes over your administrator account or alters your checkout page may redirect buyers, interfere with an embedded form or change the code you intended to serve. The controls below should be matched to your SAQ and provider responsibility matrix, rather than treated as a substitute for them.

• Accounts and access: List everyone with access to the website, hosting, domain and payment dashboard. Remove access no longer needed, and use a passkey or a unique password with two-step verification where supported, following the NCSC's account guidance. Before changing login methods, confirm a recovery method and another authorised way in; afterwards verify an ordinary login and a recovery route without locking out the only administrator.
• Checkout scripts: Inventory scripts and third-party tags loading on pages that redirect or embed payment. For an embedded form, keep the provider's confirmation or your documented script-protection method. Ask which are necessary and who approves changes. Before removing a script, save the working page or deployment and test the proposed change in staging; confirm checkout loads, the destination is genuine and the provider receives a test transaction. If a payment or consent function fails, roll back only to a tested version you know is safe; otherwise switch that function off.
• HTTPS and certificates: Your own checkout-related pages should use a valid secure connection, even if the provider hosts the card fields. Check the page address, certificate validity, redirects and renewal arrangements; the Council's cryptography guidance explains why the presence of TLS alone is not enough if it is vulnerable. For a separate explanation, see HTTPS and TLS checks for a business website. Have your host stage certificate changes, verify the live checkout afterwards and keep a recovery arrangement if renewal or routing breaks.
• Software and backups: Identify who applies security updates to the shop, extensions, hosting and server software. The NCSC recommends supported, updated devices and software; it also says to know how to restore a backup and check that it holds all your important data. Back up before an update, verify a restore path, update in staging when possible, check a provider test payment and order record, and roll back the release if they fail. If relevant, checking PHP support on shared hosting helps with a separate maintenance decision.

The Council's SAQ A scanning clarification says SAQ A includes requirements 11.3.2 and 11.3.2.1, so a merchant-hosted website that redirects to a provider or embeds its payment form needs external vulnerability scans by a PCI Approved Scanning Vendor. Its 2024 resource guide says 11.3.2 requires passing ASV scans at least once every three months; 11.3.2.1 adds a separate scan after any significant change, such as a new checkout; that one need not come from an ASV, but the tester must be qualified and independent. Ask your acquirer and host which public systems are included and how to obtain passing results; a general website check is not a substitute for an ASV scan.

How to reduce PCI DSS scope safely

The main way to reduce scope is to stop card details entering systems you control. A fully hosted page, provider-served card fields or a suitable payment link can help, provided the implementation and all other channels meet the questionnaire's conditions. Tokenisation and outsourcing are useful, but neither cancels security obligations on systems that can influence checkout.

Changing payment collection is a live business change. Agree the safer order before touching the production site:

• Step 1: Record the current flow. Ask your processor for the integration type and which SAQ and scans the planned flow would need, then draw where card details enter, travel and are stored. Include forms, phone calls, messages, plugins and any saved customer details. Check the drawing against provider documentation and with the person maintaining the site; stop if nobody can account for a route.
• Step 2: Keep a way back. Save the current configuration and working deployment, back up orders and check the restore method before changing checkout. Confirm that you can recover the previous working site and that reverting will not lose already completed orders. Do not experiment with real customer card details.
• Step 3: Trial the lower-scope option. Use your provider's current test environment and integration instructions. Check the displayed payment destination, successful and declined test cases, order confirmation, refunds where supported, and what the site stores or logs. If card details still enter your server, pause and have the design reviewed.
• Step 4: Switch with a rollback owner. Schedule the change when someone can monitor orders. After deployment, check a provider-approved live payment or other authorised production verification, the order record, and customer-facing errors without logging any card details. If payment fails, take checkout offline, or use a fallback you configured and tested beforehand, rather than restoring an old form that collected card details, and tell the provider which attempts may need reconciliation; never simply retry uncertain charges.
• Step 5: Reconfirm scope. Ask the acquirer or provider to confirm in writing that the SAQ and scans agreed before the change still fit the live flow. Recheck the provider's AOC and responsibility matrix, then update the written scope and next review date. If the answer remains unclear, ask a PCI Qualified Security Assessor rather than filing a shorter questionnaire on assumption.

A payment link may be a sensible alternative for occasional invoices, while a hosted checkout suits an online shop with an order basket. Whichever provider you choose, make the card-data boundary clear and keep evidence that it works.

If you do not comply or card details are exposed

The UK-backed Start Up Loans guidance distinguishes PCI compliance from the law, and PayPal's UK Online Card Payment Services Agreement, last updated 12 October 2026, expressly requires merchants using the covered services to comply.

Failure can lead to requests for corrective action, contract charges, restrictions or loss of card-processing facilities. The exact consequence depends on the provider agreement and card-brand programme, not a universal UK fine. Stripe's guide describes possible penalties and costs, while PayPal's agreement provides for suspension in specified circumstances. Ask your provider what its notice, evidence and escalation process actually says.

If card details may have been stolen, handle it as a security incident first. Contain the affected checkout with your provider, preserve logs and records, and ask the acquirer which card-brand or forensic reporting process applies. Your provider agreement may set its own steps: PayPal's includes containing the breach, notifying PayPal as soon as possible and then notifying customers whose card data was likely exposed; read the full clause. Agree before any incident who calls the provider and acquirer, and who can take checkout offline. Do not erase evidence in an attempt to clean the site first; coordinate restoration only after the route of compromise is understood and a clean recovery is available.

A breach involving personal data can create separate duties under UK GDPR. According to the Information Commissioner's Office, a notifiable personal data breach must be reported without undue delay and, where feasible, within 72 hours of becoming aware of it; high-risk cases also require prompt notice to affected people. Not every incident is reportable, but all personal data breaches need to be documented. Seek appropriate legal and incident-response advice for the actual circumstances.

A checklist to take to your payment provider

You do not need to solve every technical detail before contacting your provider. You do need a truthful description of the setup, access to the agreement, and somebody who can explain the website's payment route. Take these questions to the acquirer, processor or whoever manages PCI reporting for your account:

• Payment channels: Do you have a record of every way we take card payments, including the website, invoices, telephone and terminals? Ask for the list in writing and compare it with a sample of recent payment records, without copying full card numbers.
• SAQ eligibility: Which SAQ or SAQs cover our payment channels, and why? Ask which specific eligibility conditions have been checked, then match the reply to the Council's published SAQ descriptions.
• Provider evidence: Can you supply your current AOC, the services covered and a responsibility matrix? Check that the name and product match what the business actually uses, and record when the evidence needs reviewing.
• Website security: Who is responsible for the checkout page, scripts, updates, access controls and any embedded-form script protection? Get the answer in writing and compare it with the actual people who hold website and hosting access.
• Scanning and submission: Do we need an ASV scan, which public systems are in scope, and what evidence is due? Ask where the results and SAQ or AOC should go. Check that the response names an approved scan where one is required, rather than an ordinary vulnerability report.
• Changes and incidents: Who approves a new payment integration, and whom should we contact if the checkout is compromised? Save the support route and test that an authorised person can reach it without sharing customer card details.

Keep the replies beside a simple diagram of the card-data flow. Review them when you add a sales channel, change checkout providers or alter the payment page. A change that seems cosmetic to the customer may move responsibility back onto your website.

Decide what needs checking next

Start with the card-data route and the provider's written answer about your SAQ. If you cannot tell whether the page collects card details or only passes customers to a compliant processor, a developer can trace it; the page on how web development work is quoted explains how a job starts, and formal PCI validation stays with the appropriate party. With both answers in writing, you have a first scope for PCI DSS for small business; the completed SAQ shows whether the controls are in place.