Payment page security for PCI Compliance | Knowledge

For a comprehensive list of PCI requirements, please consult the Engaging Networks Trust Center.

Nonprofits that accept credit or debit card donations are required to comply with the Payment Card Industry Data Security Standard (PCI DSS). This global security framework exists to protect donor payment information and prevent fraud, data breaches, and misuse of cardholder data.

Your organization is responsible for ensuring that any systems or web pages under your control (including Engaging Networks payment pages) are secure and compliant. PCI DSS compliance helps nonprofits:

Protect sensitive donor data and trust
Reduce the risk of fraud or cyberattacks
Maintain eligibility to process card payments
Avoid costly fines, penalties, or reputational damage

Requirements

Self assessment questionnaire: complete a self-assessment questionnaire (SAQ) at least every 12 months
Page scanning: conduct quarterly scans of payment pages via an Approved Scanning Vendor (ASV)
Inventory, attestation, and authorization of scripts: maintain an inventory of scripts including the URL, purpose, and justification for the script. Additionally maintain policies to ensure only authorized scripts are loaded on payment pages
Tamper detection and alerting: maintain monitoring and detection of unauthorized page changes

Self-Assessment Questionnaire (SAQ)

PCI DSS v4.0
Frequency: Annual

To meet this requirement, an organization needs to do the following:

Determine the SAQ type applicable to your organization. Your payment processor (for example Stripe, Vantiv, iATs) can assist you with this determination
Locate the correct SAQ from the PCI council document library.
Complete the SAQ and Attestation of Compliance (AOC).
Store the completed documents securely with other compliance materials.
Provide the SAQ and AOC to your payment processor (for example Stripe, Vantiv, iATs, etc).

Page Scanning

Control: Requirement 11.3.2
Frequency: Quarterly

Engaging Networks manages this process for Smart Pages. The instructions below are applicable to page builder type pages.

To meet this requirement, an organization needs to do the following:

Enroll with Engaging Networks preferred Approved Scanning Vendor, ControlCase, or choose another ASV.

To submit a request to use an alternative Approved Scanning Vendor, please submit this form to start the process. Not all PCI-approved scanning vendors are compatible with Engaging Network’s environment; additional testing and coordination are needed to use an alternative scanner.

Download a list of pages that need to be scanned from the Engaging Networks Security Center.
Provide that list to the ASV for scanning.
Resolve any vulnerabilities revealed as part of the scan.
Provide the passing ASV scan results to your payment processor (for example Stripe, Vantiv, iATS, etc).

This video outlines the scanning process including navigating the ControlCase Dashboard.

Inventory, attestation, and authorization of scripts

To meet this requirement, an organization needs to do the following:

Part 1: Inventory and attestation

Control: Requirement 6.4.3
Frequency: Quarterly

Build or acquire a list of all scripts being used on your Engaging Networks pages.

Engaging Networks preferred ASV, ControlCase, will provide this as part of quarterly scanning. Smart Pages do not support custom scripts so the list of Engaging Networks scripts is all that is needed for this requirement.

Review the list to ensure all scripts are known to you and should be in use on your pages (see list of Engaging Networks scripts below).
Using the list of scripts, add the script URL, purpose for having the script on the page, and attest that you are aware of the scripts, they are meant to be on the your page and you have vetted their security.
Provide the attestation documentation to your ASV (required to obtain a passing scan).

Here is an example that you are welcome to copy:

We confirm that the following external scripts are intentionally embedded within our payment page. Each script is essential for the functionality, analytics, security, or user experience of our site. All scripts have been reviewed and approved by our team, and we confirm that they pose no known security risks.
List of external scripts:

[script url] -- [what it is used for]

[script url] -- [what it is used for]

Click here to review a list of Engaging Networks scripts, their descriptions and typical use cases

