A chat widget on your checkout page can now knock you out of PCI's simplest compliance tier — the 2026 SAQ A rule small merchants keep missing

A small business moved its checkout to a payment processor's embedded card form years ago, specifically to stay off the heaviest compliance tier. It fills out the short self-assessment once a year, checks the boxes, moves on. In 2026, that same setup can quietly stop qualifying — and the page that failed usually still has the exact same payment form it always did. What changed sits elsewhere on the page.

PCI DSS v4.0.1 added a new eligibility condition to SAQ A — the simplest self-assessment questionnaire, reserved for merchants whose payment page is fully outsourced to a PCI-compliant processor via redirect or embedded iframe. The condition took effect April 1, 2025, and it caused enough confusion that the PCI Security Standards Council issued a dedicated clarification, FAQ 1588, to explain exactly what it requires and how to meet it [1].

This piece covers what that condition actually says, the two ways the Council allows a merchant to satisfy it, why the scripts a small business adds without thinking — not the payment form itself — are usually what trips it, and what falls out from under a merchant that no longer qualifies for the short questionnaire.

Start with what SAQ A is for, because the new condition only makes sense against that backdrop. SAQ A is the shortest of PCI DSS's self-assessment questionnaires — a fraction of the length of the next tier up — built specifically for e-commerce merchants who never store, process, or transmit card data on their own systems because the entire payment page comes from a PCI-compliant third-party processor, delivered either as a redirect to the processor's hosted page or as an embedded iframe on the merchant's own page ^[2][5]. For years, that structural fact alone was enough: if the card number never touched the merchant's own code, SAQ A applied, full stop.

PCI DSS v4.0.1 added a specific new clause to that eligibility test. The current SAQ A wording requires the merchant to have "confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)" — a condition the PCI Security Standards Council's own blog describes as taking effect on April 1, 2025 ^[1]. That single sentence is why FAQ 1588 exists: merchants and assessors alike weren't sure what "confirmed" meant in practice, so the Council spelled out two concrete paths.

The first path is self-applied: a merchant can meet the condition by using techniques similar to — though not limited to — PCI DSS Requirements 6.4.3 and 11.6.1. Requirement 6.4.3 calls for an inventory of every script that runs on a payment page, a documented reason each one is there, and a method to confirm each script's integrity. Requirement 11.6.1 calls for a change- and tamper-detection mechanism that evaluates the payment page's scripts and HTTP headers on a regular cadence and alerts on anything that changed without authorization ^[1][4]. The FAQ is explicit that these techniques can be deployed by the merchant directly or through a third party acting on the merchant's behalf ^[1].

The second path doesn't require the merchant to build anything: get written confirmation from the PCI-compliant payment processor providing the embedded form that its solution, implemented exactly per the processor's own instructions, already protects the page from script attacks ^[1][2]. That confirmation only covers what the processor's own code does — it says nothing about anything else loaded on the same page, which is exactly where most small merchants get caught out.

This is why the condition snags businesses that have nothing to do with how the payment form itself works. A live chat widget, a website analytics tag, a tag-manager container, or a retargeting pixel sitting on that same checkout page is precisely the kind of unvetted script the rule targets — and it's also exactly the kind of thing a marketing tool, a support plugin, or an agency snippet adds to a page without anyone checking whether it touches PCI scope ^[1][3]. A merchant can have a fully compliant iframe from a fully compliant processor and still fail the condition, because the condition is about everything running on the page, not just the part that handles the card number.

The consequence of falling out of SAQ A eligibility is a materially bigger compliance lift, not a warning. A merchant who can't satisfy either path has to move up to SAQ A-EP — a questionnaire built for merchants whose own page scripts participate in handling payment data, with roughly six times the number of requirements, plus a new obligation SAQ A never carried: quarterly external vulnerability scans by a PCI-approved scanning vendor ^[2][3][5]. None of this is enforced by a government regulator — it runs through the merchant's acquiring bank or payment processor, the same relationship that sets card-acceptance fees and, in the event of an actual breach, decides who carries the liability for fraud losses. That enforcement path is identical for a merchant in the United States and one in Egypt or elsewhere in MENA accepting cards online — it's a global card-brand standard, not a national law, so there's no smaller-market exemption to rely on.