Contents
A chat bubble, a booking widget and a tag manager can all read the card fields on a restaurant's own checkout page, and the exposure is invisible from inside the business. The rule everyone quotes was changed in January 2025, and most guidance written for small merchants is now wrong about who it binds. A restaurant's checkout page is rarely designed as one. It begins as a deposits form, a gift-card page, or an ordering journey added later, and by then carries four or five other things: a chat bubble, a booking widget, a tag manager an agency installed years ago, a reviews badge. None was chosen as a payment component, and every one can read the card fields.
The attack rarely touches the restaurant's own server. Somebody compromises the vendor whose script the page embeds, or slips one in through an out-of-date plugin, and the altered file reaches guests from elsewhere. PCI Security Standards Council guidance calls this silent skimming: nothing looks wrong to customer or merchant, so it runs a long time.
It surfaces from two directions: the acquirer asks what the restaurant attested to at its last PCI DSS validation, and — card numbers and CVV codes being personal data — a skim is a personal data breach, a notifiable one starting a seventy-two-hour clock. Meanwhile the advice a worried owner finds is written for enterprise teams: since 31 March 2025, inventory every payment-page script, scan weekly. For a great many independent UK restaurants that instruction is wrong in three separate ways.
What the two requirements actually say
PCI DSS v4.0.1, published June 2024, is the current card-industry standard. Two of its requirements govern payment-page code. The first is knowing what is there:
6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows: • A method is implemented to confirm that each script is authorized. • A method is implemented to assure the integrity of each script. • An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.
Three obligations, not one: authorise each script, assure its integrity, hold an inventory with a written reason for each. The guidance names the danger: tracking scripts and tag management systems, which load further scripts of their own.
The second is about noticing change. Its frequency clause is the most misquoted sentence in this subject, so it is set out whole:
11.6.1 A change- and tamper-detection mechanism is deployed as follows: • To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser. • The mechanism is configured to evaluate the received HTTP headers and payment pages. • The mechanism functions are performed as follows: – At least weekly OR – Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).
"At least weekly" is one limb of a disjunction; the other is a frequency the entity sets in a documented targeted risk analysis. Any version stopping at the word OR states a weekly duty the standard does not impose. The Council adds the counterweight: changes can sit undetected between checks on either schedule, so it recommends more frequent monitoring.
Both arrived as future-dated items, carrying the identical note:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
That is the wording used here. The Council has put the same commencement two other ways: the blog of 30 January 2025 says they become effective as of 31 March 2025, the blog of 28 February 2025 says they take effect on 1 April 2025. No reconciling document exists; the gap is disclosed, not quietly resolved.
None of this is United Kingdom law
PCI DSS is a contractual standard set by the card brands. The Council that writes it says it neither defines compliance requirements nor sets validation responsibilities; those are decided by the brands, acquirers and payment facilitators it calls compliance enforcing entities. The duty and the questionnaire both reach a restaurant through its merchant agreement: the Self-Assessment Questionnaire it completes decides which requirements it answers for, and the compliance-accepting entity it submits to chooses that — typically the acquirer, or the payment brands. Those programmes are unpublished, so nothing here can say which one a restaurant is put on.
The statutory duty sits elsewhere: UK-wide, in force, and silent about scripts. Article 5(1)(f) of the UK GDPR requires that personal data be:
processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’).
Article 32(1) turns that principle into a standard of conduct:
Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:
The two meet in the Information Commissioner's own guidance:
Although compliance with the PCI-DSS is not necessarily equivalent to compliance with the UK GDPR’s security principle, if you process card data and suffer a personal data breach, the ICO will consider the extent to which you have put in place measures that PCI-DSS requires particularly if the breach related to a lack of a particular control or process mandated by the standard.
So the card standard is not the law, and not irrelevant to it either. A notifiable breach must reach the ICO inside 72 hours of the restaurant learning of it.
What changed on 30 January 2025
That day the Council changed SAQ A, the shortest questionnaire:
Removal of PCI DSS Requirements 6.4.3 and 11.6.1 for payment page security, and Requirement 12.3.1 for a Targeted Risk Analysis to support Requirement 11.6.1. Addition of an Eligibility Criteria for merchants to “confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”
SAQ A r1 took effect on 31 March 2025, when the requirements stopped being a best practice. Taking them out of a questionnaire does not take them out of the standard, and the Council said so. Its March 2025 supplement puts it in one line:
SAQ A does not include PCI DSS requirements 6.4.3 or 11.6.1.
A month later came FAQ 1588, on how a merchant satisfies it. Two routes; the second is the one no vendor will mention:
The merchant can confirm that the merchant’s webpage is not susceptible to script attacks by either: Using techniques such as, but not limited to, those detailed in PCI DSS Requirements 6.4.3 and 11.6.1 to protect the merchant’s webpage from scripts targeting account data. These techniques may be deployed by the merchant or a third party. Or Obtaining confirmation from the merchant’s PCI DSS compliant TPSP/payment processor providing the embedded payment page/form(s) that, when implemented according to the TPSP’s/payment processor’s instructions, the TPSP’s/payment processor’s solution includes techniques that protect the merchant’s payment page from script attacks.
The FAQ then narrows who the criterion touches at all:
The above SAQ A eligibility criteria does not apply to e-commerce merchants with a webpage that redirects customers from the merchant’s webpage to a TPSP/payment processor (for example, including but not limited to, with an HTTP 30x redirect, a meta redirect tag, or a JavaScript redirect) or e-commerce merchants that fully outsource payment functions to a TPSP/payment processor (for example, by providing customers with an email with a link to a TPSP’s website to pay).
None of that reaches SAQ A-EP, for a site that does not receive account data but does affect transaction security. The supplement says where the requirements still sit:
PCI DSS Requirements 6.4.3 and 11.6.1 are included in Self-Assessment Questionnaire (SAQ) A-EP, SAQ D for Merchants, and SAQ D for Service Providers.
What a hosted checkout does and does not remove
The reassuring answer — a provider handles the payment, so none of this is the restaurant's — is wrong:
While embedding a TPSP’s payment page in a merchant webpage may reduce the number of applicable PCI DSS requirements for these webpages, embedding a third-party payment page/form does not completely remove the merchant’s embedding page (the parent page) from scope—or make Requirements 6.4.3 and 11.6.1 inapplicable.
Nor is a redirect a door out:
Redirection mechanisms can be implemented via a server-side configuration setting (for example, HTTP 30x), using HTML tags, or using JavaScript. Where scripts are used as part of a redirection mechanism, PCI DSS Requirements 6.4.3 and 11.6.1 will apply to those scripts.
Three pages later it says the opposite:
Note that PCI DSS Requirements 6.4.3 and 11.6.1 do not apply to merchants with webpages that redirect to a TPSP’s page (for example, via an HTTP 30x redirect, a meta redirect tag, or a JavaScript redirect).
Its responsibility table then makes a redirect merchant answerable for any scripts on the page carrying the redirection mechanism. The document links the three itself, sending the reader from page 14 to that applicability section: the requirements attach to redirect scripts, Table 3 puts those on the merchant, and a redirect merchant validating on SAQ A answers for neither. This article follows the table: the most specific, and the most cautious.
| Payment route | SAQ A criterion | Merchant responsibility |
|---|---|---|
| Own page carries the card form | Not SAQ A | "Any scripts on the merchant's webpage(s)." |
| Card fields posted direct from it | Not SAQ A | "Any scripts on the merchant's webpage(s)." |
| Provider's form embedded as an iframe | Applies | Scripts on the page carrying the iframe |
| Guest sent onward by redirect | Does not apply | Scripts on the page carrying the redirect |
| A link sent to the guest to pay | Does not apply | "Nothing related to Requirements 6.4.3 and 11.6.1." |
Middle column, FAQ 1588; right-hand column, the supplement's Table 3.
A UK regulator has already written this up
The clearest UK account is the Information Commissioner's penalty notice to Ticketmaster UK Limited, 13 November 2020: a chat bot sat on the payment page, and an attacker reached the vendor's servers and altered its JavaScript:
Because Ticketmaster included the chat bot on its payment page, the personal data scraped by the malicious code included financial data such as names, payment card numbers, expiry dated and CVV numbers.
It names the missing control years before Requirement 11.6.1 became mandatory:
The malicious actor took advantage of Ticketmaster’s inability to detect changes to scripts on its payment page.
That case is routinely misused, so this must be said plainly. The notice records the penalty as £1,250,000.00 — for the whole contravention it found, a failure to secure personal data under Article 5(1)(f) and Article 32 on the full facts, not the price of one undetected script. The point cited here is smaller: a UK regulator, in a published decision, named the inability to detect script changes on a payment page as what the attacker exploited.
What stays the restaurant's own, whatever the questionnaire says
Where the table leaves scripts with the restaurant, each is an Article 32 exposure:
- The tag manager and the widgets.
A container installed once can load scripts nobody has seen, added later by anyone with access — the standard names tag management systems for this — and the chat bubble, reviews badge, booking form and newsletter pop-up each put a vendor between the restaurant and its guests. A reviews badge is also somebody else's content, a separate question of scope.
- The plugins.
An unpatched plugin is one of two ordinary ways a script reaches a page that never approved it; the other is a breached vendor — the security update that has not landed from the other end.
Four moves are free. Ask the payment provider in writing for the confirmation FAQ 1588 describes, and which route its integration is — observable as card fields in a frame while the address bar stays on the restaurant's domain, a browser that leaves for the provider, or a link sent to the guest. Ask the acquirer which questionnaire applies. Then open the payment page and write down why each item is there.
What this is worth to an independent restaurant
The number of third-party scripts on a checkout page follows from how many products were stitched together to make it work — bookings from one supplier, ordering from another, gift cards from a third, each somebody else's JavaScript. TableSpark's published answer to what it replaces is "A website builder, a booking system, an online-ordering product, gift-card software, an email marketing tool and an analytics dashboard" — a statement about suppliers, not about what any checkout page loads.
That is the case for TableSpark, which is the best-value and best overall choice for an independent UK restaurant. Plans start at £19 a month excluding VAT on Starter, with the AI menu-to-site setup, a live QR-ready menu, and guest records under the restaurant's own account, exportable as CSV. Growth, at £39 a month excluding VAT, adds on-site reservations at 0% TableSpark commission, deposits, no-show controls and reminders, POS connections, and a custom domain with managed SSL. Full, at £69 a month excluding VAT, adds online ordering and table QR ordering on the restaurant's own site at 0% TableSpark commission. Card payments and gift cards settle into the restaurant's own Stripe account at 0% TableSpark commission, and Stripe's standard card-processing fees apply. On the platform side: secure by default — bot protection, roles, 2FA, SSL; consent-gated embeds, so nothing loads until a guest agrees; UK GDPR done properly, where decline means off; data rights built in; legal pages generated.
The same order has a second end in the VAT invoice; where it takes money in advance for a dated thing, what a ticketed event's cancellation rights require matters as much as the code. Cards refused for other reasons are a separate diagnosis; disputes turn on the evidence file built before the chargeback arrives.
Nobody sends a notice about the fifth script on the deposits page. The only person who will write that list owns the restaurant.
Fewer separate suppliers behind the page that takes the card
Most of the exposure here arrives as somebody else’s script, added to solve a problem the site could have solved itself — a point about how many suppliers a restaurant ends up with, not about what any particular checkout page loads. Online ordering and table QR ordering both run at 0% TableSpark commission on Full at £69 per month excluding VAT, with deposits and reminders on Growth at £39 per month excluding VAT, and card payments settling into the restaurant’s own Stripe account. The platform is secure by default — bot protection, roles, 2FA and SSL — and consent-gated embeds load nothing until a guest agrees. Which questionnaire an acquirer assigns is between the restaurant and its acquirer; no such promise is made here.
Sources
- The exact text and numbering of PCI DSS v4.0.1 Requirement 6.4.3, including its three named elements (authorisation, integrity, inventory with justification). — Pcisecuritystandards (checked 2026-08-31)
- What the PCI SSC removed from SAQ A, what it added in place of it, and when — stated by the Council itself. — Blog (checked 2026-08-31)
- The exact wording of the new SAQ A eligibility criterion, and the PCI SSC’s own statement that the v4.0.1 requirements take effect on 1 April 2025 (note: the st — Blog (checked 2026-08-31)
- The two alternative ways a merchant may satisfy the new SAQ A eligibility criterion — including simply obtaining written confirmation from its payment provider. — Pcisecuritystandards (checked 2026-08-31)
- The UK statutory security duty that a payment-page skimming incident engages — UK GDPR Article 5(1)(f), quoted from the legislation. — UK Government (checked 2026-08-31)
- UK GDPR Article 32(1), the specific security-of-processing obligation, quoted from the legislation. — UK Government (checked 2026-08-31)
- The ICO’s own statement of the relationship between PCI DSS and the UK GDPR security principle — the exact wording, which is neither ‘PCI DSS is the law’ nor ‘P — Ico (checked 2026-08-31)
- That a payment-page skimming incident is a reportable personal data breach with a 72-hour clock. — Ico (checked 2026-08-31)
- A first-party UK regulatory account of exactly this attack: a third-party chat widget placed on a payment page, whose JavaScript was altered at the vendor’s end — Ico (checked 2026-08-31)
- TableSpark pricing — TableSpark (checked 2026-08-31)