URL/File	Description	Developer	Typical Use Cases
/cdn-cgi/challenge-platform/h/g/scripts/jsd/44e6f86df4dc/main.js	Cloudflare security challenge script that runs checks in the user’s browser to verify the client is legitimate. It may perform bot detection, browser integrity tests, or computational challenges as part of Cloudflare’s anti-DDoS/Bot Management system.	Cloudflare, Inc.	Automatically included on websites protected by Cloudflare to challenge suspicious traffic. Typically, when a site is under attack or enforcing bot screening.
enEcommerce.js	JavaScript handling e-commerce functionality on Engaging Networks.	Engaging Networks	Shopping cart management, checkout processes.
enHub.js	Engaging Networks hub functionality JavaScript.	Engaging Networks	Centralized management of scripts across pages.
enPage.js	Main JavaScript for interactive form functionality.	Engaging Networks	Form validation, multi-step forms, and submission via API.
http://github.com/janl/mustache.js	GitHub repository for Mustache.js, a minimal templating library implementing the Mustache logic-less template system.	Open-source (maintained by Jan Lehnardt and contributors)	Template rendering on web clients or servers.
https://cdn.givechariot.com/chariot-connect.umd.js	Chariot's JavaScript library for DAFpay integration.	Chariot (http://GiveChariot.com )	Donor-Advised Fund payment options embedded in donation forms.
https://cdn.plaid.com/link/v2/stable/link-initialize.js	Plaid Link initialization for connecting bank accounts.	Plaid Inc.	Linking financial accounts for payments or financial data.
https://centinelapi.cardinalcommerce.com/V1/Cruise/Collect	Cardinal Commerce's 3-D Secure API script.	Cardinal Commerce	Secure authentication for card transactions.
https://centinelapistag.cardinalcommerce.com/V1/Cruise/Collect	Cardinal Commerce's staging environment API script for 3-D Secure.	Cardinal Commerce	Testing secure payment authentication processes.
https://doublethedonation.com/api/js/ddplugin.js	JavaScript for Double the Donation matching gift functionality.	Double the Donation	Embedding employer matching gift search in donation forms.
https://h.online-metrix.net/fp/tags.js	Device fingerprinting script that gathers information about a visitor’s device (browser, OS, etc.) and sends it to ThreatMetrix for fraud analysis. Often embedded as a hidden widget to profile devices and detect high-risk activity.	ThreatMetrix (LexisNexis Risk Solutions)	Used in e-commerce, banking, and account sign-up flows for online fraud detection – it helps prevent suspicious or malicious devices from abusing services—integrations via payment gateways or security platforms to mitigate fraud.
https://js.stripe.com/v3/	Stripe's JavaScript SDK for secure payment processing.	Stripe, Inc.	Online payment integrations.
https://js.verygoodvault.com/vgs-collect/2.23.0/vgs-collect.js	Library for securely capturing sensitive data in forms.	Very Good Security, Inc.	Secure handling of sensitive financial information.
https://js.verygoodvault.com/vgs-collect/2.27.2/vgs-collect.js	VGS Collect.js library is used to securely capture sensitive user data in web forms. Injects secure iframes/fields and intercepts data before reaching the server.	Very Good Security, Inc.	This is the VGS Donation JavaScript Library that handles all Cardholder Data Environment (CDE) transactions.
https://platform.twitter.com/widgets.js	Twitter widget embedding script.	Twitter, Inc. (X Corp)	Embedding tweets, timelines, and follow buttons.
https://www.google.com/recaptcha/api.js	Google reCAPTCHA API script, which loads the reCAPTCHA widget and logic on a page.	Google LLC	Spam/bot prevention on forms and logins.
https://www.google.com/recaptcha/api.js	Google reCAPTCHA widget loader.	Google LLC	Spam prevention on form submissions.
https://www.paypal.com/sdk/js	PayPal's JavaScript SDK for payment integrations.	PayPal, Inc.	Integrating PayPal payment solutions.
pagedata.js	Engaging Networks page data script for unique page IDs.	Engaging Networks	Internal use on Engaging Networks pages – provides page-specific data.
productvariant.js	JavaScript handling product variants on e-commerce pages.	Engaging Networks	Managing product selections, variants, and associated user interactions.
suggestedgift.js	JavaScript manages suggested donation amounts.	Engaging Networks	Enhancing user experience on donation pages.
fft_init.js	JavaScript manages Engaging Networks Free and Flexible Template	Engaging Networks (4Site Studios originally developed)	Enhancing user experience on pages.
fft_one_click_v1-6.js	JavaScript manages one click donation features in Engaging Networks Free and Flexible Template	Engaging Networks (4Site Studios originally developed)	Enhancing user experience on donation pages with one click enabled.

