PCI DSS

Card testing is when criminals run small transactions through an online form to learn which stolen card numbers still work. Donation pages are attractive targets because any amount is accepted. The charity can absorb declines, refunds, chargebacks and processor fees. Bot protection, minimum gift amounts, attempt limits and alerts on bursts of small transactions all make it harder.

Requirement 11.6.1 calls for a change- and tamper-detection mechanism that evaluates the HTTP headers and payment page as received by the browser at least once every seven days. An entity may choose a different frequency only if it is set by a targeted risk analysis performed under requirement 12.3.1. The mechanism must alert personnel to unauthorized changes.

Requirement 6.4.3 requires an inventory of every script that runs on the payment page in the customer's browser, with a written justification for why each is necessary, plus methods to confirm each script is authorized and to assure its integrity. In practice each entry records the script, its source, the pages that load it, the reason, who approved it, the integrity control and the last review date.

Requirement 6.4.3 covers every script that loads and runs in a customer's browser on a payment page. The entity needs a method to confirm each script is authorized, a method to assure each script's integrity, and an inventory of all scripts with a written justification for why each is necessary. It applies to first-party, third-party and fourth-party scripts and has been mandatory since 31 March 2025.

Yes. PCI DSS applies to any organization that accepts card payments, regardless of tax status. The obligation comes through your contract with your payment processor or bank, which usually requires an annual Self-Assessment Questionnaire.

It depends on how you accept cards. Organizations that fully outsource payment pages to a PCI DSS compliant provider often qualify for SAQ A, the shortest version. Card terminals or card numbers on your own systems move you to a longer SAQ. Your processor can confirm which one it expects.

Since 31 March 2025, SAQ A merchants must confirm their site is not susceptible to attacks from scripts that could affect their e-commerce systems. PCI FAQ 1588 says a merchant that embeds a provider's payment form can protect the page itself or rely on its PCI DSS compliant provider's confirmation that the form includes script attack protections. Redirect-only merchants are not affected.

Not as a listed SAQ A requirement: the PCI SSC removed Requirement 6.4.3 from SAQ A in January 2025. A merchant that embeds a provider's payment form must still confirm its site is not susceptible to script attacks, either by protecting the page with techniques such as those in 6.4.3 and 11.6.1 or by getting confirmation from its PCI DSS compliant provider. Merchants that fully redirect to the provider are not affected.

SAQ A is for merchants that fully outsource card processing, either by redirecting customers to a PCI DSS compliant provider or by embedding the provider's payment form, such as an iframe. SAQ A-EP is for e-commerce merchants whose website does not receive card data but controls how customers or their data are redirected to the provider. SAQ A-EP covers many more requirements.

SAQ D for Merchants applies when a merchant does not meet the eligibility criteria of any narrower questionnaire, for example because card data is stored electronically or passes through systems a shorter SAQ does not cover. It covers the full set of applicable PCI DSS requirements. Changing a payment process, such as using a provider-hosted payment link, can sometimes make a narrower SAQ available.

The entity the SAQ is submitted to, usually the merchant's acquirer or payment processor, has the final say. The PCI Security Standards Council encourages merchants to contact that entity first and to confirm they meet every eligibility criterion of a questionnaire before starting the self-assessment. Processor portals often assign a type based on the merchant's answers.

PCI DSS Requirement 11.6.1 requires a change- and tamper-detection mechanism that checks the payment page's scripts and security-impacting HTTP headers at least once every seven days. A firm can choose a different frequency only if it is supported by a documented targeted risk analysis performed under Requirement 12.3.1. Alerts must reach staff who can act on them.

The PCI Security Standards Council says it does not define compliance requirements for any organization or set compliance validation responsibilities. Those come from compliance enforcing entities such as the payment brands, acquirers and payment facilitators. For most small merchants, that means the acquiring bank or payment processor that asks for the annual self-assessment questionnaire.