Can’t find a script you believe is Engaging Networks'? Please reach out to support@engagingnetworks.community for assistance.

Part 2: Script authorization

Control: Requirement 6.4.3
Frequency: Continuous/ ongoing

There are a number of ways an organization can meet this requirement. One way is to use a Content Security Policy (CSP). A CSP can be enabled for Engaging Networks pages to help meet this requirement and an organization needs to do the following:

Have a list of scripts, domains and other assets used on your Engaging Networks pages.
Follow the instructions here to define, test, and deploy a CSP header.
Monitor and update CSP directives regularly and as needed.
Be prepared to show documentation of your controls to your QSA and/or as part of an SAQ.

Tamper detection and alerting

Control: Requirement 11.6.1
Frequency: Continuous/ ongoing

This is one way to meet this requirement. There are other ways your organization may choose to meet the requirement including using third party tools.

Implement a CSP.
Enable CSP reporting as part of the policy (directive report-to ).
Set up a report collection endpoint on your server.
Generate alerts for any unauthorized changes.
Monitor and review violations regularly.
Be prepared to show documentation of your controls to your QSA and/or as part of an SAQ.

Glossary

Acronym	Full Term	Definition
AOC	Attestation of Compliance	A signed declaration that your organization complies with PCI DSS, submitted with the SAQ.
ASV	Approved Scanning Vendor	A company certified by the PCI SSC to perform required external vulnerability scans.
CSP	Content Security Policy	A security mechanism to restrict which scripts and resources can be loaded by a web page (important for script attestation).
DSS	Data Security Standard	Refers to the core PCI DSS document (e.g., PCI DSS v4.0).
PCI DSS	Payment Card Industry Data Security Standard	A global standard for securing credit/debit card transactions and cardholder data.
QSA	Qualified Security Assessor	A professional or firm certified by the PCI SSC to audit and validate PCI DSS compliance.
ROC	Report on Compliance	A detailed report generated by a Qualified Security Assessor (QSA) for larger organizations (not SAQ users).
SAQ	Self-Assessment Questionnaire	A compliance form used by merchants to assess and report their adherence to PCI DSS.

Additional Resources

Below is a list of some Frequently Asked Questions, but if you don’t find the answers you are looking for, reach out to your Account Success Manager.

FAQs

What is PCI DSS?

PCI DSS was developed to encourage and enhance payment card account data security and facilitate the broad adoption of consistent data security measures globally. It provides a baseline of technical and operational requirements designed to protect payment account data.

Who has to adhere to PCI DSS?

PCI DSS is applicable to entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE). This includes all entities involved in payment card processing - including merchants, processors, acquirers, issuers, and service providers. For Engaging Networks, this includes clients -- who are considered "merchants".

Do I need to be PCI DSS compliant, or can I simply rely on Engaging Network's compliance?

Yes, all merchants, regardless of size, must comply with the Payment Card Industry Security Standards. This is typically because merchants either store, process or transmit cardholder data; however, with the new version 4 requirements, customized payment pages also must comply since they could impact the security of the cardholder data environment by allowing vulnerabilities to put payment data at risk.

What is Engaging Network's role in PCI compliance for the platform?

Engaging Networks must certify annually, via an external Qualified Security Assessor (QSA). An Attestation of Compliance (AOC) report is prepared at the conclusion.

What is the client's role in PCI compliance for payment pages?

Clients need to follow PCI Data Security Standards, especially concerning the use of external libraries on payment pages and scanning for vulnerabilities on payment pages. Every merchant is required to complete a self-assessment questionnaire at least every 12 months. In addition, every merchant must also conduct quarterly scans of payment pages via an Approved Scanning Vendor (ASV)

Is the PCI Attestation of Compliance intended to be shared?

Yes. The PCI DSS Attestation of Compliance can be shared with clients upon request, according to applicable Participating Payment Brand rules. Clients should contact the payment brands directly for information about their compliance programs and reporting requirements.

What PCI-related best-practices should be considered when using Engaging Networks?

Implement a process where at the end of a particular campaign, all related pages are closed and redirected to your main donation page. Making this a best-practice will ensure that your account does not end up with too many open and unused pages. Closing or deleting pages that are no longer needed will reduce your exposure to spam and fraud attacks by limiting the number of entry points for bad actors, and will reduce your overall account administration needs as you will have fewer pages to maintain. Use our handy low-volume page report to help with this!

What kind of pages are scanned?

Any page builder page that takes payment, such as donation and events pages, need to be scanned. It doesn’t matter how much the page raises, the currency, or payment type. Smart Pages are also scanned but Engaging Networks manages that process.

What does it mean to do an ASV scan? What is it looking for?

A PCI ASV scan is a vulnerability scan that checks for security flaws. Quarterly (every 90 days) scans are required by the Payment Card Industry (PCI) Data Security Standard (DSS) for organizations that accept payment cards. An Approved Scanning Vendor (ASV) must perform the scan. The results of the scan will be included in a report, alerting you to any vulnerabilities that were found. If security flaws are not fixed, you may be fined or lose your ability to accept credit card payments. Regular vulnerability scans are necessary to identify and mitigate security risks associated with cardholder data.

Why is ASV scanning of Engaging Networks pages required?

Engaging Networks allows clients to customize payment pages, including adding external code and libraries. This customization offers flexibility but may also introduce potential security risks. Customized payment pages with external libraries can introduce vulnerabilities, such as cross-site scripting (XSS) or insecure dependencies. ASV scans help identify and mitigate these risks. Smart Pages do not support the same level of customization and Engaging Networks manages the scanning for those.

Will Engaging Networks and the client both need to complete ASV scans, or if EN is scanning our pages is that all that is required?

Clients will be responsible for having ASV scans performed on their payment pages. EN has selected ControlCase to be our preferred ASV scanner. Engaging Networks will manage the scanning of Smart Pages.

Why did you choose ControlCase as the scanner?

After comprehensive evaluation and testing, we are confident in ControlCase's software and expertise, and believe that they will deliver solid care and attention to our clients at a fair price. Approved by the PCI council, with over 15 years of experience in cybersecurity and compliance services, ControlCase is well-equipped to help clients identify vulnerabilities, stay ahead of potential threats, and ensure compliance with the Payment Card Industry Data Security Standard (PCI DSS). They will also handle the step by step process with you

Can I use a different scanner?

It is possible to use another vendor - a list of approved scanning vendors can be found here. However, please note that not all scanners will work in the Engaging Networks environment so please get in touch with your Account Manager to confirm this first.

Because of this, we highly recommend ControlCase for their expertise and fair pricing, which we secured through bulk rates shared among multiple clients. They are approved by the PCI council, and have over 15 years of experience in cybersecurity and compliance services.

What is the journey in working with ControlCase?

The team at ControlCase will work closely with you to ensure a smooth scanning process, with minimal disruption to your operations. You will sign a contract with, and pay, ControlCase directly for their services.

How do I get started?

Enroll with ControlCase via this link

Does Control Case help clients with fixing any scans that don't pass or is that up to the client?

ControlCase does not do any remediation themselves, but they will walk you through what needs to be fixed. If you need support to implement a fix, we can provide a list of Accredited Partners who are very familiar with this work.

Will Engaging Networks continue do scan client pages after the PCI scanning is complete?

We will continue to perform scans each week to help detect and find vulnerabilities on client pages. We will update the scans results page each week as well, but this is not a substitute for scanning by a PCI Council Approved Scanning Vendor ("ASV"). This is simply to help you achieve a clean scan each quarter from an ASV and ultimately, to keep your pages and the Engaging Networks platform safe and in compliance with PCI rules.

Can you talk about how ControlCase knows which pages to scan, once clients sign up?

ControlCase lets us know every time a client enrolls in their services. At that time, we provide a list of page URLs to ControlCase. From there, you will work with ControlCase to determine how many of those pages will need scanning.

You can also retrieve this list directly from your account’s Security Center. You can navigate to this page from the Hello menu > Security Center. Note that only Super Admin level users can access the Security Center. Smart Pages are omitted from this list as Engaging Networks manages the scanning of those pages.

Are Engaging Networks Partners who may have designed our templates being briefed on this and 1) how they can help us rectify any vulnerabilities if needed and 2) knowing how to ensure new templates are compliant?

Yes, all of our Accredited Partners are receiving all of this information as well, and many of them would be more than happy to help you. Please reach out to your Account Success Manager and we can recommend someone to work with.

What types of things could make a page fail the scans?

Reasons above and beyond vulnerable javascript libraries, include (but are not limited to) cross-site scripting, SQL injection, error handling, security patches, iframes, and input validation. Note, an example summary scan report from ControlCase is available for download from our Trust Center under the Resources section titled 'PCI DSS Related Documents'.

Does that list of pages to be scanned only include “New” and “Live” or do “Test” and other publish states also apply?

If the page is accessible from the Internet, and someone can input credit card data, or debit card data, it must be included in the scan. You will have an opportunity to verify what is in scope with ControlCase.

Will this list account for Locales, Profiles, etc.. that can have different code?

The list provided to ControlCase does not include all potential variations of a single page. Clients using locales and profiles on their pages should raise this with their scanning vendor to determine the final scope of their scan.

Will this list have a way to view Page 2 of the Supporter Hub pages, which can process credit card payment?

Engaging Networks is responsible for scanning these pages, so they are not included in the scope for clients.

'Closed' pages don't need to be scanned, even if they are processing recurring donations?

That's correct. If the page is closed and cannot be interacted with via the Internet, then it does not need to be scanned.

If pages are 'new' in EN they are not accessible online so why do they need to be scanned?

Even pages with a "New" status are accessible online with the ?mode=DEMO URL parameter. If the page is accessible from the Internet and someone can input credit card data, it must be included in the scan. You will have an opportunity to verify what is in scope with ControlCase.

Are peer-to-peer pages included in the page count, and if so will ControlCase scan to tell how many there are? Is it be based on the number of donation form templates per site or the number of live fundraiser pages?

Pages in the legacy P2P tool are not included in the EN page list/count that is currently provided to ControlCase, but ControlCase has been made aware of any P2P clients so that they can discuss with you directly what the scope of your scanning should be.

It’s only donation page urls correct, NOT other data captures as well?

The PCI-DSS ASV scan requirement only applies to pages where credit card data can be entered, which includes the following page types: Donation, Premium Donation, Symbolic Giving, Membership, Peer-to-peer, and Events. Other page types do not require ASV scanning.

Do clients need to scan non-production systems? (Sandbox environment)

If the sandbox account is set up with a payment gateway and has pages where credit card data can be entered, which includes the following page types: Donation, Premium Donation, Symbolic Giving, Membership, Peer-to-peer, and Events -- then yes, the sandbox pages should be included in the scan.

The ControlCase pricing slide indicates that it is for one domain. Does that mean we need to pay twice that amount if we have donation pages on one domain and P2P classic pages on another? Or is it still considered one EN domain?

Engaging Networks has set up a dedicated domain that the ControlCase will use to conduct ASV scanning. So clients will only be charged for 1 domain, regardless of how many custom hostname/SSL certificates they use.

Do we need to notify someone every time we create a new donation form?

No, that will not be required. When it comes time for quarterly scanning, an updated page count will be provided.

What about new or live pages that are not processing donations, but are donation templates. For example, we have a page set up for Gift-in-kinds and the payment fields are disabled.

If the page is accessible from the Internet and someone can input credit card data, it must be included in the scan. Even pages with a "New" status are accessible online with the ?mode=DEMO URL parameter. When the list of your pages is sent to ControlCase, it would include any Donation Pages you have, and then you will work with ControlCase directly to verify what is in scope. If a donation page does not have credit card fields on it, then it would be removed from the scope.

We use the same customized template on all of our donation pages, even though we have a lot of donation pages. Why do we need to scan each live page and not just the template?

The Engaging Networks system allows customization to happen at the page level, so all pages where credit card data can be entered (Donation, Premium Donation, Symbolic Giving, Membership, Peer-to-peer, and Events) will be included in the file sent to the Approved Scanning Vendor. It is up to the client to work with the vendor to determine the ultimate scope of the scan.

Are pages that have a test gateway applied excluded from the pages that have to be scanned?

Pages using a test gateway would be included in the list of pages sent to ControlCase; however, it is up to the client to work with the scanning vendor to determine the ultimate scope of what is scanned.

We just completed our certification for our PayPal gateway/merchant account. Will we still get the requests to show compliance from our merchant accounts like PayPal and Stripe?

Clients will need to check with their gateway/merchants on their individual reporting schedules.